Ease backwards compatibility with JOGL 1.x apps

I would like to request that JOGL 1.1.1 code would simply work with JOGL 2.x jars without modification (or at least with minimal changes).

I can see how you want the compiler to flag code that doesnt match a particular profile, but there should be a better transparent process without refactoring an entire code base, especially since I dont have privileges to modify someone else's code. For example, NASA World Wind, which posts source code as a zip file on a daily basis, and does not have a public source control repository. These changes would greatly ease transitioning/experimenting with JOGL 2 on an existing JOGL 1 app.

JOGL 2 should choose JOGL 1 options as defaults unless they are specified otherwise. Specifically:

* Default profile is GL2 desktop. When calling no-args constructor for GLJPanel(), it calls GLCapabilities() with GL2 Profile.

* GL interface should be synonymous with GL2. If you need something to a differentiate, add a GL1 interface or something similar.

* GLAutoDrawable.getGL() returns a GL2 equivalent so JOGL 1 code just works.

* All constants that were exposed in JOGL 1 GL interface are still available in JOGL 2 GL interface. This avoids searching for GL.GL_ and replacing with GL2.GL_

Hi,

I understand the need of easing backward compatibility with JOGL 1 apps in order to make experimenting or benchmarking more straightforward.

But I completely disagree with the proposal that states that the default of JOGL 2 should be to mimic JOGL 1:
- using GL2 as a default profile for GLCapabilities would satisfy the backward compatibility issue but would not be acceptable in the long run.
- using GL as an alias for GL2 would not help to make the API clearer. Anyway, I guess that this API is governed by the JSR-231 and that Jogl's designers do not have the direct capability to change it.
- JOGL 2 is designed to be open to the future of OpenGL. Jailing it in legacy specifications does not comply with this goal.

Another way to achieve the straightforward compatibility without polluting JOGL 2 forever could be to implement a compatibility (and therefore optional) package in a separate JAR that would provide classes and interfaces that would make JOGL2 look like JOGL 1. For instance a GL interface in this package could inherit GL2. This is an idea but I guess that implementing this would be quite bothersome and time consuming. In my opinion, JOGL 2 is today much more lacking stability than this backward functionality.

I just wanted to give a counterpoint.

Thanks,
Cyrille