-
Notifications
You must be signed in to change notification settings - Fork 185
[Future] Advance Forge Code to fit Java 8 Source Level #141
Comments
is there anyway that thermos will ever see 1.8 or 1.9? |
I am considering that as a project for June, right now there are more pressing issues that need to be dealt with. |
so it is possible? |
Yup, but not definitive |
Hmm..adding |
Does forcing java 8 simply not work due to forge trying to use the older java 6 bytecode? Optimization gains are always a nice thing to have, especially on large servers that take several minutes to load. |
Yeah, -noverify allows the server to start and run, but I'm not sure how stable it is |
well if it's confirmed to be stable, might want to figure out how to make -noverify defaulted |
It would require that everyone add it as a startup script argument, don't think it's possible to automatically apply it |
Slated for BL31 |
Java 8's bytecode introduces some compile-time optimizations over Java 6's bytecode.
Forge defaults to the outddated Java 6 bytecode, and no one should be using JDK6 anymore, it's pointless to default to it. However, forcing Java 8 does not work, the code needs to be manually examined for source level compat issues.
According to Oracle, JDK9 (slated for early 2017) will introduce new bytecode modifications to allow for more optimized String operations (http://openjdk.java.net/jeps/197).
While performance gains from changing the source level are widely disputed, it should nevertheless be raised to support JSR proposals for JDK9 (and those that were implemented in JDK8).
Edit: I meant proposal 280 (http://openjdk.java.net/jeps/280)
The text was updated successfully, but these errors were encountered: