All geek questions in one place

Java for exe a good or bad idea?

I have long wondered about converting Java projects to EXE .

The benefits depend on a faster deployment on Windows , when the user simply double-clicks the EXE button, and the application starts where Java is located, it should run some commands.

But the EXE really not the one for which Java is intended, for which portability is.

So what do you think Java for EXE is a good or bad idea?

I found an interesting article here .

Update

Wow, so it can still contradict the views. I would like you guys to add the pros and cons of JAVA to EXE.

+6
source share
9 answers

Because my experience is with Java Web Start, which is designed to run desktop applications. with a graphical interface, please think that my advice is mainly aimed at these types of applications.

Other people commented on the specifics of the OS for the EXE. I always need to wonder why people choose Java for developing desktop applications for Windows. Because Visual Studio software for Windows would probably create both a GUI (without x-plat Java layouts to bend its head) and deployments (just guessing that it could create an EXE).

OTOH only you can say what is the best development tool / language for this use case.

Regarding the potential disadvantages of creating an EXE, I note in JavaFAQ on an EXE .

There are a number of good reasons not to pack your application into an executable file. Daniel Sjöblom notes:

  • Most likely, it will not be faster. Modern virtual machines do not interpret bytecodes; in fact, they use the JIT compiler to create their own compiled code. Check out the Sun website for more information on JIT compilers.
  • Static compilation increases the size of your application many times over, since all the libraries you use must be associated with the application.
  • You are losing “free” updates for your program. Anytime a user loads a new faster virtual machine, your application gets acceleration. If you use exe, you will not get this benefit.

John A. Cruz details some of the additional steps in the development process required to create an exe. He points out that developers using native exe should:

  • Confirm the latest version of the compilation product with the vendor. If critical errors are found, they cannot be used to create a delivery product until they are resolved. Work to be performed every time an audit comes from a vendor.
  • Submit your software through a QA cycle. As soon as the engineer thinks that everything is done, they need to be checked. Therefore, each delivery version and product update must go through a full testing cycle.
  • In addition, since the built-in compilation is designed for each target platform, the QA cycle must be performed completely for each target platform, which multiplies the required effort.
  • Shelf. Maybe not so much right now, but maybe.
  • Then it is necessary that all clients are updated to the necessary version. Either there are free updates (in this case, the business must absorb the costs of renewal updates), or, as an alternative, not all customer updates need to be processed.

John notes that: when you send standard Java bytecodes, VM problems are responsible for the VM platform or provider. However, when you send compiled binaries, they become your responsibility (even if they are actually errors in the vendor compilation product).

...

Of course, my first choice is to deploy applications with a rich Java client. uses Java Web Start . Including some advantages / features of a web start as a dot:

JWS provides many attractive features, including but not limited to:

  • screensaver screensavers
  • desktop integration
  • file associations
  • automatic update (including lazy downloads and software update control)
  • splitting Aboriginal and other resources into a platform, architecture, or version of Java,
  • runtime configuration (minimum J2SE version, runtime parameters, RAM, etc.).
  • easy sharing management with extensions ..

I decided to highlight automatic updates with a gradual transition from applications. comes on disk in applications. over the network, automatic updates are becoming more common. JWS still provides a better upgrade experience (very customizable, mostly transparent to the user). I have seen.

And, of course, JWS runs on a desktop OS for which Java is available.

Update

.. Java web applications need an internet connection?

(Note that this is the name "Java Web Start".)

Of course. At least for the initial installation. You can update checks to continue running a previously installed version of the application. if the user is not currently connected.

But then (in my estimation) there are more machines (for example, netbooks) without a CD / DVD drive than without Internet connections. If you want to sell to a wider market, look at the network to deliver the application.

+4
source

It depends on your needs. We have written a small barcode scanner application for our client. They run it on two Windows PCs. They are happy to have their famous exe files. We encoded it in Java and created an EXE file for them.

Both sides are happy with this - so why not do it?

When there are good reasons for this and nothing against it, except dogmatism, then this is good, in my opinion.

