| Summary: | Relocating remaining javax.media.opengl.* -> com.jogamp.opengl.* to relax probable license issue while bundling JOGL | ||
|---|---|---|---|
| Product: | [JogAmp] Jogl | Reporter: | Sven Gothel <sgothel> |
| Component: | core | Assignee: | Sven Gothel <sgothel> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | askinner, gouessej, harvey.harrison, org.jogamp, rami.santina, sgothel, wwalker3, xerxes, xerxes |
| Priority: | P1 | ||
| Version: | 2.3.0 | ||
| Hardware: | All | ||
| OS: | all | ||
| Type: | FEATURE | SCM Refs: |
oculusvr-sdk 946d61628f32123243be3ebf2a56d6bce536db77
jogl 1ec82447e464d5308442581f14d32f9775928454
jogl 78b4918b207e16b967e8335fb8ec1b31c706c507
jogl a9618639f47beafb7e1a87533cee6eb5f2f3ba8a
jocl 84a5372eda5da00a1c4ce51d9d9faea68523dbd6
|
| Workaround: | --- | ||
| Bug Depends on: | |||
| Bug Blocks: | 698 | ||
|
Description
Sven Gothel
2013-02-06 20:09:53 CET
You can use the re-enabled 'voting' feature in the 'Importance' line above! This has my vote. 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/** |