Java 9 got released! #334
Comments
|
LWJGL 3 works great on Java 9. You don't have to do anything special and it runs without There are no JPMS modules, but the JARs include The other Java 9 feature in LWJGL is multi-release JAR files. The core library is such a JAR and it includes custom code that uses the new StackWalker API to improve performance when
Unfortunately
|
|
It works for me, but I'm getting this warning when I use java 9 only: |
|
@TheMrMilchmann indeed, LWJGL 3.1.1 and up should not produce a warning. @francogp it looks like you're on 3.1.0, upgrading to the latest release is highly recommended. |
|
It also appears as though it is not building correctly, but knowing me it is me screwing it up and not Java 9. .-. Java version: Here is what I did: |
|
That's a problem with the lwjgl3-generated repository, the two Btw, the targets |
|
I understand that those are optional, figured it would be best to do those just in case. |
Ahh that sucks. Well at least with the 6 month release cycle we might get Panama sooner, I hope.
Multi-release JARs are pretty cool, I didn't know about them. On the other hand, StackWalker API was long overdue. Makes no sense hoping the JIT works it's magic when you only want to traverse a single stack level to find the calling method name rather than printing the whole stack trace. Thanks for your answer! Do we close this then? Or leave it open for any other Java 9 questions people might have? |
Lets keep it open for a while. The latest 3.1.4 snapshot (build 3) has a change that fixes the Also, all natives JARs now have a manifest, with an automatic module name similar to the corresponding binding (e.g. |
|
Will there be support for those multi-jar things to allow one native jar file? |
Not sure what you mean exactly. Multi-release JAR files allow you to have a class multiple times, implemented differently for different Java versions. There's no technical issue with having all natives in one JAR file. They are in different files to avoid excessive download times (you only need 1/3 of them on a given system). If necessary, they can be recombined in whatever way makes sense for the application that uses LWJGL. |
|
I guess I mis-read, thought you could do resources and code per-platform with those. My mistake. |
|
I've been experimenting with modules in another project and found an important problem with automatic modules; the jlink tool cannot use them to create a custom run-time image. The entire project must be contained in explicit modules. It is possible to add Using jlink won't be critical for a lot of projects, but I think projects using LWJGL (e.g. games) will be very interested in having a compact runtime (or using AOT compilation in the future). I'll try to make the build produce binaries with automatic modules when building on Java 8 and with explicit modules when building on Java 9+. |
This enables applications using LWJGL to be bundled in custom run-time images with the jlink tool.
|
The latest 3.1.4 snapshot (build 5) has replaced Technical detailsLWJGL classes continue to be compiled with Java 8 and all jars are Java 8 compatible. The above change adds a The LWJGL module definitions can be found here. It is not valid Java code, these files would normally be called
ExampleAssuming the LWJGL jars have been downloaded to Notes:
|
|
No further issues related to Java 9 have been reported, so I'm closing this. Thanks everyone! |
|
So I may be missing something here, but I'm attempting to modularize a previously working project in Eclipse Oxygen 4.7.2, with Java 9 and LWJGL 3.1.5 stable, and am receiving this message (with org.lwjgl.util.DebugLoader=true and org.lwjgl.util.Debug=true) Generated command line (sanitized slightly): Basically, imagine I have two projects, "GameProject" and "LwjglProject," both of which are modules compiled with Java 9. In Eclipse terminology, underneath Throwing everything into the Classpath isn't a great option for a number of reasons (firstly because I'd like to use jlink to create a compressed runtime image for my project, secondly because Eclipse chokes even harder when I attempt to do so (projects fail to import anything from modules placed on the classpath, weirdly), which is probably an issue on their end. Eclipse is giving me a lot of dang issues with this.) If this isn't a bug an your end, then any ideas would still be greatly appreciated. Thank you! |
|
I'm not familiar with Eclipse so I cannot advise about the project setup. You could try running the generated command line manually, with Unless demonstrated otherwise, there are no bugs related to JPMS in LWJGL. We even have applications in production running via jlinked images using LWJGL. Btw, |
|
Ahah! I ran with Thanks much, never would have guessed that without that command line option. |
|
Looks like native modules must be required explicitly after #363. Before: require org.lwjgl;
require org.glfw;
require org.opengl;After: require org.lwjgl;
require org.lwjgl.natives;
require org.lwjgl.glfw;
require org.lwjgl.glfw.natives;
require org.lwjgl.opengl;
require org.lwjgl.opengl.natives;Compilation works without the native modules, but:
Given the above, using
That way the native modules remain optional, but if used, the above example becomes: require org.lwjgl.natives;
require org.glfw.natives;
require org.opengl.natives;and everything resolves nicely in both javac and jlink/IDEs. |
I'm not quite sure what you mean here. What exactly fails? (btw: The option is called For me the following is working perfectly fine: (I'm fully aware that those are not the actual modules but the behaviour should theoretically be the same.) |
|
I tested again using My argument is that even though the current setup is technically correct, it is not very helpful. You need to worry about lwjgl3 natives when running jlink (which is not trivial in the first place) and also when running the output image. |
|
I'll just add for anyone reading - given the difficulty of getting anything
working with Java 9 (e.g. Eclipse, VisualVM, ProGuard, etc), I wound up
just falling back to Java 8, but still shipping a minimal runtime image
with jlink by explicitly adding the required modules via `--add-modules`.
Seems to work just fine, and saves you the massive burden of migrating and
dealing with tools that haven't been updated yet. You just have to make
sure you're really including every module needed, otherwise you'll get
runtime exceptions.
I'll also note that I had to fall back to an earlier version of LWJGL,
because ProGuard would choke on the `module-info.class` files when
attempting to obfuscate everything. Not really an LWJGL issue, but it's
worth mentioning.
…On Sat, Jan 13, 2018 at 4:08 AM, Ioannis Tsakpinis ***@***.*** > wrote:
I tested again using --add-modules and jlink indeed adds the natives
module to the image (it is listed in java --list-modules). However, the
natives are not resolved when the application runs. I just figured out that
if you do java --add-modules <native modules>, then it works.
My argument is that even though the current setup is technically correct,
it is not very helpful. You need to worry about lwjgl3 natives when running
jlink (which is not trivial in the first place) and also when running the
output image.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#334 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA2wNhTSCfVk2jNJj5JtyznzEgDR0juqks5tKIC5gaJpZM4PhWzF>
.
|
|
@philipguin Isn't there a ProGuard option to ignore |
|
The latest 3.1.6 snapshot (build 11) includes the following changes: A natives module now has a transitive dependency to the corresponding Java module.As described above, this fixes applications that deploy shared libraries in a custom way. Such an application would declare: require org.lwjgl;
require org.lwjgl.glfw;
require org.lwjgl.opengl;
// ...
require org.lwjgl.vulkan;and then use a custom classpath or library path when launching the application. Applications that need to ensure that the natives are in the module path, again declare one line per binding (like on LWJGL 3.1.5), but with the require org.lwjgl.natives; // read as: "org.lwjgl with natives", org.lwjgl will be resolved by the transitive dependency
require org.lwjgl.glfw.natives;
require org.lwjgl.opengl.natives;
// ...
require org.lwjgl.vulkan; // the Vulkan bindings do not have nativesWarning to Maven users: Maven tries to produce an appropriate
|
So, how well LWJGL 3 plays with it and jigzaw? I remember @Spasi mentioning something about moving to VarHandles instead of relying on sun.misc.Unsafe. What would this entail?
The text was updated successfully, but these errors were encountered: