Modify

Opened 5 years ago

Last modified 3 weeks ago

#17858 assigned enhancement

OpenWebStart/Java 17 migration

Reported by: Don-vip Owned by: Don-vip
Priority: major Milestone: Longterm
Component: Core Version:
Keywords: java11 adoptopenjdk icedtea-web java17 Cc: Bjoeni

Description (last modified by taylor.smock)

Things are starting to take shape with what comes after Java WebStart (see #16047):

https://openwebstart.com/

Original 2019 plan:

On the current roadmap, the first version will be released end of October. A macro planning for a Java 8 => Java 11 transitions for all JOSM users would roughly look like this:

  • September 2019: we start testing OpenWebStart on all platforms. Likely we'll found a lot of bugs
  • November 2019 : first OpenWebStart version. Unlikely to fix all bugs we'll find
  • Somewhere in 2020: OpenWebStart version without any bug impacting us, we start asking everyone to switch
  • End of 2020: End of Java WebStart support by Oracle for Java 8. We force everyone to switch
  • Somewhere in 2021: Enough JOSM users have switched to OpenWebStart so we can consider moving the codebase to Java 11.

New 2021 plan:

  • 2021-03-28: ask Oracle Java WebStart users to switch to OpenWebStart => r17679
  • 2021-08-22: new Windows package that includes Java 16 => r18151:18155
  • 2021-08-22: include JavaFX 16 in macOS and Windows packages => r18161
  • 2021-08-22: update JNLP files to request Azul JVM from OpenWebStart as it includes JavaFX => r18158:18159
  • 2021-08-22: update Debian/Ubuntu launch script to depend on openjfx => r18160
  • 2021-09-15: Java 17 is released. Switch macOS / Windows packages to Java 17 and JavaFX 17, update Debian/Ubuntu launch script to prefer 17 over 11 and 8 => r18225
  • 2022-04-21: Ubuntu 22.04 LTS is released and ships Java 17 (note: default-jre is Java 11)
  • 2022-11-25: OpenWebStart adds Java 17 to their JVM list => done
  • somewhere in 2023/2024: Enough JOSM users are now using Java 17+ so we can consider moving the codebase to Java 17.
  • 2024-04-xx: Ubuntu 24.04 LTS is released and ships Java 17+ as default; Debian Bookworm already ships Java 17 as default.

Java 21 followup: #23564

Attachments (9)

rockets_win.png (4.0 KB ) - added by Don-vip 3 years ago.
rocket_dark.png (4.4 KB ) - added by Don-vip 3 years ago.
Screenshot 2021-03-27 at 12.23.47.png (30.8 KB ) - added by simon04 3 years ago.
Screenshot 2021-03-27 at 14.08.28.png (130.3 KB ) - added by simon04 3 years ago.
dialog.png (32.4 KB ) - added by Don-vip 3 years ago.
dialog2.png (29.9 KB ) - added by Don-vip 3 years ago.
Screenshot 2021-04-02 at 00.29.33.png (93.0 KB ) - added by simon04 3 years ago.
17858.auto_module_name.patch (935 bytes ) - added by taylor.smock 3 years ago.
Add automatic module name -- #15229 seems to indicate we'll want a lot of subpackages, but it may be useful to say "hey, we will be using this base module name"
17858.patch (8.3 KB ) - added by taylor.smock 19 months ago.
Warn on Java < 11 when not run under OpenWebStart, update URL to point at azul and pre-fill fields to decrease user confusion, Utils.getJavaLatestVersion uses Java 11 (WebStart) and Java 17 for latest Java versions

Download all attachments as: .zip

Change History (204)

comment:1 by Don-vip, 5 years ago

First problem: #17632

comment:2 by Don-vip, 5 years ago

Keywords: adoptopenjdk icedtea-web added

comment:3 by Don-vip, 5 years ago

First alpha version (0.2.0) is available for download: https://openwebstart.com/download/

comment:4 by Don-vip, 5 years ago

Milestone: Longterm

comment:5 by mdk, 4 years ago

Version 1.1.1 is released (at 16.12.2019)

comment:7 by Don-vip, 4 years ago

AdoptOpenJDK API now available through https://josm.openstreetmap.de/remote/adoptopenjdk-api/ (#18723)

comment:8 by Don-vip, 4 years ago

https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes/

As of 18.04.4, OpenJDK 11 is the default in 18.04.

OpenJDK 8 has moved to universe and will remain available there for the life of 18.04, to provide migration time for packages, custom applications, or scripts that can't be build with OpenJDK 11. OpenJDK 8 will be updated in 18.04 until Ubuntu 16.04 LTS reaches EOL in April 2021.

comment:10 by Don-vip, 4 years ago

AdoptOpenJDK officially refused to ship OpenJFX in their binary distributions:
https://github.com/AdoptOpenJDK/TSC/issues/27#issuecomment-607663428

So the best distribution for us would be Azul Zulu and Bellsoft's Liberica.

comment:11 by taylor.smock, 4 years ago

Another issue: #19044 (Azul Zulu 11.0.6/AdoptOpenJDK 11.0.6). It looks like jdk.swing.interop.SwingInterOpUtils doesn't exist, for whatever reason. Oddly enough, it is never directly called by us (its called by JFXPanel, which is in the java distribution). I haven't filed a bug upstream, since I haven't run with a "standard" version of Azul Zulu yet.

EDIT: Not reproducible with Azul Zulu or AdoptOpenJDK from CLI.

Possibly related to https://github.com/AdoptOpenJDK/IcedTea-Web/issues/595 .

Last edited 4 years ago by taylor.smock (previous) (diff)

comment:12 by mdk, 4 years ago

It looks like ​https://github.com/AdoptOpenJDK/IcedTea-Web/issues/595 is fixed in the actual release 1.1.7

comment:13 by jBeata, 4 years ago

Do you have a more clear deadline for moving the code-base to Java11? It will happen in the first half of 2021 or the second?

in reply to:  13 comment:14 by stoecker, 4 years ago

Replying to jBeata:

Do you have a more clear deadline for moving the code-base to Java11? It will happen in the first half of 2021 or the second?

Usually when less than 5% of our users use older versions. Currently 70% of our users use Java 8. About 20% use Java 11.

comment:15 by Don-vip, 4 years ago

Oracle changed again their plans concerning Java 8. It was previously expected they stop releasing public updates of Java 8 on java.com (the version used by nearly all our Windows users) at the end of 2020.

Now the plan is:

Oracle will continue to provide free public updates and auto updates of Java SE 8 indefinitely for Personal, Development and other Users via java.com. Oracle will provide at least 18 months notice on this page and other communication channels if an end of availability date is set. [...]
Oracle does not plan to migrate desktops from Java SE 8 to later versions via the auto update feature. This includes the Java Plugin and Java Web Start. [...]

So we won't see any major decrease of Java 8 usage until we force this change by promoting OpenWebStart and Java 11 to our users. I didn't start to work on this yet.

Given on our past experience, it takes months between the time we start to deprecate a version of Java and the time enough people abandoned it, so I wouldn't see a Java 11 migration before Q2 2021 at best.

in reply to:  15 comment:16 by stoecker, 4 years ago

Replying to Don-vip:

Q2 2021 at best.

Still very optimistic. Q4 2021 or later seems more realistic ;-) Even Linux has still about 30% Java 8.

P.S. Added --os option to our checkjosm tool :-)

comment:17 by Don-vip, 4 years ago

I meant S2, with Q4 in mind actually :)

comment:18 by jBeata, 4 years ago

Thanks for the clarification. We also use Java 8 since the minimum version for running JOSM is Java 8. But we plan to switch as soon as JOSM main version is updated to 11.

comment:19 by Don-vip, 3 years ago

Current numbers:

Java Main Version --> 8 (7174, 67.6%) 9 (21,  0.2%) 10 (24,  0.2%) 11 (2130, 20.1%) 12 (167,  1.6%) 13 (248,  2.3%) 14 (299,  2.8%) 15 (532,  5.0%) 16 (10,  0.1%) 17 (7,  0.1%)

I'm really happy to see that OpenWebStart really kicks in: several versions released, 5 companies seem to sponsor Karakun on front page, nearly 200 developers have starred the project on GitHub. Software is now available on Windows, mac and Linux. It's a complete and viable replacement to Oracle WebStart.

I'll see how to detect Oracle WebStart and suggest users to switch to OpenWebStart. At the same time they do that, they'll switch from Oracle JRE 8 to Azul JRE 11.

@Dirk would it be possible to update checkjosm to get vendor stats? I'd like to see the percentage of users running an Oracle runtime versus those who do not.

comment:20 by stoecker, 3 years ago

That information isn't available in the User-Agent, so I can't display it :-)

in reply to:  20 comment:21 by Don-vip, 3 years ago

Replying to stoecker:

That information isn't available in the User-Agent, so I can't display it :-)

Ah, I thought it was sent. I'll check only Java 8 then. Should be the same thing.

comment:22 by Bjoeni, 3 years ago

Cc: Bjoeni added

comment:23 by Don-vip, 3 years ago

I just fixed #18737 which was the only blocker to OpenWebStart migration. Let's get rid of Oracle Java WebStart.

by Don-vip, 3 years ago

Attachment: rockets_win.png added

by Don-vip, 3 years ago

Attachment: rocket_dark.png added

comment:24 by Don-vip, 3 years ago

Vote for your preferred rocket icon! Which one looks the best? 1, 2, 3, 4?



comment:25 by simon04, 3 years ago

I vote for 4️⃣ :-)

comment:26 by simon04, 3 years ago

