Relocating remaining javax.media.opengl.* -> com.jogamp.opengl.* to relax probable license issue while bundling JOGL. ========================================= This is more a discussion .. and applying such change would require most users to agree. +++ Preface (you may skip this): +++ Motivation of this discussion are the possible restrictions of providing a virtual machine (VM) runtime environment (RE) 'based on java' to be used by jogamp and clients. [1] http://en.swpat.org/wiki/Java_and_patents [1.1] http://en.swpat.org/wiki/Java_and_patents#OpenJDK:_the_GPLv2_Java_from_Oracle [2] http://en.swpat.org/wiki/Oracle_v._Google_%282010,_USA%29 [2.1] http://en.swpat.org/wiki/Oracle_v._Google_%282010,_USA%29#Does_the_grant_in_the_Java_Language_Specification_help.3F Well, [1.1] claims an implicit patent licences, and hence using OpenJDK and even heavily modified OpenJDK to be 'safe' !? [2.1] mentions that all claims need to be met to have the Java Language patent grant, including: (iii) do not add any additional packages, classes, or interfaces to the java.* or javax.* packages or their subpackages; (iv) pass all test suites relating to the most recent published version of the specification of the Java 2 Platform, Standard Edition, that are available from SUN six (6) months prior to any beta release of the clean room implementation or upgrade thereto; So if any vendor likes JOGL to be included in their java release itself, we would cause a violation of (iii). Since JOGL shall not be included in the java release itself, but as a 3rd party package, I guess this is a no issue. But I may be wrong here ofc. Remarks ? For sure (iv) is nothing we can do about it, i.e. Oracle probably will refuse a vendor to pass a TCK license in case they don't obey Oracle's wishes (-> Apache Harmony, Mobile Devices, ..). [1.1] claims that all these restriction of [2] maybe non-sense if using OpenJDK or a derived form of it .. ? If this is true - we could ofc simply bundle a subset of the RT.JAR (headless, no AWT) with any VM and should be on the safe side (?) However, it is also mentioned that VMs as provided by IcedTea may conflict the the license .. +++++++++++ IMHO such effort would not only cause inconvenience w/ users, but also may imply that we have accepted the above mentioned Java licence [2.1] and would make us 'guilty' of anticipatory obedience. Further more I like to note that the JOGL namespace 'javax.media.opengl' was created at Sun Microsystems Inc. and implicitly [at least] had it's blessing. However, it was never intended to be bundled w/ a JRE. Well, on the other side - if such change would easy bundling JOGL with some sort of Java'ish VM which uses some sort of bytecode or even native compilation - we may vote for such a change. I am very unclear here - and I guess even above use-case is irrelevant, since it's not 'Java'. +++++++++++
You can use the re-enabled 'voting' feature in the 'Importance' line above!
This has my vote.
This has my vote. Actually, I would like us to move all classes from javax.media.* and javax.media.nativewindow.* into com.jogamp.*. As it would be a big change for the public API and as it would break all existing applications, it should be in a major version (JOGL 3?). It's not only a bad thing because it would break some poor video tutorials posted on Youtube too, it would show that their authors don't care providing up-to-date resources. It could be done in 2 steps: - don't duplicate the code, copy the classes into com.jogamp.*, drive the classes in javax.media.* deprecated, only retain the public methods in them, use those classes as facades of the new classes - remove the deprecated classes The first step could be done in JOGL 2.3, the second step could be done in JOGL 3. Moreover, it would solve a major problem occurring very often under OS X. There are still completely obsolete versions of Java 3D installed as extensions, they are loaded in priority and it is sometimes impossible to skip their loading depending on the version of the JVM and the deployment mechanism. Those obsolete versions of Java 3D (1.5.1?) use JOGL 1. As a consequence, it can cause some conflicts when an application uses JOGL 2 even though it doesn't use Java 3D. Java 3D should provide some JARs with renamed packages too in order to fix this problem once for all without breaking the public API. I remind you that dropping the JARs into the JVM or in a directory used by the extension mechanism is strongly discouraged: http://jogamp.org/jogl/doc/userguide/#badpractice
As Julien suggested moved to version 3, iff we accept this task.
(In reply to comment #5) > As Julien suggested moved to version 3, iff we accept this task. Still have to see whether this needs a 3.x.y version, since our versioning scheme would allow a 2.x.*, i.e. minor version number change incl. API change.
Maybe the version 2.4 or 2.3.1 is more suitable for the second step.
No opinion on what version ths should be called (I'd mildly prefer 3.x) but I'm supportive of the change in namespace.
The name clash causes some troubles even for developers not using Java 3D and still in OS X 10.10 (Yosemite), for example with Processing and Jzy3D: http://stackoverflow.com/questions/26515228/cant-run-3d-scripts-in-processing-java-opengl-related http://stackoverflow.com/questions/19229313/java-lang-nosuchmethoderror-javax-media-opengl-gldrawablefactory-initsingleton If possible, I would prefer migrating to org.jogamp.* as it matches with the domain we use and it would avoid any mixing with JOGL 2 versions with the "old" package naming but then this change should be done in JOCL and JOAL as well.
I'm in favor too. It always seemed odd that we had stuff in javax.media.opengl.*, I assume this was left over from the Sun days :) I also like Julien's idea about using org.jogamp.* instead of com.jogamp.*, since then it would match our domain, but I'm not sure what other problems/concerns that might cause.
(In reply to comment #10) > I also like Julien's idea about using org.jogamp.* instead of com.jogamp.*, > since then it would match our domain, but I'm not sure what other > problems/concerns that might cause. Please can you elaborate? Do classes located in javax.media.* benefit of a special treatment in the application class loader?
> Please can you elaborate? Do classes located in javax.media.* benefit of a > special treatment in the application class loader? I just meant that right now, there seem to be at least three package roots in JogAmp, e.g.: com.jogamp.* jogamp.* javax.media.* If we change javax.media.* to com.jogamp.*, that still leaves two package roots (jogamp.* and com.jogamp.*). If we change javax.media.* to org.jogamp.*, then we'd still have three package roots (org.jogamp.*, com.jogamp.*, and jogamp.*). If we eventually wanted to put *everything* under one root, we'd have to change every file (or a large percentage of the files) in the project, depending on which new root we choose. That might be quite a big change :)
Actually, I meant we could keep jogamp.* and move things from com.jogamp.* and java.media.* to org.jogamp.*.
Disabling the extension mechanism when using OpenJDK and Oracle Java can break NIO 2 as one of its file system providers is in /jre/lib/ext, see zipfs.jar (despite its name, it is used for JARs too): java.nio.file.FileSystemNotFoundException: Provider "jar" not installed
I'm still investigating. I still need to check whether the obsolete versions are in some directories mentioned in the CLASSPATH environment variable or detected as extensions by the Apple JVM under Mac OS X. OpenJDK and Oracle Java use lib/ext as default directory for extensions. Moreover, the support of both endorsed standards and extensions will be removed in Java 1.9: http://openjdk.java.net/jeps/220 If the name clash only concerns Apple JVM, maybe we should rather officially stop supporting it. Personally, I would even stop supporting Java <= 1.6 except for Android in order to ensure that nobody tries to use JOGL with Apple JVM.
Emmanuel already tried to override java.ext.dirs: https://lists.apple.com/archives/Java-dev/2007/Aug/msg00477.html It means that Apple Java probably uses a different set of directories in java.ext.dirs. Some end users still install Apple Java under Mac OS X 10.10 Yosemite to get rid of some popups: https://discussions.apple.com/thread/6608589?start=0&tstart=0
As stated on IRC: < rmk0> that rename of the packages into the com.jogamp.* namespace might be good for technical reasons too. i ran into this problem with xom last month: < rmk0> http://lists.ibiblio.org/pipermail/xom-interest/2014-December/004426.html < rmk0> basically... the most recent android dx tool doesn't like anything putting itself into the java.* or javax.* namespace < rmk0> presumably they put all of this in after the oracle case < rmk0> it obviously didn't complain with that maven/jogl/android example back when i did it
First batch of changes committed: oculusvr-sdk 946d61628f32123243be3ebf2a56d6bce536db77 jogl 1ec82447e464d5308442581f14d32f9775928454 jogl 78b4918b207e16b967e8335fb8ec1b31c706c507 jogl a9618639f47beafb7e1a87533cee6eb5f2f3ba8a jocl 84a5372eda5da00a1c4ce51d9d9faea68523dbd6 - renaming - relocation Manual compilation and short tests on GNU/Linux x86_64.
All changes validated w/ latest aggregated autobuild http://jogamp.org/deployment/archive/master/gluegen_844-joal_575-jogl_1371-jocl_1032-signed/
Branch ready to merge: https://github.com/xranby/gluegen/tree/bug682 https://github.com/xranby/gluegen/commit/d04ee580f3dbc4f9c6c7cd4ba2ab7cec5b38a452 Bug 682: Rename com.sun.gluegen -> com.jogamp.gluegen in doc/**