Bug 7 - Remove prefixes from jogl
Summary: Remove prefixes from jogl
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 1
Hardware: All all
: P3 normal
Assignee: Sven Gothel
Depends on:
Reported: 2003-06-15 10:53 CEST by Sven Gothel
Modified: 2015-09-27 03:14 CEST (History)
0 users

See Also:
SCM Refs:
Workaround: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2010-03-24 07:45:17 CET

---- Reported by athomas 2003-06-15 10:53:28 ----

There has been a discussion on the 3D Programming Forum regarding the gl
prefixes in jogl (and presumably the al prefixes in JOAL)
The discussion has evolved along the lines of the static vs. singleton question
and the implications with regard to static imports in jdk1.5.

It would appear that in the long run 


would be preferable to 

GL gl = new GL();

because with static imports coming in 1.5 




making the code more closely resemble the original C api.

My understanding is that the use singletons is to allow for multiple contexts
(ie TraceGL, DebugGL, etc) however this can just as easily be accomplished by
creating a static facade to an underlying GL implementation like so:

class DebugGLProvider implements GLProvider {
    //... bunch o' methods

final class GL {
   private static GLProvider glp;
   public static void glInit() {
        // Exceptions and error-handling omitted for clarity
        String providerClass = System.getProperty("jogl.provider");
        glp = (GLProvider)Class.newInstance(providerClass);
    public static void glInit(String providerClass) {
        // Exceptions and error-handling omitted for clarity
        glp = (GLProvider)Class.newInstance(providerClass);
    public static void glEnable(int capability) {

which would then be used as follows:

class MyClass {
    public void myMethod() {

which in 1.5 beomes

class MyClass {
    public void myMethod() {

This should give a 1.5 syntax almost identical to the C syntax without
sacrificing the ability to do multiple pipeline implementations. There shouldn't
be a  performance hit for the additional level of indirection as it gets
optimized away by the compiler.

Is there something else we need to consider here? There seems to be some
interest from the group in going this route, but we'd need to move soon to
implement this, or at present our reasons for not going this way.

---- Additional Comments From djp 2003-07-10 13:09:42 ----

This issue has not been decided on by the community.  Once formal guidelines are
posted on how decisions are made this topic can be brought up.  If the comuunity
feels this is the right choice a new issue will be created.

--- Bug imported by sgothel@jausoft.com 2010-03-24 07:45 EDT  ---

This bug was previously known as _bug_ 7 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=7

The original assignee of this bug does not have
   an account here. Reassigning to the default assignee
   for the component, sgothel@jausoft.com.
   Previous assignee was djp.
CC member yensid does not have an account here