Skip to content

Conversation

@jimlloyd
Copy link
Contributor

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.

… 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?
@jsdevel
Copy link
Collaborator

jsdevel commented Oct 17, 2014

@jimlloyd can you add macros to handle 1.6?

@jimlloyd
Copy link
Contributor Author

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.

@jsdevel
Copy link
Collaborator

jsdevel commented Oct 17, 2014

I think there may be a constant defined in jni.h or something. Not sure though.

@jimlloyd
Copy link
Contributor Author

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.

@jimlloyd
Copy link
Contributor Author

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.
@jimlloyd
Copy link
Contributor Author

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.
@joeferner
Copy link
Owner

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.

@jimlloyd
Copy link
Contributor Author

Hmm, that sounds good. You're probably right, as it seems that my hack test
with gremlin-node 'passes' with all of the .class files reverted to the
ones checked into master. FYI my hacky test is just attempting to run unit
gremlin-node unit tests. They don't even run due to errors I have yet to
address, but the first error I was seeing has gone away, which indicates
that I can successfully import a .class file targeted to jdk1.8.

We should add some test classes compiled with jdk1.8 that use new language
features. We'll have to make those tests be conditioned on the jdk1.8
runtime being present. I'll work on that next week.

On Fri, Oct 17, 2014 at 3:53 PM, Joe Ferner notifications@github.com
wrote:

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.


Reply to this email directly or view it on GitHub
#164 (comment).

@jimlloyd jimlloyd mentioned this pull request Oct 20, 2014
@jimlloyd
Copy link
Contributor Author

Closing this PR, which has been superseded by PR #166.

@jimlloyd jimlloyd closed this Oct 20, 2014
@jimlloyd jimlloyd deleted the feature/jdk8-on-macosx branch October 21, 2014 05:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants