32-bit Windows natives

I've noticed that versions 2.4.0 and 2.5.0 have removed the native libraries for 32-bit Windows. I'd like to upgrade to one of these, but a good fifth of my users still use a 32-bit JVM (because that is distributed by java.com), so I can't feasibly do so.

Is there any way I could convince you to bring back the 32-bit Windows builds? Alternatively, is there a way for me to cross--compile these myself given that I don't have a Windows installation myself to build on?

According to Sven, 32-bit Windows libraries will be built anew for JOGL 2.6.0 but we won't be able to test them.

In my humble opinion, you shouldn't rely on a JRE installed on the system, you can bundle a JRE with your software in order to use a 64-bit JRE on systems supporting it.

Java itself will drop support of 32-bit JDK and JRE, some modules don't support 32-bit architectures anyway (java.lang.foreign) and sticking to an obsolete version of Java is a bad idea for obvious security reasons. You'll have to convince your end users to buy more modern hardware, it's unavoidable.

JEP 449: Deprecate the Windows 32-bit x86 Port for Removal
https://openjdk.org/jeps/449

gouessej wrote

According to Sven, 32-bit Windows libraries will be built anew for JOGL 2.6.0 but we won't be able to test them.

Cool, thanks! I'm suire I'll be able to test them.

gouessej wrote

In my humble opinion, you shouldn't rely on a JRE installed on the system, you can bundle a JRE with your software in order to use a 64-bit JRE on systems supporting it.

I understand that point of view, but I very much appreciate having one single, cross-platform download (in the form of a Jar file). I also appreciate that download being less than 100 MB.

gouessej wrote

Java itself will drop support of 32-bit JDK and JRE, some modules don't support 32-bit architectures anyway (java.foreign) and sticking to an obsolete version of Java is a bad idea for obvious security reasons. You'll have to convince your end users to buy more modern hardware, it's unavoidable.

I'm aware of that, but I'm not sure that will become what is distributed on java.com any time soon. :)

gouessej wrote

You'll have to convince your end users to buy more modern hardware, it's unavoidable.

Just FYI, it's not about the hardware, it's just that the JRE itself is the 32-bit variant, running on modern hardware. Again, because that's what java.com sometimes distributes by default.

A single "executable JAR" is a poor option, it has many limitations (you can use only options supported in the manifest or you have to provide a platform-dependent script to run the JAR, the JRE must be installed on the system, there must be no conflict with another software able to open a JAR including archivers, etc) and you can use modules with jpackage and jlink to bundle a minimized JRE. By the way, Adoptium already provides JREs whose size is around 150 MB and that includes Swing support.

I remind you that OpenJDK is the reference implementation of Java since its version 7. In other terms, when Java 32-bit support dies, it will die for both OpenJDK and Oracle Java. Rather complain to Oracle if it still suggests to download 32-bit JREs for hardware supporting 64-bit JREs.

Running a 32-bit variant on a 64-bit operating system is useless as long as you can specify options for the virtual machine to use less memory so that it continues to work on machines with a little RAM.

Time has changed, only a few end users accept installing a JRE, some of them don't update the JREs, relying on the JRE installed on the system is not a viable option on the long term. It was viable but problematic 20 years ago. Imagine that an end user installed  Java 8 but you need to use some APIs and/or to benefit of bug fixes available only in Java 11, you'll have to rewrite your source code not to fall into this situation. Maybe you're not even aware of such bugs, one of them affects the stream API appeared in Java 8.

I hardly see how to use Java >= 9 with JOGL without passing VM arguments and by providing a single fat JAR for all operating systems. When a GNU Linux user downloads a package for its distribution or when an OS X user downloads an .app file, as they are more familiar with that, it produces less friction than providing a JAR generally. Providing programs written in Java in 2023 to the public is already difficult when lots of them are accustomed with stores and online programs with no install, we won't convince them if we don't make things easy for them and a single fat JAR for everybody is not a reliable solution. If it worked reliably, yes, it would be awesome.

gouessej wrote

A single "executable JAR" is a poor option

Poor or not, as far as I'm aware, it's pretty much the only option if I want a single download.

