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/

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 to make a Java Program unextractable

Sorry I am not very sure how to state the question title. My problem is like this, I had developed a Java program, and I wish to distribute it to my friends. So I export it to Jar file, but I don't want them to extract the jar file to view the code. Is there anyway to make the program so that nobody can get the source code instead just launch the program.

You can always get the original code back from compiled class files. However, you can make the lives of those who wish to decompile such code very difficult by using an obfuscator, so the decompiled code is nearly impossible to read. Here is a list of open-source java obfuscators which you might wish to investigate.

If a computer can run it, a human can reverse engineer it.

The term you are looking for is obfuscation. Ultimately
At best, obfuscation merely makes it time-consuming, but not impossible,
to reverse engineer a program.
Another technique is SaaS. Though ultimately using black box techniques SaaS is also reverse-engineerable.
Another technique is trust. Since you are distributing it to your friends, you could ask them to not extract the jar file or view the code. If they are really your friends, they will honor your request.

The truth is that nobody wants your source code. It's pretty arrogant to think that it'd be worth the effort required to keep them out.
The best you can do is obfuscate.

Jar files typically do not contain code. They usually only contain the .class (bytecode) files necessary to run the program.

You appear to be confusing the installation application with the executable. And I also think you are confusing a java jar application with a normal .exe.
Even then, these are all just bundles of code which can still be decompiled, it's just not as easy as unpacking a jar file, which are designed to be easy to extract.
Java is designed to run on the JVM, so packing it inside a .exe is poor form as that immediately locks it onto Windows, which defeats the point of Java in the first place. So I would advice against that.
As everyone has stated, it is rare that if your program works well and you users like it, that they would even think to decompile it. But if they want to they are just a single web search from a how to anyway (regardless of the language). With regards to commercial distribution, most cases the software is obfuscated and distributed in it's .jar, with with a architecture specific launcher of the form .exe, .app, .bin etc. Do not confuse those with the actual executable which is generally a .jar file somewhere.

You could execute part of your program on a server. Basically to execute some important, large and central function of your program, the clients contact your server to compute this function.
Then you can distribute the clients to everybody, and keep the server code for your self. Just keep the server running. Then the others can't get access to whole source, but can execute the software.
This is the only sure way to do this. Other ways can be circumvented in some ways with enough effort.

First steps developing in java applet. Directions

I have to develop a small applet using, of course, java. I am absolutely ignorant about java and the java world. I dont' have the time to learn java "the programming course way". I just need to hack together this thing and then I won't code in java anymore (I assume).
My question is relative to the following subquestions:
is it feasible to code in java without eclipse, maven, etc ? I am pretty sure it is possible, technically, but is it really convenient/practically possible ?
how is the typical build/shipping process for java applets, in particular considering the presence of dependencies ? At the moment I am doing "screaming for vendetta" approach: download the dependencies jars, unpacking them, compiling my own .java file with the applet, repacking everything as .jar, copying it onto the web. I am pretty sure this is not the way to go, but it worked... at least for now. Clearly, I cannot continue this way.
I know Eclipse to be a behemot. how is the chance that I can produce something that works as in my current caveman approach within a couple of days ?
anything else that you deem important
Thanks.

Is it feasible to code in java without
eclipse, maven, etc ? I am pretty sure
it is possible, technically, but is it
really convenient/practically possible
?
Absolutely, you can write code in any text editor, compile with the javac command, and execute with the java command. It's not quite convenient, and Eclipse continuously loops a the build cycle for you.
I know Eclipse to be a behemot. how is the chance that I can produce something that works as in my current caveman approach within a couple of days ?
It's possible you'll be fine, but a little time with a real IDE will start increasing your productivity almost exponentially. To start, you'd be gaining intelligent code navigation, syntax validation, real-time debugging, refactoring support, and of course code completion.

Regarding your first point... yes, it is feasible to code outside an IDE in Java. a copy of your favorite text editor, the javadoc html pages and Ant will do just fine.
That said, you will be more productive in an IDE with Java.

"Back in the day", Eclipse and Netbeans were buggy and no other IDEs were free. So, plenty of people wrote lots of Java code (including me, and including my first applet) without the use of an IDE. You just switch back and forth between your command prompt where you would run javac and your editor-of-choice where you would make changes.
Likewise, build management tools like Ant and Maven are nice for large projects with nontrivial dependencies, but you certainly don't need them to write "Hello, world!" or even a "Hello, world!" applet.
That being said, I don't see any reason not to use an IDE today. They provide plenty of nice features that others here have already mentioned, which can save you from thousands of unnecessary keystrokes and dozens of careless bugs.

Developing without Eclipse or any other IDE (maven is a different kind of beast) is entirely feasible, but not recommended if you are ignorant about the Java world and want to finish everything within a couple of days. So, I suggest that you go with Eclipse. Download the basic Java edition, which is suitable for applet development. Among other things it will allow you to run your applet in an applet viewer (without having to start a browser). This is very convenient for debugging.
About the dependencies, you could create a "fat jar", with everything in it. A plug-in can help you with this. The other solution will be to place the dependencies in a "lib" folder. Then, in your applet jar, you need to edit the manifest file to correctly set the classpath. This is usually done with an Ant target.

Java on OpenVMS?

We run batch files on our OpenVMS Alpha and Integrity servers. Up until now they have been written in COBOL. As you can imagine there are many reasons why will not be able to maintain that process.
At the same time we have a team of developers that use Eclipse and know Java very well. Is there away to use Eclipse with OpenVMS?