Awesome, successfully tested (ticket #18737) on macOS! On Windows and macOS the status report lacks any indication that JOSM is running via webstart:

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2021-03-26 22:41:31 +0100 (Fri, 26 Mar 2021)
Revision:17674
Build-Date:2021-03-27 02:30:56
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (17674 en) Mac OS X 10.16
OS Build number: macOS 11.2.3 (20D91)
Memory Usage: 410 MB / 2048 MB (171 MB allocated, but free)
Java version: 16+36, Azul Systems, Inc., OpenJDK 64-Bit Server VM
Look and Feel: com.formdev.flatlaf.FlatLightLaf
Screen: Display 1 1440×900 (scaling 2,00×2,00) Display 2 3008×1692 (scaling 2,00×2,00)
Maximum Screen Size: 3008×1692
Best cursor sizes: 16×16→16×16, 32×32→32×32
VM arguments: [--add-modules=java.scripting,java.sql, --add-exports=java.desktop/com.apple.eawt=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=javafx.graphics/com.sun.javafx.application=ALL-UNNAMED, --add-exports=jdk.deploy/com.sun.deploy.config=ALL-UNNAMED, --add-opens=java.base/java.lang=ALL-UNNAMED, --add-opens=java.base/java.nio=ALL-UNNAMED, --add-opens=java.base/jdk.internal.loader=ALL-UNNAMED, --add-opens=java.base/jdk.internal.ref=ALL-UNNAMED, --add-opens=java.desktop/javax.imageio.spi=ALL-UNNAMED, --add-opens=java.desktop/javax.swing.text.html=ALL-UNNAMED, --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED, -Djava.util.Arrays.useLegacyMergeSort=true, --add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED,java.desktop, --add-exports=java.base/jdk.internal.util.jar=ALL-UNNAMED,java.desktop, --add-exports=java.base/com.sun.net.ssl.internal.ssl=ALL-UNNAMED,java.desktop, --add-reads=java.naming=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.awt.X11=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.applet=ALL-UNNAMED,java.desktop,jdk.jsobject, --add-exports=java.base/sun.security.action=ALL-UNNAMED,java.desktop, --add-reads=java.base=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED,java.desktop, --add-exports=java.naming/com.sun.jndi.toolkit.url=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.util=ALL-UNNAMED,java.desktop,ALL-UNNAMED, --add-reads=java.desktop=ALL-UNNAMED,java.naming, --add-exports=java.desktop/sun.awt=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.x509=ALL-UNNAMED,java.desktop,ALL-UNNAMED, --add-exports=java.desktop/javax.jnlp=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.provider=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.validator=ALL-UNNAMED,java.desktop]

Plugins:
+ ImportImagePlugin (35567)
+ apache-commons (35524)
+ ejml (35458)
+ flatlaf (35703)
+ geotools (35458)
+ jts (35458)
+ log4j (35458)

This statement might help us to identify OpenWebStart:

Class.forName("com.openwebstart.launcher.OpenWebStartLauncher")

in reply to:  24 comment:27 by skyper, 3 years ago

Replying to Don-vip:

Vote for your preferred rocket icon! Which one looks the best? 1, 2, 3, 4?

I like 1 or 4. Maybe, the dark brown on the outside wings could be a bit lighter. With the dark mode icons need to respect dark and light background and often contrasting outlines like 1 and 2 show are helpful.

comment:28 by simon04, 3 years ago

When starting, OpenWebStart shows this information message:

App name on macos screen menu is Boot · Issue 325 · karakun/OpenWebStart · https://github.com/karakun/OpenWebStart/issues/325

in reply to:  26 ; comment:29 by Don-vip, 3 years ago

Replying to simon04:

This statement might help us to identify OpenWebStart:

Class.forName("com.openwebstart.launcher.OpenWebStartLauncher")

I plan to use this (not tested yet):

    /**
     * Determines whether JOSM has been started via Web Start (JNLP).
     * @return true if JOSM has been started via Web Start (JNLP)
     * @since xxx
     */
    public static boolean isRunningWebStart() {
        try {
            // See http://stackoverflow.com/a/16200769/2257172
            return Class.forName("javax.jnlp.ServiceManager") != null;
        } catch (ClassNotFoundException e) {
            return false;
        }
    }

    /**
     * Determines whether JOSM has been started via Oracle Java Web Start.
     * @return true if JOSM has been started via Oracle Java Web Start
     * @since 15740
     */
    public static boolean isRunningJavaWebStart() {
        return isRunningWebStart() && Package.getPackage("com.sun.javaws") != null;
    }

    /**
     * Determines whether JOSM has been started via Open Web Start (IcedTea-Web).
     * @return true if JOSM has been started via Open Web Start (IcedTea-Web)
     * @since xxx
     */
    public static boolean isRunningOpenWebStart() {
        return isRunningWebStart() && Package.getPackage("net.adoptopenjdk.icedteaweb") != null;
    }

by Don-vip, 3 years ago

Attachment: dialog.png added

comment:30 by Don-vip, 3 years ago

This is the upgrade text I came with. Comments?


For the icon, I've started a poll on Twitter as well, I hope a clear winner comes out :D

in reply to:  29 comment:31 by Don-vip, 3 years ago

Replying to Don-vip:

    public static boolean isRunningOpenWebStart() {
        return isRunningWebStart() && Package.getPackage("net.adoptopenjdk.icedteaweb") != null;
    }

And we should also be aware of upcoming changes that will probably affect package names for ITW https://blog.adoptium.net/2021/03/eclipse-adoptium-announcement/

in reply to:  30 ; comment:32 by simon04, 3 years ago

Replying to Don-vip:

This is the upgrade text I came with. Comments?

Two small suggestions:

-Oracle implementation (2x)
+an Oracle implementation

-as a new product: OpenWebStart.
+as a new product: OpenWebStart

What is the difference between "OK" and "Download OpenWebStart"?

You you plan to add this dialog for the 21.03 release (I'm referring to i18n)?

in reply to:  32 comment:33 by Don-vip, 3 years ago

Replying to simon04:

Two small suggestions:

-Oracle implementation (2x)
+an Oracle implementation

-as a new product: OpenWebStart.
+as a new product: OpenWebStart

Thanks.

What is the difference between "OK" and "Download OpenWebStart"?

OK does nothing, it just closes the dialog. It's the same behaviour as current MainApplication.askUpdateJava dialog.

You you plan to add this dialog for the 21.03 release (I'm referring to i18n)?

Yes, tomorrow evening.

in reply to:  30 comment:34 by stoecker, 3 years ago

Replying to Don-vip:

This is the upgrade text I came with. Comments?

Remove the remaining sentence after "Java 11" and join the two sentences with "but".

I'd vote for icon 4 (icon 1 is second place).

by Don-vip, 3 years ago

Attachment: dialog2.png added

comment:35 by Don-vip, 3 years ago

New version taking into account Simon and Dirk feedback:


comment:36 by simon04, 3 years ago

Looks good! 👍🏿

comment:37 by stoecker, 3 years ago

Actually I meant to join the first two sentences, but this is even better ;-)

comment:38 by Don-vip, 3 years ago

Good :) Thank you :)

comment:39 by Don-vip, 3 years ago

In 17679/josm:

see #17858 - ask Oracle Java WebStart users to switch to OpenWebStart

Rocket icon from https://github.com/twitter/twemoji/blob/v13.0.2/assets/svg/1f680.svg

comment:40 by simon04, 3 years ago

Java Warnings (Package.getPackage is deprecated since Java 9):

/Users/simon/src/josm/src/org/openstreetmap/josm/tools/Utils.java:1742: warning: [deprecation] getPackage(String) in Package has been deprecated
        return isRunningWebStart() && Package.getPackage("com.sun.javaws") != null;
                                             ^
/Users/simon/src/josm/src/org/openstreetmap/josm/tools/Utils.java:1751: warning: [deprecation] getPackage(String) in Package has been deprecated
        return isRunningWebStart() && Package.getPackage("net.adoptopenjdk.icedteaweb") != null;
                                             ^

comment:41 by Don-vip, 3 years ago

In 17692/josm:

see #17858 - fix deprecation warnings

in reply to:  28 comment:42 by simon04, 3 years ago

Replying to simon04:

When starting, OpenWebStart shows this information message:

"The proxy 'System proxy' does not support 'Passive FTP Mode (PASV)'"

Only affects macOS, see https://github.com/karakun/OpenWebStart/blob/26c8990af7f2214b290d1056cd27a7f78f4477a6/openwebstart/src/main/java/com/openwebstart/proxy/mac/MacProxyProvider.java#L36-L38

Fixed by selecting "No Proxy" in the OpenWebStart Settings:


comment:43 by gaben, 3 years ago

On Windows, the WebStart dialogue pops up and not steals the focus, sometimes resulting in a JOSM 'loading' indefinitely. The same applies to Java update notification windows. The only way to resolve is to click somewhere on the splash screen.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2021-04-01 23:17:01 +0200 (Thu, 01 Apr 2021)
Build-Date:2021-04-01 21:46:03
Revision:17702
Relative:URL: ^/trunk

Identification: JOSM/1.5 (17702 hu) Windows 10 64-Bit
OS Build number: Windows 10 Pro for Workstations 2009 (19042)
Memory Usage: 912 MB / 1820 MB (719 MB allocated, but free)
Java version: 1.8.0_281-b09, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 1920×1200 (scaling 1,00×1,00)
Maximum Screen Size: 1920×1200
Best cursor sizes: 16×16→32×32, 32×32→32×32
System property file.encoding: Cp1250
System property sun.jnu.encoding: Cp1250

comment:44 by nkamapper, 3 years ago

I have an old iMac running High Sierra, which is not supported by OpenWebStart. The iMac cannot be upgraded to a newer OS. Is there a way to get an earlier version of josn.jnlp, which would work?

comment:45 by skyper, 3 years ago

Not on the official side, I guess, but note, *.jnlp are text files which can be modified and created with any text editor.

Another solution is to use .jar files directly. Starting should work from file manager or with java -jar path/filename from the console or with a simple start script including the java command. See Download.

comment:46 by Don-vip, 3 years ago

We will only support OpenWebStart for JNLP. However in your case you can use the macOS build directly instead of WebStart. There is also the brew cask package on macOS.

in reply to:  19 comment:47 by taylor.smock, 3 years ago

Somewhere in 2021: Enough JOSM users have switched to OpenWebStart so we can consider moving the codebase to Java 11.

Replying to Don-vip:

Current numbers:

Java Main Version --> 8 (7174, 67.6%) 9 (21,  0.2%) 10 (24,  0.2%) 11 (2130, 20.1%) 12 (167,  1.6%) 13 (248,  2.3%) 14 (299,  2.8%) 15 (532,  5.0%) 16 (10,  0.1%) 17 (7,  0.1%)

Have these numbers changed significantly? As in, will we be able to move to Java 11 somewhere in 2021, or is it going to be somewhere in 2022?

comment:48 by stoecker, 3 years ago

Looks still similar (I stripped the absolute values, only left the %):

Java Main Version --> 8 (66.4%) 9 (0.1%) 10 (0.2%) 11 (21.1%) 12 (1.0%) 13 (1.7%) 14 (2.3%) 15 (0.9%) 16 (5.6%) 17 (0.5%) 18 (0.3%)

Values of 15 now moved to 16, but the others are mainly unmoved.

Last edited 3 years ago by Don-vip (previous) (diff)

in reply to:  48 comment:49 by taylor.smock, 3 years ago

OK. We probably won't be moving to Java 11 this year then.
Thanks for looking.

comment:50 by stoecker, 3 years ago

It seems the majority of newer Java versions comes from newer Linux systems.

comment:51 by Don-vip, 3 years ago

Good news: most of Linux and mac users now use Java >= 11.
Bad news: almost 90% of Windows users (Windows users being about two thirds of the JOSM user base) are still using Java 8.

