Answer the question
In order to leave comments, you need to log in
How to convert .jar to .exe on JDK 11?
Hello. I can’t figure out how to compile an exe from .jar on JDK 11... With grief in half, I managed to make a working .jar, which wanted to run only after I also added /bin/ jar to PATH `a with JAVAFX11, which was connected to the project during development (javafx is not supported in JDK 11 for some reason, I had to make a bunch of crutches). By the way, this jar on other computers is launched only if you install the same JDK11 and also register javafx separately. The newest version of the usual custom jre se from the java site for some reason says that the program is written in a newer version of java (Is it like that? Why make JDK 11 and 12, if the site has 8 at all, some kind?). As a result, now I can’t make it all an exe, because all free and shareware programs (Lounch4j, JSmooth, Jet) stupidly do not want to work with such versions of java. Requests 1.6 - 1.8.9. Again, how is this to be understood?
In general, the question is rather that I do not understand all this tinsel with versions and assemblies. Why write something on old versions at all and support them so hard? How to use javafx so that I don't have to constantly tweak something during builds? Why does a project made on JDK 11 start only from it? I didn't find a custom jre on the website of this version... What's the point in desktop development, if you can't even make an exe's output without a bunch of some crutches from the outside? Is there any way for my finished project not to get into production? - Why write it at all then, if it is launched only from your IDE? In general, I don’t understand anything, good people, save me.
Answer the question
In order to leave comments, you need to log in
Well, let's start in order.
Java as a language and environment is extremely conservative and any innovations are usually perceived with hostility. Whether this is good or bad is an extremely delicate question and is always different in the eyes of the consumer. From the enterprise side, this is simply amazing, there is a huge selection of good specialists, there is a huge amount of time to support the desired version that has been tested for years and almost everything is already known about all the subtleties. On the part of small innovators and developers, development is incomprehensibly slow, which means that there is a lag behind the trends and it is significant.
Predicting the question of what kind of nonsense I bring the following fact on version support:
J2SE 1.4 release 2002, end of support 2013
J2SE 5.0 release 2005, end of support 2015
J2SE 6 release 2006, end of support 2018
J2SE 7 release 2011, end of support 2022
J2SE 8 release 2014, end of support 2025
J2SE 9-10 released in 2017/18, passing betas and a key moment in java development and policy where many huge policy changes took place. The license has especially changed, in my opinion, somewhere here and very much, I recommend reading holivars on this topic.
J2SE 11 was released in 2018, end of support in 2026.
If you go into abstraction, I can offer the following illustration. (once again, this is just an illustration for understanding and trying to draw a parallel with something else).
Let's assume that Microsoft is following the same trend as Oracle as well as the whole world of big business. As a result, we have the following: -
the main OS that major players in the software and games market are guided by is winXP.
The world is still ruled by single-threaded but multi-hertz processors that really hit 5GHz. Why change something that is so beautiful in simplicity. We simply reduce the cost and "cool down" production. And in general, the main mass still has stones of level 1 stream and 3.4 GHz. Let's focus on this.
-the world of graphics cards is still ruled by dx9c without newfangled innovations, without cuda\opencl, without dxr, without the volcano\dx12 low-level API approach. Why change something that works so well and has long been known on each side. Video cards have long been resting on the possibility of going from revision to revision with bug fixes and cheaper production. And in general, why something new, because. the main mass still has a graph of the built-in level.
- all sorts of nvme\m2\pcie4 all from the evil one, why is this if the mass user still has sata2 hdd which hardly gives out something in between.
-all monitors have an average of 800x600 pixels, but why more then?
+ As a result, with these orientations, we have a universal product (software / game) that will work for everyone on average perfectly, all possible bugs were known and fixed 10 years ago. Everything is newfangled from the evil one and only among a few enthusiasts, which means we don’t take them into account or take them trying to pass it off as a feature.
Now a few explanations to the above, developers, large naturally, get a huge advantage because. there are many of them, there is a choice, they know and understand what is happening and how, they have a rich experience of how to do it and how not to do it, and most importantly why. The study of the language and version standard is extremely detailed, tons of books, courses, discussions. On the other hand, there are no innovations, everything remains the same as it was 10 years ago, if you want a round button, forget it, or only slow crutches for which they will immediately declare a crutch writer a hand-ass.
I hope the parallel is clear. Now to the question.
Now, I will remind you of 2019, to be honest, I have seen more than a dozen enterprise solutions that are still being developed on jre7. There are those who, gritting their teeth, switch to jre8, but so far, again, my personal observations, it’s just gritting their teeth on the asphalt, very reluctantly, really don’t want to.
Regarding compilation to exe, there is no such thing in the java world. Again, let me explain.
Java is about isolating host hardware from software. Those. Do you have software that is deep purple, how many cores are there, what FS, what OS, etc. .JRE is a "virtual machine" and this is its charm, "there is one binary that works everywhere and who doesn't care where it was launched" the main thing is to have a JRE.
And here comes the joke, there are many JRE implementations themselves, there are paid ones, there are free ones, there are shareware, each has its own license and restrictions. Each one solves its own problems.
So, I'll offer another analogy. Suppose you have created a car that runs on "fuel", everything is great, in your definition of fuel is "everything that burns". In practice, on gasoline, it seems to work and as expected. On a diesel, not so much at all. On aviation, well, the truth does not work for long. It won't even start on hydrogen.
Well, enough around the bush, otherwise he spread demagoguery. Personally, my opinion and practice is that JAVA applications cannot be built at all, once again it is IMPOSSIBLE to build in exe or any other self-sufficient assembly.
Trite, but because you embed the user or YOURSELF into a license or restrictions. Well, for example, you compiled an exe which essentially includes a jre under win10 and threw it off to me, but I have winXP and it doesn’t work, and if it works, then with completely incomprehensible bug logs. If they threw off the jar file marked that it was built under jre7, then there would be no problems from the word at all.
And, by the way, even the built-in java mechanism for assembling so-called native assemblies does not solve the problem of heterogeneity from the word at all.
PS. I hope it was not in vain that I wrote such an essay and conveyed my idea. The idea is based on my observations and experience.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question