I have a java application that was mainly built for the Mac. I need to be able to do either one of three things:
Have my application always follow the current space. Meaning, if I'm on Desktop 2 and start my app, then I switch to Desktop 3, my app will then be visible on Desktop 3 automatically. This is equivalent to right-clicking on the app icon in the dock, select Options, then choose All Desktops. If I can somehow make this the default behavior for my app, without requiring user action, then that would be great!
Capture the screen of a specific space. I currently use the Robot class to take a screen capture. If there is a way I can specify which space to capture, not just the current space, then that would be great!
Be able to at least detect if leaving the current space.
I'm starting to lean towards neither one of these are possible. But if you can give any help, or possible workarounds, that would be awesome!
I have also played around with the GraphicsEnvironment, GraphicsDevice, GraphicsConfiguration, but no luck. It doesn't return any info about Mac's Virtual Desktops (Spaces).
What is also making things difficult is I'm trying to avoid using platform specific code at all costs! I know I can use JNI to accomplish this, or there may be something in the java-apple extension. But currently, I use a single code branch and build for both Mac & Windows. I'm trying to avoid having two separate builds and binaries for both platforms.
The answer is "no" unless you are writing native code and using JNI. One of the key design features of Java is that it is OS agnostic. What you are asking for is extremely Mac OS X specific. I see nothing in the Apple Java Extensions that helps either.
No, as far as I know, Java doesn't have any special support for Spaces, so you'll need to use platform-specific, native code. However, JNI--with all its ugliness--isn't your only option. You can use JNA instead, which is much more programmer-friendly, and a lot easier to debug.
In your app, you can detect the platform. If it's a platform for which you've written platform-specific code, you can execute that code. If not, you can fall back to a default, pure Java implementation.
Related
I wanted to write an application for windows/mac/linux and I chose java because a java developer friend told me Java is platform independent.
I came to a problem where I wanted to clear the console (to make the reading easier on the user).
I've tried System.out.flush(); and Runtime.getRuntime().exec("cls");.
It seems the only real solution is to use a hack (and smelly code is bad) - Java: Clear the console (check "Dyndrilliac" answer).
The reason using this hack is bad, as other users have commented on "Dyndrilliac" answer, what happens when Microsoft or Apple changes the command name from "cls" or "clear" to something different? It pretty much breaks your application and you get an error (such as "command not recognized") from the OS Company.
So my question is: did Java decide not to implement a library that handles clearing console outputs due to keeping it up to date whenever Windows/Macs/Linux decides to change it's command names? Or did Java implement a library for handling this, and I just can't find it?
Java is independent in the way that it's not run directly on your OS. java run on jvm (java virtual machine) and because of that it should work the same in all OS. But the console that you print to it's the specific OS console and therefore, every OS will have it's own clear console command (because it's not the same console). You can build program with UI (using swing or other library) And control your output, or use some technics like in the post you linked to, it should work fine.
A) because there are many many more platforms java is running on that might have extremely different views on what a console is.
B) in order to give decent tooling for console based applications, you need much more than simple "clear" commands (think nurses here!)
And finally: when Java came into existence, anything was about applets and ui. Probably nobody wanted to invest much energy in supporting "legacy style" command line programming. (that last point is probably closer to an opinion than a hard fact).
I found a lot of discussions around this point but speaking either of a Java program running from the jar (in this case it is easy to replace it) or a C# application (I do not have knowledge on C#).
I use a tool (install4j, ..) to generate an installable file for Windows from the jar of my java swing application. My product installed and running on Windows should be able to "auto-update" itself, so I must have a component in my application that checks online if a newer version was to download and put in place of the currently executing.
I do not know how my application is installed in Windows (where are put the files? in one place? ... ) So what can I do to replace the current version being run with a new version (probably from a new installable file télchargé in this case) ? what's the best way?
how can I hide the questions like "do you accept ...?" and keep the original configuration during the update?
The problem for me is that my client wants/does not necessarily install java
Use the Deployment Toolkit Script to ensure the client has a suitable minimum version of Java installed. Then deploy it using Java Web Start to provide auto-update. I realize you don't want to make the client install Java, but you might be making the client install Windows if you make an executable. You'll typically lose more users by forcing them to install Windows, than by forcing them to install Java.
Now, when I give this advice to some people, they say words to the effect:
But my client only uses Windows OS! It will never be run on Mac OS or Linux/Unix.
And to that I would point out:
OK fine, but it seems yo are trying to make a left-hand turn at a right turn only intersection. If you need to turn left, you should have done that 6 blocks back.
What I mean by that is: Windows has its own languages and IDEs specialized for Windows. Being a language designed for Windows would mean it has:
Better ways to delve into the OS. Java keeps its functionality to a core set of functions that can be reliably supported across all major platforms. Anything beyond that requires native code.
Faster development time for any GUI elements. Java GUIs need to be designed using layout managers which are harder to learn and not conducive to Drag-and-Drop GUI design, which can be much faster.
A Windows based language probably has a slew of APIs and tools for providing auto-update, or if not, more free or reasonably priced 3rd party APIs for that.
..there are customers who imposed to not install java..
There is something you don't seem to understand. The GNU Compiler for the JavaTM Programming Language compiles code to natives. That is the only way to 'turn a Java app. into an executable. The GNU Compiler..
..supports most of the 1.4 libraries plus some 1.5 additions.
It does not even claim to support all of Java 1.3.
There are other utilities to install Java apps. with a private JRE. It might seem the JRE installation is invisible to the average user. But the power user would not be fooled. E.G.
Look and Feel
A Swing based app. using the Native Pluggable Look and Feel might look 'much like' a Windows app., but many people can still tell the difference. Swing does particular components differently to native Windows components (most notably JFileChooser, but there are others), and although the rest of the components look a lot like Windows equivalents, they are not exactly the same. Even the AWT based FileDialog looks different to the Windows file dialog.
Security
If the user has a problem with their PC and decides to kill a misbehaving app. they might type the following command sequence to bring up the Task Manager: Ctrl Alt Del
Even most non-power users know that key combo.
Now, let's say I am a potential customer that thinks 'Java is insecure - I don't want it on my PC'. Your app. comes along, I look at the box, no mention of Java. Good so far. Look at the one or two screenshots of it on the back of the box - looks much like a Windows app., OK.
So I fork out $24.95 for it.
I get it back to the office, install it and run, thinking:
It has an odd feel to it, but I'm too busy now, I'll check it out later.
Then I go surfing off to the net, visit a site infected with malware, and that malware causes MS Word to lock up. So I go to kill MS Word in preparation for restarting it, but.. As I'm scrolling down the available processes I notice.. Java is running.
What the huh..?
I immediately kill every Java process and see.. your app. drop off screen.
Let's go even further to assume the Malware (that is still running) goes on to cause $2000 damage to my hardware & wipes the client database I spent 3 years putting together ($50,000 loss).
I would get on the phone immediately to my lawyer and take you to court, suing you for the sum total of $1,052,024.95.
Later, in court:
Judge: What is the million collars for?
Me: Mental stress, your honor. The defendant lied to me and now I have become paranoid. Since that malware was installed, I've lost my business, my home, my wife and my peace of mind. It has caused me to become deeply depressed and I am experiencing suicidal thoughts.
Who do you think the judge is going to side with? Do you really think you can prove that your app. was in no way responsible for the problem?
Sure, you can put a disclaimer on the box:
No claims of responsibility, use at own risk.
But there are any number of US states as well as other entire countries, that will toss that entire End User Lisense Agreement right out the window and hold you responsible.
What I'm getting at, is that you are taking a huge legal risk to pretend that a Java app. is anything but a Java app. So don't do that!
I am also very keen to know that, as per my knowledge, I deployed my application using JNLP (java network launch protocol) after signing your jar file, Client's jar itself replace with the newer version.
The confirmation question "Do you Accept" in JNLP is because of the certificate windows security and JVM certification didn't recognize that.
here is tutorial for JNLP
http://www.mkyong.com/java/java-web-start-jnlp-tutorial-unofficial-guide/
VBoxManage can do this. But I want to do this myself in my program (to write a robot).
UPDATE: I've answered your other question:
What API does VBoxManage.exe use?
It's a fair amount of overhead to bind to that API if all you want is a screen capture. For that operation, it sounds like you have the tool you need in your hand...VBoxManage is already cross-platform and already built. Look into some form of exec for whatever language(s)/platform(s) you're actually using.
However, if you really want to be doing lots of automation and need more functionality (moving the mouse around, drawing on the guest screen)...that's what the API is for. Though if you don't write it in C++ you're probably setting yourself up for a nuisance.
If I were going down that road, I'd probably follow the VirtualBox build instructions and get VBoxManage to build. Then I'd duplicate the VBoxManage build environment to make MyVBoxManage (or whatever), and tweak it a little at a time.
I've been searching around quite a bit and haven't been able to find any details on how to accomplish what I'm attempting to do. I would like my Java application to "snap/mount/stick" to the top of the screen so that anything opened up after it (for example, power point) would only use the remaining space instead of the entire screen when maximized.
I'm not even sure if it is possible, but if it is could someone point me in the right direction?
Thanks.
You can't do that using standard Java features - only with some native code assistance which should be able to modify other applications behavior, so that they pack themselves into the remaining screen "space". But you will have to code that native part for each OS you want to support. And also you will have to call those native features from Java using JNI. And also some application might act unexpectedly when you will try to modify their size.
Anyway, its a bad idea to do such a "feature" in your Java application - you will have a lot of headache supporting it in future.
I'm going to implement a honeypot for Android Smartphones as a research for my dissertation. I have never used android, java and honeypots. This the way i'm thinking to start this. I thought to use the source code (written in C language) of Honeyd which is a honeypot designed by Mr. Niels Provos. In this case I like to use eclipse 3.7 indigo for java developers. But the problem is even if i convert the source code of Honeyd to java, will the features work same as the way they did in Honeyd. Also I'm going to run android gingerbread (version 2.3) ISO in VMware workstation and try to install the converted Honeyd inside of it as a .apk application. after that i'm going to set up the virtual machine in the network to be attacked. Also I can't set up a physical high interaction honeypot as it is dangerous. so i'm concentrating on setting up a virtual low-interaction honeypot. I have some question dwelling in my head.
1) converting the Honeyd to java 2) Will Honeyd structure work for android platform? 3) As honeypots put on its own network behind a firewall, how to use this step regarding Android? 4) How to give a good alerting mechanism?
Could you please suggest me any help regarding this.
You can probably build the existing C code using the NDK.
The "proper" way would be to build it as a library and call into it from your dalvik (ie, what you code in java) application process. This also makes it easy to use java ui components for an alerting mechanism (otherwise you could have a java app or even something remote on the host that is monitoring the honeypot process for alerts)
While unsupported, many people have also had success building stand-alone command-line executables using the ndk toolchain and launching these. Since you are dealing with a customized android rather than a device, you shouldn't have too many problems with that - you can set OOM killer values on your stand alone process, and if you want you don't even need to run the android framekwork at all - you could just run on the linux that underlies it. Though one might ask what the point of the exercise would then be.
Essentially, if you are on a customized "device" (in this case virtual) and you don't really need any UI, then the only thing really unique about android is having to build C code against the bionic libc rather than a more normal embedded linux one; and even then, you can use a different libc if you statically link.
If you try to use java code to do it, you will likely run into the limitation that there is no good way to grant root access to java code, so you would have to either modify the platform to more easily run custom java code as root, or modify the underlying linux to let unprivileged code open privileged ports.
Frankly, I don't think this is a very good project idea, as you are talking about exposing a specific platform to a threat that probably isn't focused on it.