![]() ![]() But as you can probably imagine, it can be very tempting to use undocumented behavior in some cases. To be fair, these changes should in theory not cause any compatibility issues, because they only affect undocumented classes and assumptions that were never guaranteed to be true in future Java versions. ATLauncher's code used undocumented classes as well as the class loader hack. This is an issue because a very popular hack to extend the classpath at runtime assumes that the default class loader is a URLClassLoader. This is based on the (also new) module system, which required some changes to class loading, which resulted in the default class loader no longer being a URLClassLoader. Would it be a big issue to just package the launcher's libraries in the jar? This would remove the need for any classpath The main breaking change is that use of com.sun.* and sun.* classes is now disallowed completely, as opposed to being just bad practice. It seems overkill though to have two Java processes for the launcher alone. One option would be to make a small main class that downloads the necessary libraries, and then starts a Java subprocess for the main launcher code and sets the classpath correctly on the command line. Sadly all workarounds that I could think of are more complicated than they should be. That doesn't work though, because the custom URLClassLoader uses the system class loader to load the App class, so App's class loader is still the system class loader and not the custom one. I've tried to get around this by making a new URLClassLoader and using that to load the main App class. 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). 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. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |