Develop Reference

Does Java Program on XP will run as it is on windows 7

I wanted to know Will the Java desktop application running on Windows XP also run as it is on Windows 7 or need any modification in program?

Theoretically java is platform independent and should run on any Windows, any linux, any mac etc without any modification exactly the same. Practically you have to check that you do not use any platform dependent features or parameters.
For example:
JNI
Execution of platform specific command line tools
Platform specific file paths
Communication with platform specific processes/services
Operations that can produce security issues on some Operating systems (e.g. specific file paths, registry entries under HKLM on windows 7,8 etc)
Assumptions about line, path, file path separators (\r\n vs \n, \ vs '/', ; vs :)
Wrong usage of layout managers that can cause UI to fail on some screen resolutions.

Yes. It will definitely work. Try it and if got any errors send us for review.

Java is Platform Independent.
You can use that application in any OS.
In stand alone application, Java source code is converted into byte code . So Java is platform independent.

Java's claim is to be a WORA (Write Once, Run Anywhere) language.
Assuming that Windows 7's JRE hasn't introduced any new bugs and assuming your code is straight-forward Java that doesn't rely on JNI, manipulating Windows XP specific registry keys, etc., the answer is a definite yes. It should run smoothly.

Yes, thanks for the JVM (Java Virtual Machine) it will act the same on different platforms ...

Vagrant for a Java project: should you compile in the VM or on the host?

Here’s the question: When using Vagrant for a Java project (or any compiled language project for that matter), should you compile in the VM or on the host? Also, would you want your IDE and all your development tools to be run from inside the VM as well, or on the host?
It seems to be not very well defined exactly how a Java IDE and the compile/deploy process work with a Vagrant VM. Generally my impression is that code is edited on the host, and run on the VM, which works great for non-compiled languages. Other answers on Stackoverflow have implied that Vagrant is less useful for compiled languages because of the extra compile step, but I still want to see what can be done.
Some things I’ve thought through already:
Why compile on the VM
if compiling on host, java is one more piece of software to install
if compiling on host, the java version on host must be manually kept up to date with that on the VM
the corresponding java version on the host might be unavailable (say, on a Mac)
Why have IDE on the VM
tighter integration between environment and IDE, can use shortcuts to run the application
can connect debugger for java applications without remote debugging (one step run/debug)
Why compile on the host
faster compile times
want to keep the VM as close to what production looks like as possible
Why have IDE on the host
it’s the vagrant convention to edit code on the host and run it on the VM
better UI performance (X forwarding and VNC are slow)
What are your thoughts: should I run my IDE from inside the VM or the host? Should I compile from inside the VM or the host?

After much thought and experimentation, I've decided on where to use Vagrant and how it integrates with the Java development workflow.
For JavaEE / deployed applications, configuring a web server and a database server are definitely things that have "enough" complexity to warrant the use of Vagrant. With two servers and the myriad ways to configure them, it's easy for configuration to get out of sync from one developer to another, bringing about the "works on my machine" syndrome. For this kind of software, it would work best to edit and compile the code on the host, and deploy to a Vagrant VM that mimics your production environment. The deployment folder for the web server could even be symlinked to a compile target on the host, removing the need to manually redeploy. So Vagrant could be an important part of your development lifecycle, but the cycle time for code/compile/deploy from the host and run on the VM with Java would be longer than the cycle time for code on the host and run on the VM that we see with PHP/Ruby/Node/etc.
For standalone Java applications (like libraries or desktop applications) the story changes a bit. In this case it makes the most sense to edit, compile, and run on the host machine, eschewing the use of Vagrant altogether. If you're using one of the big Java IDE's (Eclipse, Netbeans, IntelliJ...), you already have Java installed on the machine. At that point there is very little advantage compared to the overhead of using Vagrant, and only serves to put an extra layer of complexity in your development process. This is because by the time you are able to edit Java with an IDE you are able to run everything on the host anyway. One issue is that the version of Java required for the project may not match the version running the IDE on the host. In general (hopefully) this is not too much of a problem; as of this writing JDK6 is end-of-lifed and JDK8 is not yet released (guess where that leaves us). But if you did need to run multiple versions, you should be able to set JAVA_HOME on the host as needed. Though this does introduce extra complexity, it is less complexity than maintaining a Vagrant runtime just to work with projects using different versions of Java.
The interesting question is what to do with containerless web applications. Should the web server (in this case internal to the application) be run inside the VM as we did for the external web server? Or run on the host as we did for the standalone application? For containerless web applications, there is no external web server to worry about, but there is still likely a database. In this situation we can take a hybrid approach. Running a containerless web app is essentially the same as running a standalone application, so it would be effective to compile and run your code on the host machine. But with a database involved there is still enough complexity and configuration there that it makes sense to have the database server be on its own Vagrant VM.
Hopefully this gives Java developers who are interested in Vagrant some context about how to use it.

I was interested to this topic during the last year :)
My solution is to have a vagrant machine configurable with flags.
For example one of this flag enable the desktop gui because some developer prefer to code on the host machine while others prefer to have a much more integrated environment with the desktop and the IDE in it.
To face the desktop slowness you should install a very useful vagrant plugin (yeah... vagrant has plugins that greatly improve the development environment) in this way: vagrant plugin install vagrant-vbguest
This plugin will install virtual box guest addition on every guest to make it usable while using the virtualbox interface.
Then to enable the gui edit the Vagrantfile in this way:
config.vm.provider "virtualbox" do |vb|
vb.gui = true
end
Instead to speed-up the shared folder performances I suggest to use rsync:
config.vm.synced_folder "./git", "/home/vagrant/git", type: "rsync", rsync__exclude: ".git/"
In this way the source code is edited on the host and then rsync-ed to the guest.

