Experimental hacks to use JDK8. Not backward compatible with JDK6.#164
Experimental hacks to use JDK8. Not backward compatible with JDK6.#164jimlloyd wants to merge 8 commits into
Conversation
… JDK6. These changes seem to be sufficient to make JDK8 work. This module's unit tests pass, and I have evidence that gremlin-node now accepts references to classes that were compiled for Java 8. We now have to figure out how to maintain backward compatiblity for JDK6. Perhaps we can simply detect which JDK is installed in JAVA_HOME and compile for it?
|
@jimlloyd can you add macros to handle 1.6? |
|
Yes, I'll figure out how to add macros. It seems that I should be able to specify something along the lines of '-source 1.8 -target 1.6', i.e I hope there is a way to enable 1.8 when built using JDK8 but still be fully compatible with JDK6 if JDK8 classes are not loaded. Researching how to do that now. If you know how, please reply back. |
|
I think there may be a constant defined in |
|
From the research I've done so far it looks like the notion of 'source 1.8 -target 1.6' is not possible. So I'm just going to aim for relying on JDK 1.8 when javac is version 1.8. My plan at the moment is to use your node-find-java-home as an example to find javac and then exec 'javac -version'. I'll then parse that response. If the response is 'javac 1.8.*' I'll set JNI_VERSION to JNI_VERSION_1_8, otherwise I'll set it to JNI_VERSION_1_6. To do this I will need to learn a bit more about gyp. Let me know if you see any flaws in this plan or have a better idea. |
|
Hmm, my plan is much too complicated. I'm just going to do some #ifdefs inside java.h. |
There are still problems we have to solve for a general release, but this version should do the right thing for jdk1.6 and jdk1.8. jdk1.7 will work, but it will no longer target 1.6. In addition to fixing the problem with jdk1.7, we also need to change the build system so that .java files are compiled to .class files as part of npm install, instead of checking them in.
|
Added a commit that gets us closer to a good solution. See the commit comment. I believe we have to move the javac compilation out of compile_java_code.sh and into the gyp build, and then remove the various .class files from version control. Let me know if I am missing something. |
This may not work, since we don't specify language: java The Travis documentation isn't clear, so let's just try it and see what happens.
Sorry, I should have been testing this on a different branch.
|
The .class files should be OK. I've been compiling them with the compile-java-code.sh which compiles them with 1.6 source compatibility so they should work with any newer JDK. |
|
Hmm, that sounds good. You're probably right, as it seems that my hack test We should add some test classes compiled with jdk1.8 that use new language On Fri, Oct 17, 2014 at 3:53 PM, Joe Ferner [email protected]
|
|
Closing this PR, which has been superseded by PR #166. |
3 participants
FOR REVIEW ONLY. DO NOT MERGE TO MASTER.
These changes seem to be sufficient to make JDK8 work.
This module's unit tests pass, and I have evidence that gremlin-node
now accepts references to classes that were compiled for Java 8.
We now have to figure out how to maintain backward compatibility for JDK6.
Perhaps we can simply detect which JDK is installed in JAVA_HOME and
compile for it?
This is tested only on my Mac with OS 10.9.5, and with jdk1.8.0_25.
The commit comment says "mac only", but the only iffy thing I did was change
compile-java-code.sh to use ${JAVA_HOME} instead of /opt/jdk1.6.0_45,
which I think should improve compatibility across platforms.