Develop Reference

Auto-update of Java application converted to a Windows installable

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/

How to develop a microcontroller software in java with eclipse

I don't know if I've been looking at the wrong place but it seems the documentation for this is very limited on the Oracle website. (Even on google)
I'm working on a school project in which we have to make a software in java and embed it on a micro controler. The program is never actually going to be put on a microcontroller though, we just have to develop it.
I've been looking at the Java SE Embedded, ME Client and ME documentation for the better part of 2 hours now and I still have no idea where to start.
Here's what I need to do.
I would like to develop it in eclipse preferably because it's connected to our repository. (we could use netbeans if it's not possible with eclipse)
We need a way to load the software on a microcontroller. (like an eclipse plugin)
We need to be able to run the program on a UI that we will code to test it and to show our teacher that it works.
We almost had it going with the Java ME Embedded but there is no way to make a UI to test it.
If someone can give me a link to a tutorial or anything would be much appreciated.
Thank you
+++++++++
Edit
+++++++++
I need to specify that we can choose any microcontroller or any range of microcontroller.

Does this need to run directly on the micro or can there be an OS? If you are allowed to run an OS then take a look at the beagle board which has several JVMs available (See http://elinux.org/BeagleBoard#Java)
For a lower cost alternative, Raspberry Pi offers a JVM as well (See http://www.raspberrypi.org/archives/4920)
Both the boards I've listed above are well supported by the community so you should be able to find lots of information by utilizing your favorite search engine.
If you need to run java directly on the CPU, then it appears your options are more limited... A quick search turned up a company called ajile systems who make a CPU module which can directly process java bytecode.

How does Java differ on different platforms?

I am currently in high school. I was recently browsing the internet looking for what employees in the software industry usually want and what the job requirements are like.
I came accros a job description and one of the requirement is:
Strong, object-oriented design and coding skills (C/C++ and/or Java
preferably on a UNIX or Linux platform)
Note the last part: Java preferably on a UNIX or Linux platform.
I don't understand this. Isn't Java run inside a virtual environment/machine? Why would it matter what OS it is running on since Java cannot directly interact with the OS?

A developer job description may require experience with some OS for several reasons:
First, as you noticed already, there are languages that talk directly to the OS and the code needs to be aware of the underlying OS (like C/C++, which are listed in your job description).
Secondly, even if the programming language abstracts away anything that's OS-specific from you (including the file-system / path separators), you are still going to deploy / configure / run / monitor your applications on top of some OS and you need to know (at least) the basics in order to do that.
For a Java job description, If UNIX/Linux "is a plus", it usually means you're going to run your code on a UNIX/Linux system and you should know how to start a process (your own java app or some application server), how to deploy an application in a container, how to read log files and so on...

While Java the language runs on a virtual machine, the Java library must abstract access to facilities available on the host platform. Ideally, these abstractions are cross-platform, but the devil is in the details—hence the preference for experience on a particular target platform.

Develop once debug everywhere
While conceptually it shouldn't make any difference on what target platform the java code is executed on unfortunately in practice it isn't always that simple but a rather tedious task to get the code running on any platform.
Beginning from easy to circumvent mistakes e.g. using / or \ instead of java.io.File.separatorChar or : / ; instead of or java.io.File.pathSeparatorChar
there are most often problems including methods implemented in native code that often aren't that compatible across different platforms.
It might be even possible your employer is looking for someone to implement native java methods using JNI.

First, you're right in that Java runs inside of a virtual machine - it doesn't directly expose the inner workings of the system to you. However, that doesn't mean that each system doesn't differ in some way under the covers - different flavors of operating systems have different kernels, different ways they think about scheduling, different ways to handle threading, and different interrupt chains (Linux has quite a few signals, whereas Windows has a handful).
As far as Java (the language) is concerned, it runs the same everywhere. How it's actually accomplished is dependent on the native JVM that it's running on.
For this job posting, though, I wouldn't read too much into the UNIX/Linux portion. This is more or less gauging how comfortable someone would be working in a UNIX or Linux environment while programming Java. The majority of IDEs available for Java are cross-platform, but that shop may be using Mac or some flavor of *nix (RHEL, Debian, Ubuntu, etc). It'd also be important to make use of the command line/shell script, since a lot of the convenience of working with UNIX/Linux is on the command line.
Not every shop uses Windows machines to develop on. Just a heads-up.

Java does not differ on different platforms. That is the most highlighting feature of Java ( portability ). The JVM abstracts the underlying platform.
However, platform matters when it comes to a software development, which involves not just the coding part. Mostly in industries, devs work on Linux platform by logging into a terminal. You don't get a GUI as in Windows and a good IDE like NetBeans. So in that case, you should know how to compile and run a java program from terminal.
Example, In linux, In order to create a package, you create a directory ( folder ), say myJava/. You go into it (cd myJava) and write the SomeThing.java file and compile using javac SomeThing.java and you get a SomeThing.class file ( inside myJava ). Now in order to execute this, you need to use the java command. Prior using it, you need to move to the parent directory containing this package. Then execute as java myJava.SomeThing. You wouldn't be knowing this unless you play around in Linux platform. Other things like setting up the classpath etc are also matters of concern

Java to EXE good or bad idea?

I have been wondering for a long time about converting Java projects to EXE.
The advantages relies in the faster deployment on Windows where the user simply double clicks the EXE and the application is launched where is with Java, he has to run certain commands.
But EXE is really not what the Java was intended for which is portability.
So what do you think, Java to EXE good or bad idea?
I found some interesting article here.
Update
Wow, so may contradicting views so far. I would like you guys to add the pros and cons of the JAVA to EXE.

Since my expertise is with Java Web Start, which is for launching desktop apps. with a GUI, please consider my advice to be targeted mostly at those types of apps.
Other people have commented on the OS specific nature of an EXE. I always have to wonder why people choose Java to develop Windows specific desktop apps., since the Visual Studio software for Windows would probably make both GUI development (no x-plat Java layouts to bend your head around) and deployment (just guessing it can produce an EXE) easier.
OTOH only you can say what is the best development tool/language for this use-case.
As to the potential disadvantages of creating an EXE, I note at the JavaFAQ on EXEs.
There are a number of good reasons not to package your application in an executable. Daniel Sjöblom notes:
It will probably not be any faster. Modern virtual machines don't interpret bytecodes, they actually employ a JIT compiler to produce native, compiled code. Check Sun's site for further information on JIT compilers.
Static compilation increases the size of your application multifold, since all of the libraries you are using need to be linked into the application.
You lose 'free' upgrades to your program. Anytime your user downloads a new faster virtual machine, your app gets a speed boost. If you are using an exe, you will not get this benefit.
Jon A. Cruz details some of the extra steps in the development process required to create an exe. He points out that developers making native exe's need to:
Validate the latest versions of the compilation product from the vendor. If critical bugs are found, it can't be used to build a shipping product until those are addressed. Work that needs to be done each time a revision comes out from the vendor.
Submit the software through a QA cycle. Once engineering thinks things are done, they need to be verified. So every shipping version and update of a product needs to go through complete testing cycles.
Further, since native compilation is per target platform, the QA cycle needs to be done completely for each target platform, which multiplies effort required.
Shelf space. Maybe not a big deal nowadays, but could be.
Then one needs to get all customers to upgrade to the proper version. Either have free updates (in which case the business needs to absorb the cost of producing updates) or alternatively needs to handle clients not all updating.
Jon notes futher: When you ship standard Java bytecodes, VM problems are the responsibility of the platform or VM vendor. However, when you ship compiled binaries, they become your responsibility (even if they're actually bugs in the vendor's compilation product).
...
Of course, my first choice for deploying Java rich client apps. is using Java Web Start. Putting some of the benefits/features of web-start in point form:
JWS provides many appealing features including, but not limited to:
splash screens
desktop integration
file associations
automatic update (including lazy downloads and programmatic control of updates)
partitioning of natives & other resource downloads by platform, architecture or Java version,
configuration of run-time environment (minimum J2SE version, run-time options, RAM etc.)
easy management of common resources using extensions
..
I decided to highlight auto-update since with the gradual shift from apps. delivered on disk to apps. delivered over a network, auto-update is becoming more common. JWS still provides the best update experience (very configurable, mostly transparent to the user) I've seen.
And of course, JWS works on OS' for desktop PCs for which Java is available.
Update
..does Java web apps require internet connection?
(Note that name is 'Java Web Start'.)
Sure it does. At least for the initial installation. Update checks can be specified to continue to launch the previously installed version of the app. if the user is not currently connected.
But then, (in my estimation) there are more machines (such as Netbooks) with no CD/DVD drive, than there are without internet connections. If you want to sell to the larger market, look to the network to deliver the app.

It depends on your needs. We had written a little barcode client scanner app here for our customer. They run it on two Windows-PCs. They are happy having their well-known exe-files. We coded it in Java and created an EXE-file for them.
Both parties are happy with it - so why not doing it?
When there are good reasons for it and nothing against it except dogmatism then it is ok in my opinion.

I am the author of the article you linked to - glad you've found it interesting!
As my article states, and as others have already pointed out in their answers, there are multiple ways to simplify deployment of Java apps - JNLP, EXE wrappers, installers bundling a private JRE, and so on. But true native compilation is the only option that also provides protection against Java decompilers - you simply do not ship the bytecodes.
Of course, that does not make reverse engineering of and tampering with your code impossible, just much more costly in terms of required skillset and time.
As far as application performance is concerned, native compilation can make a big difference if you target embedded systems. This also applies to memory and disk footprint, albeit to a smaller extent. On the desktop you would typically get better startup, but in most other scenarios and aspects the results would depend on your app.

If it has a good reason why not? Even Eclipse has an EXE on windows and (and platform dependent binaries for linux, mac, etc) Of course you loose portability but if that is not important then go ahead.
UPDATE
The question is what do you want to achieve by creating an exe :
Convenience : users on windows prefer to click on icons, this is especially true for the non geeks. On the other hand non geeks don't care what the link does internally if it starts up an exe or something else. You can have an application icon for non native Java applications too. The alternatives would be
Web start
Creating an installer package,e.g.: http://www.advancedinstaller.com/java.html This can also solve the problem of installing the JRE
Performance : If you compile your Java application into a native solution you may gain a bit on performance but it depends on what technology you use. For example Swing tends to be slow but compiling that to native is rather tricky. If you use SWT instead of Swing that is already using native components therefore no need for further native compilation. On the other hand recent JVMs perform very well and can compile java to native to further improve the performance bottlenecks. This is done silently on the background you dont need to worry about that.
Sum : in some cases it might be the only solution, but if you choose the right technologies there will be many Java based alternative solutions to reach the same goal.

The page behind the link in the question is written by a company that sells products that compile java to native code. I would not base a decision on that alone.
The question also says that the advantage of the exe a better user experience, because the user can just double click to launch the application.
That is possible with executable jar file. In fact, its actually quite easy with standard tools in the java runtime. You just have to add a manifest to a jar file, and specify the class with the main in it. You can also specify other jar files in the classpath relative to the location of the main jar file. You can also specify an image to use as a splash screen as a resource.
e.g.
Class-Path: lib/derby.jar lib/derbytools.jar lib/jcalendar-1.3.2.jar l
ib/joda-time-1.4.jar lib/log4j-1.2.14.jar lib/looks-2.2.1.jar lib/swi
ng-layout-1.0.jar
SplashScreen-Image: resources/splash.png
Main-Class: com.you.pkg.app.Main
The basic ant project in Netbeans will do all but the spash-screen for you if you use it. If your some reason you want to do all of that by hand, make sure you understand the format of the manifest file, its a bit finicky.

As Linux, mac., Solaris user I think this is bad idea.
If you want faster deploy on windows, just create installer.

Jar files provide many benefits including:
Compact: The whole application (i.e. all the class files) is stored in one archive file (which can incorporate image and sound files if required).
Ease of use: The application can be run by double-clicking.
Compression: The jar format allows you to compress your files for efficient storage.
Security: You can digitally sign the contents of a jar file. Users who recognise your signature can then optionally grant your software security privileges it wouldn't otherwise have.
I would not convert to exe.
Most Windows applications run from a .exe file (Word, Internet Explorer, FireFox, NetBeans, ...)
Java itself has no support for doing this as the executable file will then be platform dependent (i.e. it won’t run on Macs)
However, there are (free) applications that can do this for you.

Minecraft does it, so it must be a good idea!
All jokes aside, understand that it's not 'conversion' that you are looking for, but using a custom launcher. The article you linked does a nice job of explaining the different approaches and pros/cons of each. As a general idea, it requires the extra work of creating the launcher (and a different version for each different OS architecture), but it gives you a little more control (version checking is a nice feature, also you may update the application jar rather easily, like Minecraft does). Overall it's a good idea if you think it's worth the effort, and the (little) loss in portability.
Edit: the 'Custom Java Launchers And Wrappers' approach is the one that you should use if you don't need the really nifty extra features offered by those below it.

Depends on the user base. If they are tech-related in anyway then giving them a .jar file (which could be run by double click) is a good idea for mobility.
If your users are less techy but you still need it to run on multiple platforms then wrap it as exe for Windows and as .app for Mac.
Important: I would suggest making a script to wrap it into exe, so you run it each time you have a new version.

How can I distribute my java applications for user ease?

I'm really confused - but really it's pretty wierd because I know two programming langauges but I can't figure out something simple like this...
I've been looking for ages but I can't seem to get my head around it.
You See, for a long time I've been writting in AutoIt, and I've written two programs in it that are due to go on sale soon! They were never meant to be out for a long time though (kind of like Windows Vista), so lately I've been learning Java with success. I've wrote a few very very simple applications in eclipse while going through Java tutorials! I'm now ready to transfer my programs to Java, to gain me a wider market due to Java's cross-platform ability, but I never anticipated distribution to be this complex.
My first problem I have come across is ease of use on multiple OS's: I don't want my customers to have to deal with JRE or multiple files, I need a double click solution that will work on MAC, Windows, Linux, etc so that even complete computer newbie's can launch my software! Secondly, this is not as much a problem as something I am not sure how to do. This is including files in my software package some need to stay seperate from the program but others could be compiled, but actually I suppose this can be worked around by an installer - which would probably be easier! And finally the other proram I made is stand - alone so it can work on USB sticks (which what it was designed for), now, how do you suppose I do this so it will launch on multiple opearating systems when it's plugged in without any hasle?
Update :: Forgot to add :: My concerns about security
I have read and from personal experience I know: how easy it is to decompile a .jar, and if there not protected properly read the source code! I know about obfuscation and I know I'll have legal back up but it just worries me. Even from the point of view that user may get the wrong first impretion of my software.
So to conclude in one sentace (Please read above still):
I need to be able to let people use my software written in Java by double clicking e.g. Like something made in AutoIt - a standard application i.e *.exe
Thanks in advance

There are two routes you can take without needing any extra software involved.
The first is to just make an executable jar (Java Archive) file. Java automatically associates the .jar extension with the Java interpreter on most systems. The JAR's manifest file will tell it which class to launch when you double-click it.
The second, less recommended route, is to make a Java Web Start application, with a JNLP launcher file. The is aimed more at applications distributed from web sites.

I'll suggest the third way: write several platform-specific launch scripts for your application. For example, run.bat for Windows and run.sh for Linux. Inside every script write a command to run JRE with all the necessary parameters. You can also maintain some pre-launch checks (is JRE installed?) or some platform-specific actions in this scripts.