But it's not surprising as Oracle JRE will never prompt Java 8 users to update. And apart of the Java WebStart > OpenWebstart migration message, I still haven't make anything to ask "regular" JRE-based users to transition from an Oracle JRE to something else, so now would be a good time.

From https://rafael.codes/openjdk/ I think we should promote these two OpenJDK distributions:

They both ship OpenJFX, which could be handy for future long-term JOSM developments.

in reply to:  51 ; comment:52 by taylor.smock, 3 years ago

Replying to Don-vip:

Bad news: almost 90% of Windows users (Windows users being about two thirds of the JOSM user base) are still using Java 8.

I think I remember something somewhere talking about Minecraft and Java 16 being the baseline. Hopefully that pushes most of the users on Windows to Java 16 (and 16 > 11 :) ).

Do we want to use jpackage for the Windows installer as well (we are already using it for Mac)? This may also help us push to Java 11+. But it does increase size (15 mb -> 38mb).

They both ship OpenJFX, which could be handy for future long-term JOSM developments.

Good to know -- Mapillary was asking me (again) if I could reuse their Javascript based image viewer, which requires either (1) a JS engine that supports newer features (no native Java ones) or (b) embedding a web browser and distributing that for all the platforms JOSM supports.

in reply to:  52 ; comment:53 by stoecker, 3 years ago

Replying to taylor.smock:

Good to know -- Mapillary was asking me (again) if I could reuse their Javascript based image viewer, which requires either (1) a JS engine that supports newer features (no native Java ones) or (b) embedding a web browser and distributing that for all the platforms JOSM supports.

We did that in the past with a tool called webkit-image, which rendered a URL and saved the resulting image. This was necessary to follow the Yahoo guidelines for their service. Was an ugly workaround, but it worked. Don't know if JOSM still has the code for this or if it was removed.

in reply to:  53 ; comment:54 by Don-vip, 3 years ago

Replying to stoecker:

Don't know if JOSM still has the code for this or if it was removed.

Removed long ago ;) r11578:11581

Last edited 3 years ago by Don-vip (previous) (diff)

in reply to:  52 comment:55 by Don-vip, 3 years ago

Replying to taylor.smock:

Do we want to use jpackage for the Windows installer as well (we are already using it for Mac)? This may also help us push to Java 11+. But it does increase size (15 mb -> 38mb).

Yes, can be an option too.

comment:56 by gaben, 3 years ago

I still use Java 8 on Windows because in later versions they changed how scaling works and it is unusable for me. On Linux there is no difference :)
Will try again and report back if something improved in the meantime, which potentially means minus one Java 8 user.

in reply to:  54 ; comment:57 by taylor.smock, 3 years ago

Replying to Don-vip:

Replying to stoecker:

Don't know if JOSM still has the code for this or if it was removed.

Removed long ago ;) r11578:11581

author of removal: stoecker :)

And yes, it looks like an ugly workaround. AKA not something I want to do. I kind of want to try to avoid workarounds, if at all possible. They tend to break.

But if JavaFX is an option in the future, I believe MS Streetside has a 360 image viewer, which would probably fix the problem anyway (ignoring the perennial "2048px is too little for 360" comments).

in reply to:  56 ; comment:58 by taylor.smock, 3 years ago

Replying to gaben:

I still use Java 8 on Windows because in later versions they changed how scaling works and it is unusable for me. On Linux there is no difference :)
Will try again and report back if something improved in the meantime, which potentially means minus one Java 8 user.

Stupid question: Have you reported a bug to the JDK maintainers? Or is the scaling issue intentional?

in reply to:  57 comment:59 by stoecker, 3 years ago

Replying to taylor.smock:

Don't know if JOSM still has the code for this or if it was removed.

Removed long ago ;) r11578:11581

author of removal: stoecker :)

Ah no. That's unfair. It was broken before.

in reply to:  58 comment:60 by anonymous, 3 years ago

Replying to taylor.smock:

Stupid question: Have you reported a bug to the JDK maintainers? Or is the scaling issue intentional?

It was reported years ago and as far as I know it's an intentional fix for another scaling issue.
If you are interested I can collect the JDK ticket(s) and SO questions and a possible solution if there is any (should be).

Edit: the login cookie expired, it was me (gaben).

Last edited 3 years ago by gaben (previous) (diff)

comment:61 by Don-vip, 3 years ago

Ah great, we can give an hint to OpenWebStart about the vendor we prefer:
https://openwebstart.com/docs/OWSGuide.html#_specify_a_specific_vendor_in_the_jnlp_file

So if we set "Azul" or "BellSoft", OpenWebStart will download this JVM instead of AdoptOpenJDK (which doesn't include JavaFX).

It seems we can only specify a single vendor, so which one should we use between the two? Both seem OK.

comment:63 by Don-vip, 3 years ago

In 18159/josm:

see #17858 - request Azul JVM from OpenWebStart and add following JavaFX modules: controls,media,swing,web

comment:64 by Don-vip, 3 years ago

In 18160/josm:

see #17858 - make Debian/Ubuntu package depend on openjfx and add following JavaFX modules: controls,media,swing,web

comment:65 by Don-vip, 3 years ago

In 18161/josm:

see #17083, see #17858 - include JavaFX 16 in macOS/Windows packages

comment:66 by Don-vip, 3 years ago

Description: modified (diff)
Keywords: java17 added
Summary: OpenWebStart/Java 11 migrationOpenWebStart/Java 17 migration

I think we have now a good chance to switch to Java 17 somewhere in 2022. This migration will have been absolutely horrible, the worst in my Java development experience.

comment:67 by Don-vip, 3 years ago

Description: modified (diff)

comment:68 by Don-vip, 3 years ago

In 18166/josm:

see #17858 - promote Azul and BellSoft distributions over Oracle one

comment:69 by Don-vip, 3 years ago

In 35805/osm:

see #17858 - do no longer ship Java FX through giant openjfx plugin

comment:70 by Don-vip, 3 years ago

In 35806/osm:

see #17858 - do no longer ship Java FX through giant openjfx plugin (dist)

comment:71 by Don-vip, 3 years ago

In 18167/josm:

see #17858 - deprecate native javafx plugins, no longer needed, would rather cause harm as loading JavaFX through classpath is no longer supported anayway

https://github.com/openjdk/jfx/blob/master/doc-files/release-notes-16.md#javafx-runtime-logs-a-warning-if-javafx-modules-are-loaded-from-the-classpath

by taylor.smock, 3 years ago

Add automatic module name -- #15229 seems to indicate we'll want a lot of subpackages, but it may be useful to say "hey, we will be using this base module name"

in reply to:  71 comment:72 by taylor.smock, 3 years ago

Replying to Don-vip:

In 18167/josm:

see #17858 - deprecate native javafx plugins, no longer needed, would rather cause harm as loading JavaFX through classpath is no longer supported anayway

https://github.com/openjdk/jfx/blob/master/doc-files/release-notes-16.md#javafx-runtime-logs-a-warning-if-javafx-modules-are-loaded-from-the-classpath

For this deprecation, I should probably update the MS Streetside plugin to no longer depend upon JavaFX, right? Or should I wait for the September release to avoid breaking stuff right now?

comment:73 by Don-vip, 3 years ago

No need to wait for next release if you bump the min JOSM version of the plugin.

in reply to:  73 ; comment:74 by taylor.smock, 3 years ago

Replying to Don-vip:

No need to wait for next release if you bump the min JOSM version of the plugin.

Fair enough. Except I don't think the current JOSM packages for Windows are built that way. So I've got to wait for the stable release in order to set the min version. I can technically set the min version to the latest version, but I probably ought to wait for a release.

Anyway, I was thinking:

  • Move the JavaFX 360 viewer from MS Streetside into JOSM core (in a try-catch block, just so that people without JavaFX can still use JOSM), this will fix #16472.
  • Modify the ImageEntry class to have a isPano or is360 method (probably a default method returning false)
  • Modify the ImageEntry class to have a getNext and getPrevious method (maybe also getFirst and getLast as well)
  • Modify the ImageEntry class to have an additionalPainters method so that detections can be drawn on the image (Mapillary/KartaView).

But that should be in a different ticket. :)

in reply to:  74 comment:75 by Don-vip, 3 years ago

Replying to taylor.smock:

  • Move the JavaFX 360 viewer from MS Streetside into JOSM core (in a try-catch block, just so that people without JavaFX can still use JOSM), this will fix #16472.

I plan to finally take a look at it, move it to the openjfx plugin, with necessary changes in core if needed (like the MP3 player) so that 360 pictures can be viewed with just the openjfx plugin (indeed to fix #16472). Making sure JavaFX was available everywhere was the first step.

Let's discuss it in #16472.

in reply to:  74 ; comment:76 by stoecker, 3 years ago

Replying to taylor.smock:

I can technically set the min version to the latest version, but I probably ought to wait for a release.

That's not necessary. The minimum version is the needed minimum version for the plugin to work. The "stable" release is a rather artificial construct for josm to satisfy users (and developers) who expect such a thing. For the plugin mechanics it makes no difference.

comment:77 by Don-vip, 3 years ago

In 35807/osm:

see #17858 - fix javafx plugin

comment:78 by Don-vip, 3 years ago

In 35808/osm:

see #17858 - fix javafx plugin (dist)

in reply to:  76 comment:79 by taylor.smock, 3 years ago

Replying to stoecker:

That's not necessary. The minimum version is the needed minimum version for the plugin to work. The "stable" release is a rather artificial construct for josm to satisfy users (and developers) who expect such a thing. For the plugin mechanics it makes no difference.

The reason why I was inclined to wait for release is just in case someone's JNLP file doesn't self update -- I'm presuming there will be a note in StartupPage about the new JavaFX dependency, so they would at least be able to know about the change.

EDIT: I'm going to have to troubleshoot why I cannot seem to build MS Streetside (I've tried with openjfx installed).

See r35809/osm.

Last edited 3 years ago by taylor.smock (previous) (diff)

comment:80 by Don-vip, 3 years ago

In fact, why did you remove the dependency? I only deprecated the native plugins, but the openjfx plugin still exists, and I'd like to make it the only JOSM plugin to provide a 360° image viewer, if it appears JavaFX is really mandatory and we can't create a Swing-based one in core.

Last edited 3 years ago by Don-vip (previous) (diff)

comment:81 by Don-vip, 3 years ago

In 18171/josm:

see #17858 - add javafx to module-path in Linux launcher

in reply to:  80 comment:82 by taylor.smock, 3 years ago

Replying to Don-vip:

In fact, why did you remove the dependency? I only deprecated the native plugins, but the openjfx plugin still exists, and I'd like to make it the only JOSM plugin to provide a 360° image viewer, if it appears JavaFX is really mandatory and we can't create a Swing-based one in core.

My bad. I read "deprecated" as move off ASAP.

comment:83 by Don-vip, 3 years ago

