#Atlauncher java se binary code

This was the case up until Java 8, but in Java 9 the system class loader is no longer an URLClassLoader and the old hack doesn't work anymore. Currently the launcher downloads some libraries at runtime and adds them to the classpath, using a hack that only works when the system class loader is an URLClassLoader. I've done some testing, and ran into a new issue. I'm currently working on the Java 6 source compatibility in my fork and will probably make a PR for that soon. There are some odd cases which compile with JDK 8 and run on Java 6 but don't compile on JDK 9 in Java 6 mode (like JComboBox which was generified in Java 7).

#Atlauncher java se binary code

This means that the launcher code has to be fully compatible with the earliest Java we want to support, at the source level. JDK 9 now has data on what features the Java libraries supported in earlier JDK versions.I know at least one place where ATLauncher uses an undocumented class (which is to get the total system RAM to display it in the log), but there may be more. Almost all of the undocumented sun and com.sun classes cannot be used anymore - they are intentionally not part of any public module.

This shouldn't be too complicated to fix, we just need to add a module-info.java and list the necessary AWT/Swing/etc. You now have to declare which parts of the Java libraries you want to use, beyond core language classes.

I've looked into this a little, and the biggest issues I've noticed so far are: Still a while to go, but there are early-access builds already, and it may be good to get the launcher Java 9-ready early, since there are some likely problematic changes. JDK 9 is scheduled to come out at the end of July 2017.