Maybe it's because I don't keep up with COBOL, but I am not sure why you're convinced you have to abandon it. I realize it's not the "in" thing, but if you already have a large code base I'd think at least twice before switching to another language. If it's a lack of developers, I don't think you're going to run out that soon.
That said, googling Eclipse & OpenVMS gave this link:
http://www.sdtimes.com/SearchResult/32973
So it looks like you can still get Eclipse for OpenVMS from eCube. If I'm reading that article correctly, HP seems to want you to go the NetBeans directions. Personally, I'm still using Emacs (and not currently doing any Java), so won't make a recommendation; I just wanted to point out that there are other ways to develop Java than Eclipse.
I didn't find Java for VMS on Sun's site (someone feel free to correct me if you find it), but it looks like you can get the JDK from HP/Compaq at:
http://www.compaq.com/java/download/ovms/1.5.0/index.html
Edit: I meant, but forgot to say: Assuming you're using a JVM on the VMS side, you should be able to development with Eclipse on another platform, and copy the byte code to the Alphas.

Speaking from experience, if you do decide to rewrite your batch processes in Java I'd suggest you use a third party batching framework like Spring Batch instead of 'growing your own'.
Using a framework also constrains you to work within a standard and should provide non-functional requirements like re-runability, transactions and error handling.
We've (re)built a number of batch processes from various technologies to Java using a home-grown framework and I find we end up spending time on fixing/optimizing the framework rather than just focusing on the business logic.

Don't leave Cobol yet - call a-cobol-programmer-thinking-about-switching-to-the-modern-world and make a trade: you teach him Java, He maintains your legacy.

Shell scripts and java usually aren't a great mix. You may want to consider installing a JVM on your VMS servers, and using one of the JVM-hosted languages that handle that case better- jython, jruby, or groovy might be candidates to consider.

Eclipse relies on native Java extensions that do not appear to have been ported to OpenVMS. Don't give up though. Java runs on OpenVMS (at least 1.5 according to a Google search).
NetBeans has a Java only edition that should work on OpenVMS. On the NetBeans Download Page select the OS Independent Zip option for the platform.

Are you running the batch files on your OpenVMS system? If so, HP makes Java available for OpenVMS, not SUN; you will have to look at their site. You can develop your java code on a windows/linux machine and test it on your VMS system; you must be aware of the native extensions that you cannot use on the VMS implementation of Java.

Speaking with some experience in this area, I suggest developing with Eclipse on your Windows/Linux/Mac desktop, and pushing the code out to OpenVMS for testing/deployment. Eclipse won't run on OpenVMS because of some platform-specific components of its GUI.
Some caveats:
Make sure that you are using the same version JVM on your desktop as on OpenVMS.
The case insensitivity in OpenVMS can be a problem when using inherently case-sensitive Java .class files. Package everything in a .jar and deploy it that way.
The attributes on .jar files have to be set correctly or the OpenVMS JVM can't open them. The following command should do the trick:
SET FILE *.jar /ATTR=(RFM:STMLF,RAT:CR)
HP provides both a "fast" JVM and a "classic" JVM. Use the fast VM unless your memory needs are highly variable.

I realize this question is rather old, but I was shocked nobody mentioned this book covering Java on OpenVMS.
https://www.theminimumyouneedtoknow.com/java_book.html
What really matters when using an x86 editor on OpenVMS source is your file transfer software. OpenVMS (and many other midrange ASCII based platforms) use even though most PC developers say LineFeed Carriage Return, the data files typically store it in the other order.
You can read much more about that here:
https://www.logikalsolutions.com/wordpress/information-technology/most-text-editors-get-tabs-wrong/
Your file transfer software will need to perform text mode file transfer changing the line ending characters OR your editor needs to both use and respect the better systems line ending characters. I thought there was something in Eclipse (via plug-in) to handle this. Notepadqq claims to have something.
Note this: They use Eclipse for development, not just editing.
That means they are running and debugging in their own PC based Eclipse universe and that ain't how it's going to work on OpenVMS. They are going to need a terminal into the VMS system and it needs to be a REAL VT-100 terminal emulator, not the worthless free stuff. You can read a little bit more about that here:
https://www.logikalsolutions.com/wordpress/information-technology/diamond-edt-keypad-support/
and here
https://www.logikalsolutions.com/wordpress/information-technology/xterm-and-vt-emulation/
Depending on how old your system is, you might have Pathworks installed and running. Then a system manager can create a directory for each user that they can map as a network drive to the PC. This lets the PC user use the directory like any other network disk and it generally could be configured to handle the line ending issues with text files.
There is no way they can develop on OpenVMS using Eclipse. They can edit files then test on OpenVMS, but they cannot develop within the IDE which I suspect is what they really want to do.
The only GUI that ever existed for OpenVMS was DECWindows. You had to run it on either a VAXStation or a DS model Alpha workstation. I never heard of Eclipse being ported to it. In the latest port of OpenVMS to x86 there is no GUI. It is a server only OS.
Yeah, I spent two decades on the platform and even wrote this book for it.

Yes, there is a version of Eclipse that supports OpenVMS called NXTware Remote. It has support for Java and COBOL languages as well as Fortran, Basic and Pascal.

You can edit OpenVMS files using pretty much any editor, including Eclipse - just use Samba to make OpenVMS directories and files visible to desktops on the network. If you install Java for OpenVMS, then you've got folks using Eclipse, and compiling and running on OpenVMS.
As for ditching Cobol - why? There's still a ton of companies running it, and it will certainly last for decades more.