No problem. The JavaFX handling is not really simple :D

comment:84 by Don-vip, 3 years ago

New numbers:

Java Main Version --> 8 (63.2%) 9 (0.1%) 10 (0.2%) 11 (20.4%) 12 (0.7%) 13 (1.3%) 14 (1.7%) 15 (0.8%) 16 (9.2%) 17 (1.3%) 18 (1.1%)

comment:85 by skyper, 3 years ago

Problem with open webstart on windows: #21354

comment:86 by skyper, 3 years ago

There are problems with kendzi3d plugin and java 16/17, see #21348.

Last edited 3 years ago by skyper (previous) (diff)

comment:87 by Don-vip, 3 years ago

Looks like the impact of Windows installer is massive, Java 8 dropped a lot more than I expected:

Java Main Version --> 8 (39.3%) 9 (0.1%) 10 (0.1%) 11 (24.2%) 12 (0.4%) 13 (1.0%) 14 (1.2%) 15 (0.4%) 16 (17.9%) 17 (8.3%) 18 (7.2%)

Among Java 8 users, the OS market share is:

Linux (18.6%) Mac (8.1%) Windows (73.4%)

in reply to:  86 comment:88 by taylor.smock, 2 years ago

Replying to skyper:

There are problems with kendzi3d plugin and java 16/17, see #21348.

Good news: I've got a kendzi3d-dev plugin that runs on Mac OSX under Java 17. There are a couple of bugs, but it doesn't crash.

comment:89 by taylor.smock, 2 years ago

As a heads up, some of the tools we use depend upon Java 11+ now.

Specifically,

comment:90 by stoecker, 2 years ago

StartupPage now warns for Java < 11. Maybe that helps ;-)

Last edited 2 years ago by stoecker (previous) (diff)

comment:91 by taylor.smock, 2 years ago

Good to know (also, Ubuntu 22.04 was released today).

It has been awhile since the last update of Java stats (see comment:87), but I would presume we are at least 60%+ Java 11 or later. And hopefully more like 80%+.