Virtual mini-Linux distribution that can be run within a unit test on Windows

I would like to automate testing of some remote SSH functionality written in Java. In order to test it for real I would like to have some simple Linux distro against which the test will run. Automated tests though should be able to run on Windows machine. Probably Linux may run in some kind of virtual machine as guest OS and test class may be the one starting and stopping that.
Do any of you know of something similar to this or any alternatives to testing?

I use VirtualBox with Ubuntu installed inside it for any such stuff. The reason being that VirtualBox is ridiculously easy to set up so the virtual machine looks like a different computer with a proper IP address for the local machine (use a "bridged" network interface), and Ubuntu is ridiculously easy and fast to set up (download the image, boot, answer 3-4 questions, walk away, come back 15 mins later).
It also lets you return to the last snapshot in case you totally screw it up.
It runs perfectly well in "seamless" mode too if compositing effects are turned off, i.e. you see the Linux Windows just like any other window on your screen, among the Windows windows.
So really, all the advantages, and hardly a disadvantage.

Cygwin has been around since 1995, and would be perfect for setting up unit testing of this sort of feature under windows, since you can run an sshd in it. See sshd under Cygwin and Cygwin

Free Native Launcher For Java At Linux and Mac

My Java application require a huge memory heap. I need to launch my application using
java -Xms32m -Xmx128m xyz.jar
Hence, I would like to create native launcher for my Java application, where I can pass the JVM heap size parameters in. I plan to use JSmooth http://jsmooth.sourceforge.net/ for Windows platform.
However, I would also like to create native launcher for Linux and Mac. May I know which open source/ free software can help me to do so?
LaunchAnywhere
http://www.zerog.com/iamanual/usermanual_ia55/WebHelp/launchanywhere/abo12e.htm
seem good. But it is a commercial software.
Thanks.

This may not be the answer you want, but I would use an application bundle on MacOS and a simple shell script on linux/unix.
Only reason really is that the end user experience of using web start and or shell scripts on OSX just isn't that great, Mac users expect everything to work like a Mac app bundle.

Hm, you might consider using Java Webstart. It's a bit more than just a launcher, but it can do the things you want. It eases deployment, and you can also install applications manually and use them offline, and it's cross-platform.
Or you can just write a simple launcher shell script. Many apps do that, and it works fine.

Use '/Developer/Applications/Utilities/Jar Bundler' to package your Jar as a Mac app. This makes it easy to specify an icon, launch params for heap size, minimum Java versions, System properties, etc.

Why does Java Web Start not work with 64-bit Java environments?

Java Web Start does not come with 64-bit builds of the JDK. Why is this? What is lacking that keeps it from building and working?

Apparently, there is no reason, since its in JRE6u12. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4626735

Thought you'd might want to know the new update is out:
http://java.sun.com/javase/6/webnotes/6u12.html
64-Bit Browser Support for Java Plugin
and Java Webstart This release
supports the New Java Plugin and Java
Webstart on AMD64 architecture, on
Windows platforms. A Java offline
installer (JRE and JDK) is provided.
Note, if you use 32-bit and 64-bit
browsers interchangeably, you will
need to install both 32-bit and 64-bit
JREs in order to have Java Plug-In for
both browsers.

Mostly its a lack of demand. You only really need 64-bit version if you intend to run more than 1200 MB of memory for a web start client. Otherwise it doesn't make much difference.
Do you know of any examples of a web start application which uses this much memory?

Yes, Javawebstart is not just used to start an app starting from a simple visit of the web via your browser. It is used also for JNLP deployment.
And applications that need MORE than just 2-3 GB are really existing. JavaWebStart DID work in the past to start in 64 bit mode.
But now javawebstart no longer honors the -D64 command line flag given to the command line parameters of the VM (what is even worse is that we are even limited to about 247MB even if we pass the VM parameters -Xmx (which are no longer honored too !!)
Using JNLP applications is now impossible. We need full support of 64 bit mode (and a way to pass VM creation parameters). This is not just a limitation but a severe return to the old ages, with Java VM becoming now extremely slow and swapping.
It looks like the Java documentation is wrong now or the support parameter for it has changed. If you ever have installed some tool that provides associations of JNLP with a command, it is possible that it has changed the mapping using an installation of the 32 bit version only of Javawebstart in \windows\syswow64 (which the Java control panel will not detect and not update), when at the same time you have the latest update instaleld in \windows\system32 with a 64-bit javaws laucnher that suports BOTH 32-bit and 64-bit VMs.
To start java in 64-bit when you have installed both 32-bit and 64-bit versions, you need to check the shortcut created on the descktop or start menu to see that it effectively usees the correct path in \windows\system32 and that the parameter "-J-d64" is present (as well as "-J-Mx=3048m" if you want to increase the maximum size of the VM. Otherwise your VM will be 32 bit and limited to 247 MB !!!
I hate those tools that install and change the Java installation somewhere else, without properly registering them in the Windows registry using a supported installation method (not just for their own use, but trying to change associations of file types.
Anyway there's a bug in the Java control panel for Windows if it does not help restoring the file associations, and does not detect that another JRE has been setup (most often oan outdated version !) And the documentation still incorrectly states that we must use the
folllowing VM parameter "-D64" when it should be "-d64" (the former is just used to define a property with an unset value in the environment).