gouessej wrote

you can use only options supported in the manifest

It should perhaps be noted that my current downloadable Jar is just a launcher program, which downloads the rest of the program (and keeps it updated on a per-file basis), and relaunches the JVM with any custom args I might want. One nice thing about that is that the direct download is less than 100 kB, which is particularly nice since I've made it so that the download includes a login cookie for immediately logging in as the same user as was logged in on the website when downloaded. Being a single, very small download means that it can be "throw-away", easily re-download if misplaced or lost, or the login cookie expires, or in any other similar event. 100 kB and 100 MB is a big difference in that regard.

gouessej wrote

I remind you that OpenJDK is the reference implementation of Java since its version 7. In other terms, when Java 32-bit support dies, it will die for both OpenJDK and Oracle Java.

Well aware, I'm just saying that 32-bit support will only be removed in the versions following when that happens, and java.com is clearly not distributing the latest version.

gouessej wrote

Time has changed, only a few end users accept installing a JRE

While I can see that being the expectation, it actually hasn't been a huge problem for me. I have had exceedingly few complaints about that.

gouessej wrote

but you need to use some APIs and/or to benefit of bug fixes available only in Java 11, you'll have to rewrite your source code not to fall into this situation.

Since I've already been supporting Java 8 since forever, I'm not in a position where I need to rewrite my source code.

Dolda2000 wrote

Poor or not, as far as I'm aware, it's pretty much the only option if I want a single download.

Feel free to reconsider your expectations. A clean download page detecting the operating system and suggesting only a single program to download could be an acceptable compromise, couldn't it? Don't hesitate to ask for help.

Dolda2000 wrote

It should perhaps be noted that my current downloadable Jar is just a launcher program, which downloads the rest of the program (and keeps it updated on a per-file basis), and relaunches the JVM with any custom args I might want. One nice thing about that is that the direct download is less than 100 kB, which is particularly nice since I've made it so that the download includes a login cookie for immediately logging in as the same user as was logged in on the website when downloaded. Being a single, very small download means that it can be "throw-away", easily re-download if misplaced or lost, or the login cookie expires, or in any other similar event. 100 kB and 100 MB is a big difference in that regard.

You mitigate the problem I mentioned a bit yes, but your launcher program is still limited to the options available in the manifest. Moreover, your launcher program won't work without a compatible JRE installed on the system and it's technically possible to create a launcher program that wouldn't be a single executable JAR (for example by using Nullsoft Scriptable Install System). The difference between 100 KB and 100 MB is big when the network isn't very good but if your launcher program has to download some assets, won't it have to download megabytes anyway?

Dolda2000 wrote

While I can see that being the expectation, it actually hasn't been a huge problem for me. I have had exceedingly few complaints about that.

I don't want to be a killjoy but the end users who fail to run your program because they haven't installed a JRE might not complain at all, it doesn't mean that the problem doesn't exist.

gouessej wrote

A clean download page detecting the operating system and suggesting only a single program to download could be an acceptable compromise, couldn't it?

I've seen other sites do that, and I've always thought it's an ugly solution. For example, sometimes you want to download a file on one system and run it on another, and even when that's not the case, OS detection is heuristic at best. In addition, if you just get an EXE file automatically, you might fool people into thinking that it's a Windows-only program.

gouessej wrote

but your launcher program is still limited to the options available in the manifest.

Admittedly true, but I fail to see when that could possibly be a problem.

gouessej wrote

The difference between 100 KB and 100 MB is big when the network isn't very good but if your launcher program has to download some assets, won't it have to download megabytes anyway?

To begin with, all my assets taken together still use far less than a full JRE -- I think it's currently somewhere around 30 MB. But also, again, since it's sometimes desirable to re-download the launcher and to consider it somewhat throw-away, that's still enough reason for me to try and keep it as small as possible. I consider the launcher a replacement for JNLP, which I still find unfortunate that it went away.

gouessej wrote

I don't want to be a killjoy but the end users who fail to run your program because they haven't installed a JRE might not complain at all, it doesn't mean that the problem doesn't exist.

