Making the ThinkDifferent classes be JDK version-independent. JDK 9… #5747
Conversation
… and later have a new java.awt.desktop package that replaces the custom handlers in the com.apple.eawt package. This commit uses java.lang.reflect.Proxy to generate handlers of the correct type.
|
Fixes bug: #5746. |
ssilverman
changed the title
ssilverman
changed the title
|
|
||
| // public ThinkDifferent(Base base) { | ||
| // this.base = base; | ||
| // } | ||
|
|
||
| /** | ||
| * Sets a handler on an instance of {@link Application}, taking into account JVM version |
There was a problem hiding this comment.
Should say "JDK version", but I don't want to make a new commit.
There was a problem hiding this comment.
My thinking on this is that the JDK includes the JVM plus libraries and other misc. stuff. You could theoretically change package names in the JDK 1.8 class files to JDK11-compliant names (eg. change com.apple.eawt to java.awt.desktop), and then run them on an older JVM (subject to only non-native code, etc). So my view is that this is still a JDK difference and not a JVM difference. JVM, in my mind, includes bytecodes plus support, and doesn't include the libraries (with some exceptions, eg. invokedynamic implementation).
There was a problem hiding this comment.
Some links:
- https://www.javaworld.com/article/3272244/core-java/what-is-the-jvm-introducing-the-java-virtual-machine.html
- https://en.wikipedia.org/wiki/Java_virtual_machine
It is my belief that these support my view of libraries, including the AWT, being part of the larger meaning of a "JDK" and not "JVM", especially in this instance, where the only major difference is the package name.
There was a problem hiding this comment.
Regarding me not wanting to make a "new commit", above, I've discovered that any new commits update this pull request. Makes life easier... :)
There was a problem hiding this comment.
To play devil's advocate with myself: Originally, "Java" was defined as a JVM plus libraries plus language, so in reality, I think the lines are kind of fuzzy anyway. I won't object to whatever's chosen, "JVM" or "JDK".
|
Instead of using reflection throughout, a better option is to invoke the necessary class that will work for the platform in use. Debugging code that's using this much reflection is a nightmare (we know because we've gone through lots of Java versions, all the way back to 1.1). Though to avoid these kinds of problems, if we move to Java 11, we'll likely do that and not provide any backwards compatibility (as discussed in #5753). |
|
What do you mean by invoke the necessary class? Are you saying have a compiled version for JDK 1.8 and another for JDK 11? My use of Processing is as part of a larger system. I use the core classes essentially as an easy-to-use graphics layer. I build my projects using Maven so I just use the core classes. However, I have to have different compiled versions of those classes for each JDK version because of those desktop package name changes. My goal with this pull request was to make it so the exact same set of compiled classes work across both JDK versions (8 & 11). If you don’t think that’s a tenable approach here, that okay, since it’s easy enough to just have to create two separate JAR versions. I’d rather be able to use one JAR file, but it’s not critical. I support the concept of moving to 11-only support, though. |
|
Fixed with benfry/processing4#1 and continued development happening at https://github.com/processing/processing4 |
… and later have a new java.awt.desktop package that replaces the custom handlers in the com.apple.eawt package. This commit uses java.lang.reflect.Proxy to generate handlers of the correct type, independent of the handler parameter types, which are different across JDK versions.
Specifically, this fixes being able to run a Processing app (externally or otherwise) on OSX using a JDK having a version > 1.8 (i.e. 9 and above).