Anyway, neither checkstyle nor error_prone are required updates to get Java-EarlyAccess-JOSM working again (I think I could update jacoco from 0.8.7 to 0.8.8, but I don't know if something else will cause it to fail).

comment:92 by stoecker, 2 years ago

Current stats: 8 (36.1%) 11 (22.1%) 17 (34.6%)

comment:93 by anonymous, 2 years ago

Hello, i still run into issues in OWS. It keeps saying that "no suitable jvm is found" whenever I launch from the file.

in reply to:  93 comment:94 by anonymous, 2 years ago

Replying to anonymous:

Hello, i still run into issues in OWS. It keeps saying that "no suitable jvm is found" whenever I launch from the file.

worth noting, I can't launch from the terminal either.

comment:95 by anonymous, 2 years ago

Used OWS in general without problems. Had a break of some weeks and now on MacOS 12.3.1 OWS complains about a missing JVM and it does not download it automaticalle. Is there a way to install the needed JVM (azul?) manually?

comment:96 by ajf3934221jos, 2 years ago

Same problem … NO JVM

comment:97 by jBeata, 2 years ago

Do you have a more clear deadline for discontinuing Java 8 support?

in reply to:  96 comment:98 by ajf3934221jos, 2 years ago

Replying to ajf3934221jos:

Same problem … NO JVM

... solved by itself

in reply to:  93 comment:99 by taylor.smock, 2 years ago

Replying to anonymous, anonymous, anonymous, ajf3934221jos, ajf3934221jos:

Hello, i still run into issues in OWS. It keeps saying that "no suitable jvm is found" whenever I launch from the file.

This appears to have been an OpenWebStart Bug. See https://github.com/karakun/OpenWebStart/issues/514 for more information. It should be fixed now.

Replying to jBeata:

Do you have a more clear deadline for discontinuing Java 8 support?

I do not. I don't know about the rest of the team. As noted by stoecker, we still have ~1/3 users on Java 8. Previous practice has been to increase Java versions when a relatively small portion of JOSM users are on the deprecated version (from comment:14, <5%). With that said, getting users to migrate off of Java 8 is somewhat of a nightmare (specifically for Mac/Windows users), since the java.com releases are Java 8. I've updated documentation to point to other Java distributions (specifically Azul with JavaFX), and I encourage users to either use OpenWebStart or the installers.

comment:100 by taylor.smock, 2 years ago

Stupid question: Do we want to update the link to java.com on the JOSM home page? (**JOSM** is an extensible editor for [osmwww: OpenStreetMap] (OSM) for [https://www.java.com Java 8+].)

I.e., **JOSM** is an extensible editor for [osmwww: OpenStreetMap] (OSM) for [https://www.java.com Java 8+], but we recommend [https://www.azul.com/downloads/?version=java-17-lts&package=jre-fx#download-openjdk Java 17+].

JOSM is an extensible editor for OpenStreetMap (OSM) for Java 8+, but we recommend Java 17+.

comment:101 by stoecker, 2 years ago

Wha, when you change it, then simply replace the link. ;-)

comment:102 by taylor.smock, 2 years ago

Description: modified (diff)

comment:103 by Don-vip, 2 years ago

current stats:

8-10 (31.2%) 11-16 (27.3%) 17+ (41.5%)

these numbers include everyone, meaning also people running a very old version of JOSM and unlikely to be affected by our decision to migrate to Java 11/17 as they don't update their JOSM at all. If we only look at people running at least JOSM 18360 (21.12), numbers are:

8-10 (19.6%) 11-16 (28.4%) 17+ (52.0%)

Among these users, the Java 8 users distribute as follow:

OS > 1%:
Linux (28.7%) Mac (5.0%) Windows (66.0%)

Languages > 5%:
en (51.5%) de (15.5%) en_GB (6.2%) fr (5.4%)

comment:104 by sebastic, 23 months ago

The Debian package had to drop support for openjdk-8 when it switch to building with openjdk-11 because it not backwards compatible, would openjdk-11 support need to be dropped when JOSM is built with openjdk-17 or does that do preserve backward compatibility?

in reply to:  104 comment:105 by taylor.smock, 23 months ago

Replying to sebastic:

The Debian package had to drop support for openjdk-8 when it switch to building with openjdk-11 because it not backwards compatible, would openjdk-11 support need to be dropped when JOSM is built with openjdk-17 or does that do preserve backward compatibility?

We still build and develop JOSM with Java 8. If we were to build it with Java 11, then yes, there might be some incompatibilities (there are some classes that override a method in Java 11 that did not in Java 8, and if we compile with Java 11 it looks for those overridden methods in the implementing classes). I do not know if that is the case for Java 17 -> Java 11, but a good general recommendation it to compile it with the lowest version of Java possible, since that will (almost always) work on later versions of Java.

So the answer is "I don't know". There is a --release switch that can be used by javac to output the appropriate class files, with the caveat that some JDK classes may now override a method, which has caused issues in the past. For your sanity (and ours), just use the "minimum" java version the debian packagers want to support that JOSM also supports.

I don't know how the Debian package decides which compiler to use (default-jdk?), but that is really the limiting factor.

With all that said, some plugins are now depending upon Java 11+, so it isn't a horrible thing that the Debian package requires Java 11+.

comment:106 by sebastic, 23 months ago

Java 11 isn't the problem, Java 17 is. Specifically these bits:

  • 2021-09-15: Java 17 is released. Switch macOS / Windows packages to Java 17 and JavaFX 17, update Debian/Ubuntu launch script to prefer 17 over 11 and 8 => r18225
  • 2022-04-21: Ubuntu 22.04 LTS is released and ships Java 17 (note: default-jre is Java 11)
  • somewhere in 2022: Enough JOSM users are now using Java 17+ so we can consider moving the codebase to Java 17.

Debian bullseye is in the same boat as Ubuntu jammy, openjdk-11 is still the default-jdk and default-jre.

Requiring Java 17 to build JOSM will mean using a non-default JDK on Debian stable and Ubuntu LTS.

openjdk-17 is available in backports for Debian stable, java-common in experimental even made it the default, but that change isn't going to find its way into stable and LTS releases.

comment:107 by taylor.smock, 19 months ago

Here is a hopefully stupid question:

Do we have infrastructure in place to inform users that they must update to a newer version of Java? I didn't see anything, but I might have missed it.

Pseudocode of what I was looking for:

    private static void javaVersionCheck() {
        if (Utils.getJavaVersion() < 11) {
            if (Utils.isRunningJavaWebStart()) {
                // Show user link to OpenWebStart, then exit. Maybe two months from release before a force exit though
                // (aka, we start compiling most classes for Java 11).
            } else {
                // Our installers all include Java 17+, so everyone here must be running the jar file or be on Unix/Linux.
                if (PlatformManager.isPlatformOsx()) {
                    // Link to OSX installer and Java 17, maybe OpenWebStart?
                } else if (PlatformManager.isPlatformWindows()) {
                    // Link to Windows installer and Java 17, maybe OpenWebStart?
                } else if (PlatformManager.isPlatformUnixoid()) {
                    // Ask user to install Java 11/17 and use that instead. Packagers might be a problem.
                } else {
                    // We probably won't ever hit this, but just tell the user that they need to use Java 11+ and link to Java 17 (maybe Java 17 source?)
                }
            }
        }
    }

I was kind of thinking that we could continue compiling a few classes with Java 8 (MainApplication, PlatformManager, Utils, OpenBrowser) and give the user more concrete steps for their situation while we move to Java 11/17 for all other classes.

EDIT: We could probably modify the Platform#startupHook for this.

Last edited 19 months ago by taylor.smock (previous) (diff)

by taylor.smock, 19 months ago

Attachment: 17858.patch added

Warn on Java < 11 when not run under OpenWebStart, update URL to point at azul and pre-fill fields to decrease user confusion, Utils.getJavaLatestVersion uses Java 11 (WebStart) and Java 17 for latest Java versions

comment:108 by taylor.smock, 19 months ago

I'd appreciate it if someone with Windows (x64) could test attachment:17858.patch against a 32 bit Java 8 install. It should detect that the OS is x64 and set the appropriate download URL. I'll see if I can get my hands on a Windows machine to test, but I'd like a second opinion in any case.

comment:109 by Klumbumbus, 19 months ago

With 64 bit Windows and 32 bit Java 8 and applied patch I was asked to Update Java and was linked to:

https://www.azul.com/downloads/?version=java-17-lts&os=windows&architecture=x86-64-bit&package=jre-fx

(already scrolled down to Download Azul Zulu Builds of OpenJDK)

Build-Date:2022-10-20 21:25:38
Revision:18579
Is-Local-Build:true

Identification: JOSM/1.5 (18579 SVN de) Windows 10 64-Bit
OS Build number: Windows 10 Enterprise 2004 (19041)
Memory Usage: 137 MB / 247 MB (44 MB allocated, but free)
Java version: 1.8.0_351-b10, Oracle Corporation, Java HotSpot(TM) Client VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 2160×1440 (scaling 1.00×1.00)
Maximum Screen Size: 2160×1440
Best cursor sizes: 16×16→32×32, 32×32→32×32
System property file.encoding: Cp1252
System property sun.jnu.encoding: Cp1252
Locale info: de_DE
Numbers with default locale: 1234567890 -> 1234567890

in reply to:  109 comment:110 by taylor.smock, 19 months ago

Replying to Klumbumbus:

With 64 bit Windows and 32 bit Java 8 and applied patch I was asked to Update Java and was linked to:

https://www.azul.com/downloads/?version=java-17-lts&os=windows&architecture=x86-64-bit&package=jre-fx
(already scrolled down to Download Azul Zulu Builds of OpenJDK)

Thanks. :)

I thought it was going to work (based off of documentation), but I wanted to make certain. This will hopefully get rid of the tickets where someone installed 32bit Java on 64bit Windows, and wonders why they run out of memory easily.

I'll go ahead and apply the patch Monday (I want to give other contributors a chance to look at the patch).

I don't think anything is controversial in the patch, but I want to make certain people don't have a problem with us pointing at Java 17 LTS when I think we are going to be jumping to Java 11 LTS next (because of default-jdk/default-jre in Debian, and OpenWebStart not currently having any Java 17 JREs available).

comment:111 by gaben, 19 months ago

Before moving from Java 8, please take a look at the reported hidpi issues affecting every Java version 9 and above on Windows.

I tried to improve the situation in JOSM, but no success :(

in reply to:  111 comment:112 by taylor.smock, 19 months ago

Replying to gaben:

Before moving from Java 8, please take a look at the reported hidpi issues affecting every Java version 9 and above on Windows.

I tried to improve the situation in JOSM, but no success :(

This most likely needs to be fixed in the upstream JDK. As far as I know, we don't do anything with respect to the standard swing component text rendering.

Have anyone filed a Java ticket for the behavior? I know I haven't, as I usually only file tickets when I've diagnosed the problem and can (at least) provide a suggestion on how to fix it. For all I know, this might be fixed if we start compiling against Java 9+ (the build.xml currently just compiles against Java 8, even if the compiler is Java 17, IIRC).

Rather unfortunately, I do not have a windows machine with HiDPI available for debugging.

comment:113 by Don-vip, 19 months ago

Part of the difficulty of the HiDPI issues is that it's difficuult to support both Java 8 and later versions. Switching to Java 17 might reduce the difficulty of tackling these issues.

Last edited 19 months ago by Don-vip (previous) (diff)

in reply to:  113 ; comment:114 by taylor.smock, 19 months ago

Replying to gaben:

Before moving from Java 8, please take a look at the reported hidpi issues affecting every Java version 9 and above on Windows.

I tried to improve the situation in JOSM, but no success :(

For reference, we are working around the following bugs in Java 8:

In addition, we have special handling for Java 8 in:

  • ImageProvider#read (#9984/#16047)
  • PlatformHookOsx#startupHook (looks like it is mostly for java -jar users)
  • PlatformHookUnixoid#preStartupHook (#12022/#16666)

With all that, I would not be surprised if there was special handling for Java 8 bytecode in the Swing code paths (AKA, if (bytecode < 53) { /* Assume application will look horrible if hidpi paths are followed */ }). But this is probably an interaction between the scaling done by Windows and the scaling done by the JVM, which will require stepping through code on a windows machine.

You could also try running JOSM with -Dsun.java2d.uiScale=1.0 and see if that "fixes" the issue. Definitely not ideal, as it will effectively disable the HiDPI detection code.

Possible upstream bugs:

Replying to Don-vip:

Part of the difficulty of the HiDPI issues is that it's difficuult to support both Java 8 and later versions. Switching to Java 17 might reduce the difficulty of tackling these issues.

As much as I'd like to, I don't think we'll be able to move to Java 17 until OpenWebStart adds Java 17 JVMs to their jvm list.

in reply to:  114 comment:115 by Don-vip, 19 months ago

Replying to taylor.smock:

josm-found -- TIL we have our own label in the JDK bug tracker

Yep you just have to state to add this label when you report a bug.

As much as I'd like to, I don't think we'll be able to move to Java 17 until OpenWebStart adds Java 17 JVMs to their jvm list.

Well if it takes too long we can still update to Java 11 as I planned originally :)

comment:116 by taylor.smock, 19 months ago

In 18580/josm:

See #17858: start linking to Java 17 for Java updates.

The link for the Java download page now goes to azul.com, and attempts to pre-fill as
much of the download form as possible.

This also adds a method to warn users running Java 10 or earlier that their version
of Java will soon be unsupported by JOSM. This only affects users using Java 10 or
earlier if they are not running JOSM using WebStart.

in reply to:  106 ; comment:117 by tuxayo, 18 months ago

Replying to sebastic:

Java 11 isn't the problem

As of now, aren't there too many people on Java <11? Hopefully by prompting them to upgrade a large part will do. But for a lot of Linux cases, it might the distro install that need updating and many people aren't tech savvy enough to do that. Maybe and having an AppImage with JRE bundled with JOSM would help to up JRE version quicker without loosing much people?

Debian bullseye is in the same boat as Ubuntu jammy, openjdk-11 is still the default-jdk and default-jre.

Requiring Java 17 to build JOSM will mean using a non-default JDK on Debian stable and Ubuntu LTS.

That might be naive but are many people on Debian and Ubuntu using JOSM from their repos? If that's the case, then the package can require openjdk-17 and no issue with default-jre being 11, would that work?

«using JOSM from their repos» Ah crap they would have to enable backports of add an external repo for JOSM so likely most people download the .jar or use WebStart.

.

openjdk-17 is available in backports for Debian stable

Isn't it in the normal repos? https://tracker.debian.org/pkg/openjdk-17 still not the default though.

in reply to:  114 comment:118 by tuxayo, 18 months ago

Replying to taylor.smock:

As much as I'd like to, I don't think we'll be able to move to Java 17 until OpenWebStart adds Java 17 JVMs to their jvm list.

How does it work even for Java 11? IIUC OpenWebStart ships by default Java 8, and the JVM Manager has be used to switch to 11. Is that easy enough so we can count on the vast majority of WebStart users to do that? If not, how to guide them to have a better success rate?

in reply to:  117 comment:119 by taylor.smock, 18 months ago

Replying to tuxayo:

As of now, aren't there too many people on Java <11? Hopefully by prompting them to upgrade a large part will do. But for a lot of Linux cases, it might the distro install that need updating and many people aren't tech savvy enough to do that. Maybe and having an AppImage with JRE bundled with JOSM would help to up JRE version quicker without loosing much people?

There is a snap (that really needs to be updated for current "best" practices) and an unofficial flatpak (I've contributed to the flatpak). I don't think it is worth it to add an appimage to our download options.

How does it work even for Java 11? IIUC OpenWebStart ships by default Java 8, and the JVM Manager has be used to switch to 11. Is that easy enough so we can count on the vast majority of WebStart users to do that? If not, how to guide them to have a better success rate?

We have the JNLP set up to use Java 1.8+, which OWS interprets as preferring newer versions of Java. So it will (by default) download the Java 11 JRE for the user. The user can fiddle with some settings so that doesn't happen, but at that point, it is the user's problem.

in reply to:  103 comment:120 by taylor.smock, 18 months ago

Replying to Don-vip:

[...]
8-10 (19.6%) 11-16 (28.4%) 17+ (52.0%)

Among these users, the Java 8 users distribute as follow:

OS > 1%:
Linux (28.7%) Mac (5.0%) Windows (66.0%)
[...]

What are the Java 8 numbers looking like now? I'm mostly interested in the Mac/Windows numbers, since I expect Linux users to be using the version from their distro's repository.

I'm thinking about changing the build.xml file to compile everything for Java 11 starting in January (assuming Java 11+ uptake looks good) except:

  • MainApplication
  • PlatformHook
  • Logging
  • Anything else needed to get to the point where we ask users to update their Java version

comment:121 by stoecker, 18 months ago

Java 8: Windows (32%) Mac (14%) Linux (18%) Total (27%)
Java 8 for JOSM >= 18583: Windows (17%) Mac: (22%) Linux (13%) Total (17%)

comment:122 by taylor.smock, 18 months ago

Thanks. I was really hoping for more movement. It appears that the total hasn't really moved from comment:103 (19.6% to 17%). Only major change is that Mac now accounts for a greater "share" of the Java 8 users (42%, up from 5%). I wonder what is going on there? Maybe some plugins aren't playing nice with Java 17 (see MagicWand as an example)?

I'll go ahead and get a patch put together for the build.xml, but I don't think we are at the point where we can switch.

comment:123 by stoecker, 18 months ago

For the Mac I'd rather say it's a low user base. Mac is used by only 8% of all users. So a few users may change the result a lot.

Also note that our stats are rather low quality. +/- a few per cent are normal.

We'll probably need to choose 10% as goal for switching. 5% seems not realistic for a long time.

Last edited 18 months ago by stoecker (previous) (diff)

in reply to:  122 comment:124 by skyper, 18 months ago

Replying to taylor.smock:

I wonder what is going on there? Maybe some plugins aren't playing nice with Java 17 (see MagicWand as an example)?

Yes plugins could be one reason but you example is wrong as MagicWand is Java 11+, only.

comment:125 by jBeata, 13 months ago

Is there any deadline for when Java 8 will not be supported anymore? Currently, also the ImproveOSM, KartaView, and Geohash plugins are running on Java 8, but we can upgrade to Java 17 as soon as JOSM is upgraded.

comment:126 by stoecker, 13 months ago

Even thought there is a warning now there is not much improvement. So if we switch to java > 8 we'll loose a lot of users.

Thought plugins can already switch earlier. Simply set "Plugin-Minimum-Java-Version" in manifest :-)

Maybe that helps convince some users?

in reply to:  126 comment:127 by taylor.smock, 13 months ago

Replying to stoecker:

[Though] plugins can already switch earlier. Simply set "Plugin-Minimum-Java-Version" in manifest :-)

Don't tempt me. :)

Geotools 29.x requires Java 11 or later, and updating that one will make the following plugins effectively require Java 11+:

  • cadastre-fr
  • ImportImagePlugin
  • opendata
  • matsim
  • Tracer-testing

And then there is the need to change the build-common.xml file for it (as it is part of the ordered_plugins list).

@jBeata: from comment:103, you are looking at ~20% of users not running Java 11 or later. We've had the warning up for about a year now (see comment:90) and JOSM has been linking to a Java 17 distribution for 6 months when asking users to update Java (see comment:116).

Quite frankly, I would encourage plugins to start updating to Java 11 or later at this point, and I'm really close to advocating a drop-dead date for Java 8 of 2024-05-01 (2 year lead time from when we started indicating that we were planning to drop Java 8 support).
Even then, I think we'll probably try to compile a select few classes with Java 8 specifically to give holdouts instructions on how/where to update their java version for another year or so.

comment:128 by stoecker, 13 months ago

Current stats:

Java Versions with at least 1%: 8 (23.7%) 11 (19.3%) 16 (1.0%) 17 (50.8%) 18 (1.1%) 19 (2.6%)

Values per OS. The second number is cumulated count, so 80% for 11 means 80% of users use >= Java 11.

FreeBSD 17(20%, 60%) 11(20%, 80%)  8(20%,100%)
Linux   17(15%, 23%) 11(57%, 83%)  8(17%,100%)
Mac     17(67%, 71%) 11(16%, 90%)  8( 9%,100%)
Windows 17(65%, 67%) 11( 3%, 71%)  8(28%,100%)

comment:129 by stoecker, 13 months ago

I see no issue with updating plugins to Java >= 11 when this allows to go forward with e.g. geotools.

With JOSM core OTOH I'm not so sure. I don't see the big killer feature in the core where we really need Java 8 which justifies to loose a quarter of our users. Or do I overlook something?

in reply to:  129 ; comment:130 by taylor.smock, 13 months ago

Replying to stoecker:

With JOSM core OTOH I'm not so sure. I don't see the big killer feature in the core where we really need Java 8 which justifies to loose a quarter of our users. Or do I overlook something?

  • Desktop.moveToTrash (Java 9, instead of using Files.delete; this would give users a chance to revert an accidental deletion)
    • I think this would be the most "critical" reason to move to Java 11+, but we could probably work around it by having a Consumer<File> be set and then a Utils.delete method that calls the consumer.
  • sealed classes (Java 15, restrict implementors of OsmPrimitive to Node, Way, Relation)
  • record classes (Java 15, use for stuff like LatLon, mostly to make it easier to move to a value class when Java supports it)
  • HTTP/2 support (currently done via plugin; there are some subtle bugs due to having a differing implementations, mostly related to the default headers)

in reply to:  130 ; comment:131 by stoecker, 13 months ago

Replying to taylor.smock:

Replying to stoecker:

With JOSM core OTOH I'm not so sure. I don't see the big killer feature in the core where we really need Java 8 which justifies to loose a quarter of our users. Or do I overlook something?

  • Desktop.moveToTrash (Java 9, instead of using Files.delete; this would give users a chance to revert an accidental deletion)
    • I think this would be the most "critical" reason to move to Java 11+, but we could probably work around it by having a Consumer<File> be set and then a Utils.delete method that calls the consumer.
  • sealed classes (Java 15, restrict implementors of OsmPrimitive to Node, Way, Relation)
  • record classes (Java 15, use for stuff like LatLon, mostly to make it easier to move to a value class when Java supports it)
  • HTTP/2 support (currently done via plugin; there are some subtle bugs due to having a differing implementations, mostly related to the default headers)

Nice, but not really killer features. I think currently we should still go the way of increasing the pressure (i.e. with switching plugins to higher java) and not yet abandon Java 8 for the core (and reevaluate in summer :-).

in reply to:  131 ; comment:132 by Don-vip, 13 months ago

record is a killer feature if we manage to decrease the memory consumption of LatLon substantially. Did anyone start to try that to see how much memory we could gain?

in reply to:  132 comment:133 by taylor.smock, 13 months ago

Replying to Don-vip:

record is a killer feature if we manage to decrease the memory consumption of LatLon substantially. Did anyone start to try that to see how much memory we could gain?

I don't think record by itself will be a significant memory reduction. I'll check and see, but I believe that value classes will be where we start seeing significant memory improvements. Big things (from our perspective):

  • Implicitly final (like a record class)
  • No super call
  • No synchronized methods (since it doesn't have an identity)
  • new Value(0.0, 0.0) == new Value(0, 0) (new Value(0.0, 0.0).equals(new Value(0, 0)) is not necessary)
  • An array of LatLon can be stored as [lat1, lon1, lat2, lon2, lat3, lon3] instead of [Pointer1[lat1, lon1], Pointer2[lat2, lon2], Pointer3[lat3, lon3]] which would be a 33% memory reduction (naive, assumes all latlon values are in arrays). TBH, making Node a value class would probably have higher absolute memory reduction returns, since it stores lat/lon in its own fields. But making LatLon a value class might reduce the number of new LatLon calls (so instead of latLon1.interpolate(latLon2, 0.5).lat() creating a new LatLon in interpolate, it just does the calculation for lat()).

When I was looking at it, there were going to be several different hurdles to overcome (namely converting Coordinate to an interface), but otherwise, LatLon is already very similar to a record (only final fields), it just need to become final.

With that said, there might be some memory optimizations that the JVM can do with record classes.

comment:134 by taylor.smock, 10 months ago

In 18790/josm:

Fix #23103, see #17858: Notify users that a plugin requires a newer Java version

We were previously only logging a warning if a plugin required a newer Java
version. We additionally needed to update the download link generation for Azul
and sync the next minimum Java version with that used by the JOSM wiki check.

There was also a help topic that linked to a dead page (which was also
unavailable in the internet archive).

in reply to:  134 comment:135 by gaben, 10 months ago

Replying to taylor.smock:

Why JDK instead of JRE?

Edit: Okay, because JDK always seems to have an installer, while JRE just most of the time.

Last edited 10 months ago by gaben (previous) (diff)

comment:136 by taylor.smock, 10 months ago

Edit: Okay, on linux it has an installer.

As noted in the comments, the JDK's have installers. For whatever reason, Azul doesn't provide installers for the JRE packages. At least on Mac/Windows. I didn't check Linux -- most Linux users should just use whatever their distribution provides.

It is a bit more space used on the user's machine, but it should "just work" for most people.

comment:137 by taylor.smock, 8 months ago

Description: modified (diff)

As a heads up, it looks like wiremock will not be providing explicit support for Java 21 in their 2.x series, and won't be supporting Java 8 in their (as yet unreleased) 3.x series. See https://github.com/orgs/wiremock/projects/5 for details.

I don't think we'll have issues using their 2.x series with Java 21, but I wanted to bring it up for when we add Java 21 to the build system. Just in case it consistently fails.

Anyway, other features in newer Java versions that I discovered when reviewing a PR on GitHub:

  • Predicate.not (Java 11)
  • Math.clamp (Java 21, not Java 17, so we still wouldn't be able to use it; we an the equivalent in Utils)

Beyond that, it looks like I might have to correct myself.
In comment:133, I said "I don't think record by itself will be a significant memory reduction", but a JDK developer did some benchmarks which show (minimally) a CPU speed increase. I would anticipate that this is due to "constant folding of instance fields", but the JVM might be doing some other optimizations due to being able to "trust" the record classes.

As a side note, Java 21 is being released in 5 days.
Do we want to move all of our installers to Java 21 once that happens, or do we want to wait a month or so?

Additional notes:

  • Most URL constructors are deprecated (do we want to move everything over to URI, keeping URL methods for legacy reasons?)
  • SecurityManager is deprecated -- its removal will fix a whole class of bugs with respect to OpenWebStart

comment:138 by taylor.smock, 8 months ago

When we move to Java 9+ and start writing a module-info.java file, what module name are we going to want to use?

I'd like to add the Automatic-Module-Name to our MANIFEST.MF so that plugins can start writing their own module-info.java files.

Here is a rundown of the current state of our dependencies:

Dependencies with a set module name

  • jmapviewer: org.openstreetmap.gui.jmapviewer (see #23114, needs a release and update in source:trunk/ivy.xml)
  • org.apache.commons:commons-compress: org.apache.commons.compress
  • org.tukaani:xz: org.tukaani.xz
  • ch.poole:OpeningHoursParser: ch.poole.openinghoursparser

Dependencies without a set module name

Unused/to be removed:

  • javax.json:javax.json-api -> replaced by jakarta.json:jakarta.json-api (kept for backwards compatibility)
  • org.glassfish:javax.json -> replaced by org.eclipse.parsson:parsson (kept for backwards compatibility)
  • com.adobe.xmp:xmpcore: We don't actually use this in JOSM core; it is a dependency of com.drewnoakes:metadata-extractor though.
  • oauth.signpost:signpost-core: I'm looking at removing this come 2024 since the OSM website considers OAuth 1.0a to be deprecated.

Requires merge and/or release and update:

  • org.apache.commons:commons-jcs3-core: Should be fixed in their next release (org.apache.commons.jcs3, probably not 3.2, which came out yesterday. Caveat: their next release will probably require Java 17)
  • com.drewnoakes:metadata-extractor: Probably com.drew.imaging, see https://github.com/drewnoakes/metadata-extractor/issues/566 (I should probably ping this again)

Deprecated/unmaintained/unlikely to have a release in the near future:

  • com.google.code.findbugs:jsr305: Near as I can tell, this is deprecated (especially since it uses the javax root package). jspecify is (apparently) using a fork of checker framework with the intent of merging it back in. There seem to be two major alternatives for nullness annotations, the aforementioned checkerframework, jspecify, and Jetbrain's annotation library.
  • com.formdev:svgSalamander: It looks like either we will have to pick up the release process or move to a newer Java SVG library -- the author of svgSalamander apparently has issues releasing to maven central, and the com.formdev guys have moved to JSVG. I did just get JPMS information added to svgSalamander source code though.

Other:

  • org.webjars.npm:tag2link: This is really just a "resource" jar.

in reply to:  128 comment:139 by taylor.smock, 8 months ago

Do we have some updated Java Version usage stats? Specifically for Windows (28% on Java 8 6 months ago)? The last update had Mac at <9%, and I'm not that worried about Linux/BSD users (I expect 90%+ of both BSD and Linux users to be using a package manager, so I expect their Java 8 usage to rapidly decrease once package maintainers update their minimum Java version).

comment:140 by stoecker, 8 months ago

Raw data (percent, cumulated percent) Timeframe approx 1 day.

Version with at least 1%:

All     21( 4%,  4%) 20( 2%,  6%) 19( 1%,  7%) 18( 1%,  8%) 17(55%, 63%) 16( 1%, 64%) 11(13%, 77%)  8(23%,100%)

Linux   21( 6%,  6%) 20( 2%,  8%) 19( 2%, 10%) 18( 1%, 12%) 17(34%, 46%) 14( 1%, 47%) 11(41%, 89%)  8(11%,100%)
Mac     21(15%, 15%) 20( 1%, 17%) 17(42%, 59%) 16( 1%, 60%) 15( 1%, 61%) 11( 4%, 65%)  8(35%,100%)
Windows 21( 1%,  1%) 20( 2%,  3%) 19( 1%,  4%) 18( 1%,  4%) 17(68%, 72%) 16( 1%, 73%) 11( 1%, 74%)  8(26%,100%)
Linux (27.7%) Mac (13.9%) Windows (58.4%)

comment:141 by taylor.smock, 8 months ago

Windows hasn't moved much, if at all. :(

I really wish I knew why people were sticking with Java 8.

I guess I'll just keep bumping the min Java versions for plugins when I make significant modifications.

in reply to:  141 comment:142 by gaben, 8 months ago

Replying to taylor.smock:

I really wish I knew why people were sticking with Java 8.

I'm still using Java 8 on Windows, AMA.

In short, every time I tried to move off, I ran into various UI issues across different apps. Java 8 is rock-solid.

comment:143 by stoecker, 8 months ago

If we get trouble to support 8, then we'll migrate to 11 and users will need to adapt. And trouble is already starting. E.g. Jenkins is also Java >= 11 only.

in reply to:  143 ; comment:144 by taylor.smock, 8 months ago

Also:

  • error-prone only supports Java 11+ (and probably soon to be Java 17+) as the compiler
    • I've got a way to use error-prone 2.10 on Java 8 and error-prone 2.22 on Java 11+, but there are a lot of new issues I need to go through and fix. They do claim to support the --release flag, so we could modify the job to compile with Java 11 (or later) but run the tests with Java 8. But that might require changes to the ant targets -- I don't think ant is "smart" enough to avoid recompiling. Maybe a test-java-version variable or something.
  • checkstyle only supports Java 11+
    • I can probably do the same thing for checkstyle that I'm doing for error-prone
  • wiremock 3 dropped Java 8 support. I probably won't be able to update this test dependency going forward (until we move off of Java 8 or only run tests on Java 11+).

We can technically compile only on Java 17 (or later) and use the --release javac option to compile against Java 8 (which we already do).

in reply to:  144 ; comment:145 by stoecker, 7 months ago

Replying to taylor.smock:

We can technically compile only on Java 17 (or later) and use the --release javac option to compile against Java 8 (which we already do).

That usually only works correct if you also compile against the Java 8 classes. And that means you need to install it. I don't think that reduces the trouble ;-)

in reply to:  145 comment:146 by taylor.smock, 7 months ago

Replying to stoecker:

That usually only works correct if you also compile against the Java 8 classes. And that means you need to install it. I don't think that reduces the trouble ;-)

From JEP 247

automatically configures the compiler to produce class files that will link against an implementation of the given platform version

What javac --release does is set --source, --target, and --bootclasspath. The important one is the latter; it is what prevents us from accidentally using newer methods/classes. The source of that definitions is $JAVA_HOME/lib/ct.sym. It is a maintenance burden for upstream Java, which is why Java 21 gives a deprecation warning when compiling for Java 8 -- they only support N-3 LTS versions.

See also #20920.

comment:147 by stoecker, 7 months ago

Did the behaviour change somewhen? Because last time I tried I got results which were old java byte-code but still didn't work.

in reply to:  147 comment:148 by taylor.smock, 7 months ago

Replying to stoecker:

Did the behaviour change somewhen? Because last time I tried I got results which were old java byte-code but still didn't work.

It must have if it wasn't previously working.

Here is how I tested:

public class Test {
  public static void main(String... args) {
    System.out.println(" ".isBlank()); // isBlank -> isEmpty later, to check javac 17 compiling to java 8 bytecode
  }
}
$ java -version
openjdk version "17.0.8.1" 2023-08-24 LTS
OpenJDK Runtime Environment Zulu17.44+53-CA (build 17.0.8.1+1-LTS)
OpenJDK 64-Bit Server VM Zulu17.44+53-CA (build 17.0.8.1+1-LTS, mixed mode, sharing)
$ JAVA_HOME="$(/usr/libexec/java_home -v 1.8)" java -version

openjdk version "1.8.0_382"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_382-b05)
OpenJDK 64-Bit Server VM (Temurin)(build 25.382-b05, mixed mode)

$ javac --release 8 Test.java && JAVA_HOME="$(/usr/libexec/java_home -v 1.8)" java Test
Test.java:3: error: cannot find symbol
    System.out.println(" ".isBlank());
                          ^
  symbol:   method isBlank()
  location: class String
1 error

$ javac --release 11 Test.java && java Test
true

If I then change isBlank to isEmpty and run the same command for the java 8 test

$ javac --release 8 Test.java && JAVA_HOME="$(/usr/libexec/java_home -v 1.8)" java Test
false

comment:149 by stoecker, 7 months ago

Looking at the recent changes and the increasing usage of Java 11 components I think we'll change our approach. We'll switch to Java 11 beginning next year (so 23.12 will be the last Java 8 release)!

comment:150 by skyper, 7 months ago

There is no java 21 available for stable Debian 12 (bookworm). Until openjdk-21 might be available in backports the plugins requiring java 21 won`t work.

comment:151 by taylor.smock, 7 months ago

I'm looking at updating the debian packages to depend upon Java 17.

@stoecker: Do you know off the top of your head how our debian packages are built?

comment:152 by stoecker, 7 months ago

With a Makefile I think. I'm not totally sure about the Debian/Ubuntu build process since for my own stuff I abstracted it away and create an RPM like spec file format and later forgot the details, but I think the Makefile in apt-source directory builds the packages ;-)

Changing for other Java versions probably only means to extend the control file? We could add java21 and 17 there. Assuming that | means OR that would make it future proof ;-) Please provide the correct names for that (do the packages follow the same naming or did it change like it usually does).

cat DEBIAN/control

Package: josm-latest
Version: 1.5.svn{{VERSION}}
Section: utils
Maintainer: josm developers <josm-dev@openstreetmap.org>
Homepage: https://josm.openstreetmap.de
Priority: extra
Architecture: all
Depends: openjdk-11-jre | java11-runtime | openjdk-8-jre | java8-runtime,
         proj-data, fonts-noto, openjfx
Description: Editor for OpenStreetMap (daily development snapshot)
...

comment:153 by taylor.smock, 7 months ago

I was going to add default-jre (>= 2:1.17) -- I don't know what it is for anything earlier than Debian Buster (oldoldstable) which is 2:1.11.

I'll just manually repackage it for testing purposes, since I was running into issues with dpkg-buildpackage.

comment:154 by sebastic, 7 months ago

You only need to specify a single jre package with the alternative dependency using the minimum runtime version, the java<N>-runtime virtual package is provided by all relevant jre packages (e.g. ones created by java-package).

If you want to get users to upgrade to openjdk-17 you can change the dependencies to:

Depends: openjdk-17-jre | java8-runtime,
         proj-data, fonts-noto, openjfx

That does not automatically change the alternatives, for that update-java-alternatives should be used.

comment:155 by stoecker, 7 months ago

Remember this needs to work for new and old Debian and Ubuntu!

comment:156 by stoecker, 7 months ago

Thought we probably could drop some releases (especially Ubuntu). I'm pretty sure some of them are already out of support...

currently it's:
mantic lucid natty oneiric precise quantal raring saucy trusty utopic vivid wily xenial yakkety zesty artful bionic cosmic disco eoan focal groovy hirsute impish jammy kinetic lunar noble

comment:157 by taylor.smock, 7 months ago

I'm in the process of manually updating the file in a current archive release so I can use it for testing. And documenting how I'm doing it so someone looking at svn history knows how to do it in the future.

  1. curl -O https://josm.openstreetmap.de/apt/pool/universe/j/josm-latest/josm-latest_1.5.svn18887_all.deb
  2. ar x josm-latest_1.5.svn18887_all.deb control.tar.xz
  3. tar xf control.tar.xz control
  4. Edit control to match new control
  5. xz --decompress control.tar.xz && tar uvf control.tar ./control && xz control.tar
  6. ar r josm-latest_1.5.svn18887_all.deb control.tar.xz

Thought we probably could drop some releases (especially Ubuntu). I'm pretty sure some of them are already out of support...

Current versions in support:

  • 23.10 Mantic (2024-07-01)
  • 23.04 Lunar (2024-01-20)
  • 22.04 Jammy (2027-04-01 for standard LTS, 2032-04-02 for extended LTS)
  • 20.04 Focal (2025-04-02 for standard LTS, 2030-04-02 for extended LTS)
  • 18.04 Bionic (2028-04-01 for extended LTS)
  • 16.04 Xenial (2026-04-02 for extended LTS)
  • 14.04 Trusty (2024-04-02 for extended LTS)
Last edited 7 months ago by taylor.smock (previous) (diff)

comment:158 by sebastic, 7 months ago

I recommend to not support any Ubuntu release that's out of standard support: https://wiki.ubuntu.com/Releases

That leaves you with the two most recent LTS releases: focal & jammy

And two non-LTS releases: lunar & mantic

openjdk-17 is available since bionic: https://launchpad.net/ubuntu/+source/openjdk-17

Last edited 7 months ago by sebastic (previous) (diff)

comment:159 by stoecker, 7 months ago

Hmm, are these all Ubuntu. No Debian?

comment:160 by taylor.smock, 7 months ago

Debian has

  • Buster
  • Bullseye
  • Bookworm
  • Trixie
  • Sid

I think debian users use alldist.

comment:161 by stoecker, 7 months ago

So "alldist trusty xenial bionic focal jammy lunar mantic" should remain. sebastic would also drop first 3, but 3 more aren't so much when I drop 21 ;-)

comment:162 by stoecker, 7 months ago

Stripped the distros.

comment:163 by taylor.smock, 7 months ago

I've verified the control changes (as in, "does JOSM install and run") on:

  • Buster (oldoldstable). Note: There was an issue during ca-certificates install which is not our problem. Retrying worked. Installs Java 11 instead of Java 17 with default-jre (>=2:1.17), probably because it also matches java8-runtime. EOL is 2024-06-30.
  • Bullseye (oldstable)
  • Bookworm (stable)
  • Trixie (testing)
  • Sid (unstable)
  • 18.04 Bionic
  • 20.04 Focal
  • 22.04 Jammy
  • 23.04 Lunar
  • 23.10 Mantic

We should drop trusty -- it does not have Java 8 in their repositories.
We should also drop xenial, since it uses Java 9 for default-jre, and Java 9 has been EOL for quite some time (Java 11 is not in xenial's repositories). In any case, the version of Java 9 used by xenial seems to have issues (like no --add-modules).

Control changes: Depends: default-jre (>= 2:1.17) | java8-runtime,

Test setup: podman run -it --rm --volume $(pwd):/mnt ${IMAGE} /usr/bin/bash -c "apt update && apt install -y /mnt/josm-latest_1.5.svn18887_all.deb && josm-latest --version && josm-latest --status-report"
See comment:157 on how the deb file was generated.

comment:164 by stoecker, 7 months ago

All done.

comment:165 by taylor.smock, 7 months ago

In 18889/josm:

See #17858: Add Java 17 as an option for the Java version in deb packages

By depending upon default-jre with a version specification, we can avoid
hardcoding many specific Java JREs versions via |. Instead, we just indicate
that the default-jre must be >= 17 or the currently installed version must be
Java 8 compatible. This will change on 2023-12-31 when Java 8 support is dropped.
See #17858 for details.

This was verified via the following in an Ubuntu 23.04 container:

  1. curl -O https://josm.openstreetmap.de/apt/pool/universe/j/josm-latest/josm-latest_1.5.svn18887_all.deb
  2. ar x josm-latest_1.5.svn18887_all.deb control.tar.xz
  3. tar xf control.tar.xz control
  4. Edit control to match new control
  5. xz --decompress control.tar.xz && tar uvf control.tar control && xz control.tar
  6. ar r josm-latest_1.5.svn18887_all.deb control.tar.xz

The resulting deb package was then tested against Debian Buster, Bullseye,
Bookworm, Trixie, and Sid, along with Ubuntu 18.04, 20.04, 22.04, 23.04, and
23.10 with
podman run -it --rm --volume $(pwd):/mnt ${IMAGE} /usr/bin/bash -c "apt update && apt install -y /mnt/josm-latest_1.5.svn18887_all.deb && josm-latest --version && josm-latest --status-report"

comment:166 by skyper, 7 months ago

Something does not work as there is no newer josm-latest package available than r18887.

comment:167 by taylor.smock, 7 months ago

I'm going to go out on a limb and assume that whatever we use to build the deb packages didn't like the changes. They are valid (I did test the changes manually since I have no clue what we actually use to build the packages). I didn't use the standard debian build tools for testing since I didn't know which one we were using, and the first one I tried didn't like the original control file.

@stoecker: How would you feel about building the deb packages on GitHub CI? If you are worried about vendor lock-in, Gitea has a CI workflow that is compatible with GitHub actions.

comment:168 by sebastic, 7 months ago

The official Debian buildds (using sbuild) don't take alternative dependencies into consideration when installing build dependencies, so when default-jre (>= 2:1.17) isn't installable the build will fail. Other resolvers like those in pbuilder/cowbuilder chroots fall back to the alternative java8-runtime virtual package as expected.

comment:169 by taylor.smock, 7 months ago

sbuild might be the one I tried first -- it fails for various reasons:

  1. No changelog (I made a local one for testing)
  2. Needs Source field in control

So I highly doubt we are using sbuild.

I just tried dpkg-deb (from dpkg), and that largely worked. All I had to do was "fix" the Version field.
ant dist && cp dist/josm-custom.jar native/linux/latest/usr/share/josm-latest/josm-latest.jar && dpkg-deb --build --root-owner-group native/linux/latest/ test.deb

Again, I have no clue what we are actually using.

comment:170 by stoecker, 7 months ago

As far as I see we're using "dpkg -b" to build the package.

The issues seems not with the build, but the repo. I simply deleted the old stuff and reprepro complained that I need to cleanup. We'll see if the next release works error-free.

How would you feel about building the deb packages on GitHub CI?

Things which work on the Linux server wont go to external servers. Only stuff which wont run on the Linux server like the Windows and Mac packages.

comment:171 by taylor.smock, 7 months ago

The issues seems not with the build, but the repo.

Good to know. My standard assumption when I just changed something that is now failing is that it is something I did.

Things which work on the Linux server wont go to external servers. Only stuff which wont run on the Linux server like the Windows and Mac packages.

I'm still tempted to add it to the GitHub actions, mostly as a sanity check. Although we probably won't need it for several years.

in reply to:  149 comment:172 by anonymous, 4 months ago

Replying to stoecker:

Looking at the recent changes and the increasing usage of Java 11 components I think we'll change our approach. We'll switch to Java 11 beginning next year (so 23.12 will be the last Java 8 release)!

I updated the StartupPage version check to tell Java 11 is minimum requirement.

comment:173 by taylor.smock, 3 months ago

In 18985/josm:

Fix #23355: Sanity check JVM arguments on startup

See #17858: JOSM will no longer continue running if the user is on an unsupported
Java version (for this commit, older than Java 11; message indicates Java 17).
This does update the link for Azul from Java 17 to Java 21 as well.

In order to (hopefully) reduce confusion, the webstart and Java update nags will
also be reset in the event that JOSM will exit due to old Java versions. This is
mostly so that users will get the messages to update to OpenWebstart or the
appropriate Java link for their platform and architecture.

Additionally, this will (hopefully) reduce the number of tickets we have to close
due to missing JVM arguments by informing users of the missing arguments at startup.

comment:174 by taylor.smock, 2 months ago

Description: modified (diff)

comment:175 by taylor.smock, 2 months ago

In 19018/josm:

See #17858/#23564: Update Java versions in Linux start scripts

Additions:

  • Java 19-20 (EOL, added for completeness)
  • Java 21 (preferred LTS)
  • Java 22 (latest Java version)
  • Java 23 (next Java version)

Removals:

  • Java 8, 9, and 10: We no longer support Java < 11.

in reply to:  150 comment:176 by skyper, 6 weeks ago

Replying to skyper:

There is no java 21 available for stable Debian 12 (bookworm). Until openjdk-21 might be available in backports the plugins requiring java 21 won`t work.

Well, openjdk-21-jre is in testing (trixie) but still not even sources for openjdk-21 are available in current stable (bookworm) which means that the next 14 month all plugins requiring java21 are not usable for Debian users. Please, keep that in mind when updating plugins. Thanks a lot.

comment:177 by stoecker, 5 weeks ago

I changed server installation. Java8 is out. Tomorrow it will start building with Java 11.

comment:178 by stoecker, 5 weeks ago

In 19044/josm:

switch build-xml to java 11 and drop java 9 support, see #17858

comment:179 by gaben, 5 weeks ago

There are also version="1.8+" mentioning in the JNLP files.

comment:180 by stoecker, 5 weeks ago

In 19047/josm:

switch JNLP to 11 (hope this is right, can't test here), see #17858

comment:181 by taylor.smock, 5 weeks ago

switch JNLP to 11 (hope this is right, can't test here), see #17858

Worked for me with OpenWebStart.

comment:182 by GerdP, 5 weeks ago

The file josm\core\tools\eclipse\JOSM (Java 8).launch is probably also obsolete now?

comment:183 by taylor.smock, 5 weeks ago

I would think so. :)

If no one has deleted it by the time I finish going through dependency updates and fixing new issues from the various tools, I'll go ahead and remove it at the same time.

comment:184 by stoecker, 5 weeks ago

What's the advantage of replacing all variable types with var? That's much harder to read than the previous code. If this is not faster please revert the changes. I agree that this has advantages in some cases, but normally explicit variable types are much better. That's a lesson learned from using many different languages.

Last edited 5 weeks ago by stoecker (previous) (diff)

comment:185 by anonymous, 5 weeks ago

Also the build.xml contains <property name="java.lang.version" value="8" />. Is it correct? (I have no clue at the moment, just looking for Java 8 remains.)

in reply to:  185 comment:186 by gaben, 5 weeks ago

Replying to névtelen:

Also the build.xml contains <property name="java.lang.version" value="8" />. Is it correct? (I have no clue at the moment, just looking for Java 8 remains.)

That was me, forgot to log in.

comment:187 by GerdP, 5 weeks ago

You probably didn't update to r19048 yet?

comment:188 by gaben, 5 weeks ago

Ooh, yes I missed that.
(Btw I like clicking on r19048, why escaping?)

comment:189 by GerdP, 5 weeks ago

Because the relevant change was in r19044

in reply to:  184 comment:190 by taylor.smock, 5 weeks ago

Replying to stoecker:

What's the advantage of replacing all variable types with var? That's much harder to read than the previous code. If this is not faster please revert the changes. I agree that this has advantages in some cases, but normally explicit variable types are much better. That's a lesson learned from using many different languages.

I can revert it -- I was mostly doing it to avoid drifting from the sonarlint recommendations. S6212 is the specific rule.

I'll go ahead and keep var when it is var foo = new Foo().

comment:191 by stoecker, 5 weeks ago

Please revert it. Hiding the explicit type in most cases does no harm, but forcing the developer to explicitly change the type when he rewrites code is usually a good idea. Force him to think about it! Also when functions change their return it will cause an error instead of silently hiding this.

And we should disable this rule. It's a dumb recommendation: It encourages lazyness.

When not using an IDE (like me) the disadvantages are much more obvious.

P.S. That said: I don't mean that "var" shouldn't be used. In many cases it's probably perfectly fine shorter code.

in reply to:  191 comment:192 by taylor.smock, 5 weeks ago

Replying to stoecker:

And we should disable this rule. It's a dumb recommendation: It encourages lazyness.

I didn't like the rule anyway -- it is a PITA to convert things to var -- I tend to look at each case individually instead of using a code mod. It would save me time to turn it off. I can't do that (I don't have the permissions for that on our sonar instance).

When not using an IDE (like me) the disadvantages are much more obvious.

Fair.

P.S. That said: I don't mean that "var" shouldn't be used. In many cases it's probably perfectly fine shorter code.

Like I said in comment:190, I'll probably keep it when creating new objects like var foo = new Foo().

comment:193 by stoecker, 5 weeks ago

I think I disabled it. Also updated to sonar 9.9.4.

comment:194 by anonymous, 3 weeks ago

The README file shown via Help -> About still refers to JRE 8.

The likely needs to be updated to 11, e.g.:

--- a/README
+++ b/README
@@ -9,12 +9,12 @@ Installation notes
 To run JOSM, you need:
 
 * The JOSM .jar file, e.g., josm-tested.jar or josm-latest.jar
-* Java Runtime Environment (JRE) 8, or later.
+* Java Runtime Environment (JRE) 11, or later.
 
 
 How to get Java Runtime Environment
 -----------------------------------
-You need JRE Version 8, or later.
+You need JRE Version 11, or later.
 
 Microsoft Windows and Apple macOS users should visit one of:
 - https://www.azul.com/downloads/?package=jdk#download-openjdk

comment:195 by stoecker, 3 weeks ago

In 19073/josm:

see #17858 - Java 8 → 11

Modify Ticket

Change Properties
Set your email in Preferences
Action
as assigned The owner will remain Don-vip.
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from Don-vip to the specified user. Next status will be 'new'.
Next status will be 'needinfo'. The owner will be changed from Don-vip to Don-vip.
as duplicate The resolution will be set to duplicate. Next status will be 'closed'. The specified ticket will be cross-referenced with this ticket.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.