E.g. com.sun.opengl.util.texture
The general rule from Sun has always been “Don’t use stuff you find in com.sun.* because it’s stuff that could go away or change at any time. If your code breaks next week because you relied on something in com.sun.* it’s not our fault.”
Wouldn’t it make more sense, if you intend for people to use these classes, to put them in a different package, e.g. net.java.jogl.* or some such thing?
I agree. why shouldn’t it be in javax.media.opengl.util?
suggesting…
javax.media.opengl.util.Texture
javax.media.opengl.util.Glut
javax.media.opengl.util.Animator
…etc, for tried and tested utils
code will break if another rename occurs anyway.
hmm…haven’t this issue been discussed?
The javax namespace is tightly controlled. Since these libraries are experimental and still evolving we placed them in the com.sun.* namespace which is not covered by the same restrictions.
When discussing core classes in the JRE/JDK, it is correct that you should not rely on classes in packages such as com.sun.* which are not in the API specification. However, in this case we are providing these libraries as a convenience, not as a guarantee of their presence, so you can feel free to just use them as they stand.
[quote=“Ken Russell,post:3,topic:27070”]
I personally have doubts that this will be a good move in the long run. It blurs the line that was once clear. Now we are encouraged to use some of the com.sun.* stuff but not other classes in the same package.
How should we interpret “[you] are providing these libraries as a convenience, not as a guarantee of their presence” ? Isn’t that essentially what all the com.sun.* classes are? Stuff that isn’t guaranteed to be there. If they aren’t guaranteed to be there, why should we rely on them this time?
Maybe I’m just being paranoid… but seeing “import com.sun…” in my code makes my skin crawl 
I agree that the utility packages should be placed under com.sun.opengl since they are experimental…
However I guess I understand the problem. If some other vendor develops a jsr compliant implementation, the com.sun classes are likely to be not included.
Why not make a seperate jar file for the com.sun classes? IIRC this is the way java3d ships. Further, the license should allow to bundle the utitlity jar file with other implementations of jogl (maybe it does already)…
[quote=“zero,post:5,topic:27070”]
Just to be clear. I realize that they are experimental and understand that they should be kept out of the code javax.* package. I’m only suggesting that com.sun.* implies an internal Sun implementation class that I should not touch and perhaps an alternate package related to the project on Java.net would be more appropriate at this stage. (e.g. net.java.dev.jogl.util.* or similar)
It’s not a big deal, I was just bringing it up now while there is an opportunity to discuss it and do something should there be a decision to make changes at all.
Basically I don’t think the rules about the com.sun.* namespace are as clear-cut as you describe. Certainly classes in the sun.* hierarchy are off-limits. The com.sun.* classes that ship with the core JDK are not guaranteed to be present on all platforms so their use is discouraged. However, external libraries may place their classes anywhere, and classes produced by Sun would logically go in the com.sun.* namespace. Java3D ships its utility classes in the com.sun.j3d namespace.
For technical reasons (the Gamma class relies on native code support in core JOGL) we don’t plan to decouple the JOGL utility classes from the core implementation, though because everything is BSD licensed anyone is welcome to do so and redistribute them that way.
Ah… nevermind then… I just had a misunderstanding about sun.* vs. com.sun.*