I'd expect there to at least exist a subset of users who would complain, but I can't recall seeing a single complaint ever. There have been requests to be on some common app-stores (which I resent), but none about Java being required.

I'll admit it's not as it was 15 years ago when some prebuilt computers came with Java preinstalled, but in my experience it's not that bad, at least not yet.

It would be nice if there were some executable file format that were supported out of the box on all the common platforms, but until such time as that is the case, I find Java to be the least bad approximation.

Dolda2000 wrote

I've seen other sites do that, and I've always thought it's an ugly solution. For example, sometimes you want to download a file on one system and run it on another, and even when that's not the case, OS detection is heuristic at best. In addition, if you just get an EXE file automatically, you might fool people into thinking that it's a Windows-only program.

It's quite cleanly done on sourceforge.net, you can suggest a package for the detected platform while displaying the support of some other platforms. If you find that not convenient or misleading, you can show all files of all platforms and simply highlight the one that suits the most or let the user choose. As long as you don't suggest too many files, the end users won't be lost. If your audience is mostly composed of technical users, it won't be a problem.

Dolda2000 wrote

gouessej wrote

but your launcher program is still limited to the options available in the manifest.

Admittedly true, but I fail to see when that could possibly be a problem.

You don't have the control on the available memory for your launcher program. If you target machines supporting 64-bit JREs but using 32-bit JREs because of the lack of memory, you'll have to hope that your launcher program doesn't use too much memory, such a problem can happen in other circumstances.

Dolda2000 wrote

To begin with, all my assets taken together still use far less than a full JRE -- I think it's currently somewhere around 30 MB. But also, again, since it's sometimes desirable to re-download the launcher and to consider it somewhat throw-away, that's still enough reason for me to try and keep it as small as possible. I consider the launcher a replacement for JNLP, which I still find unfortunate that it went away.

I used Java WebStart for years, it was quite buggy, making it work everywhere was nearly impossible. Yes you're right especially if you use Swing, it will be difficult to minimize a JRE to get something under 30 MB.

Dolda2000 wrote

I'd expect there to at least exist a subset of users who would complain, but I can't recall seeing a single complaint ever. There have been requests to be on some common app-stores (which I resent), but none about Java being required.

I'll admit it's not as it was 15 years ago when some prebuilt computers came with Java preinstalled, but in my experience it's not that bad, at least not yet.

It would be nice if there were some executable file format that were supported out of the box on all the common platforms, but until such time as that is the case, I find Java to be the least bad approximation.

I understand your position about app-stores, I refuse using them too. I don't advise to abandon Java, I suggest to avoid expecting non technical users to have a compatible JRE installed on the system.

gouessej wrote

It's quite cleanly done on sourceforge.net, you can suggest a package for the detected platform while displaying the support of some other platforms. If you find that not convenient or misleading, you can show all files of all platforms and simply highlight the one that suits the most or let the user choose.

In my case, I don't even have a separate download page to offer multiple choices right now, the download link is just part of the site navigation menu, and I like the cleanliness of that. Having to add a separate download page would feel like a downgrade to me.

gouessej wrote

If your audience is mostly composed of technical users, it won't be a problem.

Just to be clear, I think most of my users are not particularly technical. Haven't run a survey or anything, but that's my impression.

gouessej wrote

You don't have the control on the available memory for your launcher program. If you target machines supporting 64-bit JREs but using 32-bit JREs because of the lack of memory, you'll have to hope that your launcher program doesn't use too much memory, such a problem can happen in other circumstances.

I can't see that being a problem. The launcher itself doesn't even use a MB of heap space, so if the JVM is capable of running Swing at all, it can certainly run the launcher.

gouessej wrote

I used Java WebStart for years, it was quite buggy, making it work everywhere was nearly impossible.

I have to say I never had that much problem with it. My only real issue was when Oracle decided to refuse self-signed certificates; that's when I started considering replacing it with my own launcher. The only other issue I remember having was that the persistence service didn't scale with the number of files stored and became unusably slow after a couple of hundred of files. To be clear, I think my current launcher is mostly better, but I did like having just a tiny text file as the primary download.