Bug 682 - Relocating remaining javax.media.opengl.* -> com.jogamp.opengl.* to relax probable license issue while bundling JOGL
Summary: Relocating remaining javax.media.opengl.* -> com.jogamp.opengl.* to relax pro...
Status: RESOLVED FIXED
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 2.3.0
Hardware: All all
: P1 enhancement
Assignee: Sven Gothel
URL:
Depends on:
Blocks: 698
  Show dependency treegraph
 
Reported: 2013-02-06 20:09 CET by Sven Gothel
Modified: 2019-03-29 17:54 CET (History)
9 users (show)

See Also:
Type: FEATURE
SCM Refs:
oculusvr-sdk 946d61628f32123243be3ebf2a56d6bce536db77 jogl 1ec82447e464d5308442581f14d32f9775928454 jogl 78b4918b207e16b967e8335fb8ec1b31c706c507 jogl a9618639f47beafb7e1a87533cee6eb5f2f3ba8a jocl 84a5372eda5da00a1c4ce51d9d9faea68523dbd6
Workaround: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2013-02-06 20:09:53 CET
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'.

+++++++++++
Comment 1 Sven Gothel 2013-02-06 20:16:45 CET
You can use the re-enabled 'voting' feature in the 'Importance' line above!
Comment 2 Mark Raynsford 2013-02-07 19:14:46 CET
This has my vote.
Comment 3 Xerxes Rånby 2013-03-07 12:14:03 CET
This has my vote.
Comment 4 Julien Gouesse 2014-10-21 10:36:27 CEST
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
Comment 5 Sven Gothel 2014-10-21 10:43:58 CEST
As Julien suggested moved to version 3, iff we accept this task.
Comment 6 Sven Gothel 2014-10-21 10:46:59 CEST
(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.
Comment 7 Julien Gouesse 2014-10-21 16:16:58 CEST
Maybe the version 2.4 or 2.3.1 is more suitable for the second step.
Comment 8 Harvey Harrison 2014-10-21 19:41:24 CEST
No opinion on what version ths should be called (I'd mildly prefer 3.x) but I'm supportive of the change in namespace.
Comment 9 Julien Gouesse 2014-10-25 15:42:41 CEST
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.
Comment 10 Wade Walker 2014-10-25 17:16:31 CEST
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.
Comment 11 Julien Gouesse 2014-10-25 17:23:52 CEST
(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?
Comment 12 Wade Walker 2014-10-25 17:42:59 CEST
> 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 :)
Comment 13 Julien Gouesse 2014-10-25 18:06:19 CEST
Actually, I meant we could keep jogamp.* and move things from com.jogamp.* and java.media.* to org.jogamp.*.
Comment 14 Julien Gouesse 2014-10-29 11:56:36 CET
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
Comment 15 Julien Gouesse 2014-11-05 14:06:57 CET
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.
Comment 16 Julien Gouesse 2014-11-05 14:19:06 CET
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
Comment 17 Mark Raynsford 2015-01-27 17:49:19 CET
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
Comment 18 Sven Gothel 2015-02-02 02:54:00 CET
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.
Comment 19 Sven Gothel 2015-02-09 11:58:48 CET
All changes validated w/ latest aggregated autobuild

http://jogamp.org/deployment/archive/master/gluegen_844-joal_575-jogl_1371-jocl_1032-signed/
Comment 20 Xerxes Rånby 2015-11-26 12:25:08 CET
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/**