+3
source

I am the author of the article you contacted - I'm glad you found it interesting!

As stated in my article, and as others have already noted, there are several ways to simplify the deployment of Java applications - JNLP wrappers, EXEs, installers that combine private JREs, etc. But true native compilation - the only option that also provides protection against Java decompilers - you just don't send bytecodes.

Of course, this does not make reverse engineering and faking your code impossible, but much more expensive in terms of the required set of skills and time.

In terms of application performance, embedded compilation can make a big difference if you target embedded systems. This also applies to memory and disks, albeit to a lesser extent. On the desktop, you will usually get a better launch, but in most other scenarios and aspects, the results will depend on your application.

+3
source

If he has a good reason, why not? Even Eclipse has an EXE for Windows and (and platform-dependent binaries for Linux, Mac, etc.) Of course, you lose portability, but if it doesn't matter, then go ahead.

UPDATE

The question is what do you want to achieve by creating exe:

  • Convenience: users in windows prefer to click on icons, this is especially true for non-geeks. Non-geeks, on the other hand, don't care what the link does inside if it launches exe or something else. You may have an application icon for non-native Java applications. Alternatives would be

  • Performance. If you compile the Java application into your own solution, you can work a little, but it depends on what technology you use. For example, Swing tends to be slow, but compiling what's native is pretty complicated. If you use SWT instead of Swing, which already uses its own components, there is no need for further compilation. On the other hand, recent JVMs work very well and can compile java for native to further improve performance bottlenecks. This is done quietly in the background, you do not need to worry about it.

Sum: in some cases this may be the only solution, but if you choose the right technologies, there will be many alternative Java-based solutions to achieve the same goal.

+2
source

The page after the link in the question is written by a company that sells products that compile java into native code. I would not base the decision on just that.

The question also says that exe has the advantage of an improved user interface, as the user can simply double-click to launch the application.

This is possible with the jar executable. In fact, it's actually quite simple with standard tools in the Java environment. You just need to add the manifest to the jar file and specify the class with the main one 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 screensaver as a resource.

eg.

 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

Netbeans' main ant project will do everything except the spam screen for you if you use it. If for some reason you want to do all this manually, make sure you understand the manifest file format, it's a little thin.

+1
source

Like Linux, mac., Solaris, I think this is a bad idea. If you need a faster deployment on Windows, just create an installer.

0
source

Jar files provide many advantages, including: Compactness: the entire application (i.e. all class files) is stored in a single archive file (which can include images and sound files, if required). Ease of use: the application can be launched by double-clicking. Compression: The jar format allows you to compress your files for efficient storage. Security: you can sign the contents of the jar file digitally. Users who recognize your signature can then grant your software security rights that they otherwise would not have.

I would not convert to exe.

Most Windows applications run from an .exe file (Word, Internet Explorer, FireFox, NetBeans, ...) Java itself does not have support for this, since the executable will then be platform dependent (i.e., it will not work on Mac computers ) However, there are (free) apps that can do this for you.

0
source

Minecraft does this, so it should be a good idea! All the jokes aside, understand that this is not the "conversion" you are looking for, but the use of a custom launcher. The article you tied up pretty well explains the different approaches and pros / cons of each. As a general idea, this requires additional work on creating a launcher (and a different version for each OS architecture), but it gives you a little more control (version checking is a good feature, you can also update the application easily like Minecraft.). All in all, this is a good idea if you think it is worth the effort, and there is a (small) loss in portability.

Edit: The “Custom Java Launchers and Wrappers” approach is the one you should use if you don't need the really great advanced features offered below.

0
source

Depends on the user base. If in any case they are technology-related, then providing them with a .jar file (which can be launched by double-clicking) is a good idea for mobility.

If your users are less tech, but you still need to run them on multiple platforms, then wrap them as exe for Windows and .app for Mac.

It is important . I would suggest making a script to port it to exe, so you run it every time you have a new version.

0
source

Source: https://habr.com/ru/post/905501/

More articles:


All Articles