Thread: [gl4java-usergroup] Is GL4Java dead ?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi  all,

no new release... since a big time

Is GL4Java dead or frozen ?

Best regards
-- 
R.Pac

no, i think its stable...
Jens

----- Original Message ----- 
From: "Pac" <pa...@tu...>
To: <gl4...@li...>
Sent: Saturday, April 26, 2003 10:58 AM
Subject: [gl4java-usergroup] Is GL4Java dead ?

> Hi  all,
> 
> 
> no new release... since a big time
> 
> Is GL4Java dead or frozen ?
> 
> 
> Best regards
> -- 
> R.Pac
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup

From what I know, gl4java maps the complete OpenGL 1.4 API and is very
stable. Everytime I thought I had found a bug, I ended figuring out I was
wrong and the gl4java API was good. So actually, we can say gl4java is quit=
e
up to date.

But we have all noticed Sven was much less present on the mailing list for
the past few monthes, and he is not here to answer our concern that the
gl4java API might not evolve anymore towards OpenGL 2.0. Sven certainly has
his own personal reasons for being less present, and he has done so much
great work on gl4java during 7 years none of us would dare to judge his lac=
k
of presence.

Since I have spent nine monthes of full time programming on the OpenMind
engine using gl4java, and since OpenMind is the technology I intend to use
for the future game developments of my company, I personnaly feel very
concerned about how the future of the API. But maintaining the OpenMind ope=
n
source project already eats an impressive amount of time on my schedule and
I know I wouldn't be able to help maintain gl4java as well, though I'd be
interested to.

I think it'd be good that someone who has skills in java, c++ an JNI would
be promoted as a secondary project admin aside with Sven, and could bring a
new life to the gl4java API and help animate the community.

There are a few issues that I think should be adressed on gl4java actually =
:

- Set up a compilation script that can easily be run on a cross platform
basis. As some of you may have noticed from the numerous messages on the
mailing list, the make script of gl4java is not easily portable, and many
people have hard time compiling gl4java on Windows and MacOSX. On OpenMind,
one of our open source developers -Robert Cadenas- has setup a compilation
script for apache ANT. ANT is a "make like" tool coded in java and targeted
to cross platform compilation. Compiling OpenMind has never been so easy an=
d
it works perfectly on Windows, MacOSX and Linux. Creating such an ANT scrip=
t
for gl4java would make it more accessible to new open source developers.

- Ensure CG compatibility and provide some demo featuring vertex and
fragment shader code

- I would personnaly get rid of Java 1.1, 1.2 and MS JVM compatibility in
order to simplify the code, the compilation process, and drive people to us=
e
java 1.4

- Eventually make a lifting to the web site, and animate the community.

I am personnaly commited to use gl4java with the OpenMind scene graph, and
I'd sincerely like to continue working with it. If I succeed selling my
video game project using OpenMind I could eventually have some employee hel=
p
developping the gl4java API, but if I don't have this chance and the API
should die slowly, I may have no other choice than moving the scene graph o=
n
some other binding that gets a more dynamic support.

I wish someone would have the time and the interest to bring gl4java back t=
o
a more dynamic development.

Regards,

Alban Cousini=E9
  =20

Le 27/04/03 11:12, =AB=A0Jens G=FCnther=A0=BB <jen...@ag...> a =E9crit=A0:

> no, i think its stable...
> Jens
>=20
> ----- Original Message -----
> From: "Pac" <pa...@tu...>
> To: <gl4...@li...>
> Sent: Saturday, April 26, 2003 10:58 AM
> Subject: [gl4java-usergroup] Is GL4Java dead ?
>=20
>=20
>> Hi  all,
>>=20
>>=20
>> no new release... since a big time
>>=20
>> Is GL4Java dead or frozen ?
>>=20
>>=20
>> Best regards
>> --=20
>> R.Pac
>>=20
>>=20
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> gl4java-usergroup mailing list
>> gl4...@li...
>> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup

Just a small correction, gl4java maps openGL 1.3 (at least the cvs=20
version does). So no vertex/fragment programs yet :)

I've been hacking away at the gl4java source code lately. I reworked=20
the make script to be a bit more readable. My version works fine on=20
linux, windows(using cl/link instead of gcc/ld) and solaris. No mac os=20=

x yet. Gerard Ziemski's port uses pbxbuild to build the everything and=20=

I would prefer to use gcc directly, but I haven't figured out how to do=20=

that yet. You said that a colleague had made an ant build script. Is it=20=

practical to use ant to compile c code?

After reworking the makefile I started playing with the GLCanvas class.=20=

While hacking away at the code I ended up removing 2/3 of the source=20
code. Strangely enough everything still works fine :). I do have to=20
admit that I did strip out some functionality (the ancient jvm support=20=

(like netscape and ms builtin ones), offscreen rendering, etc). I'm=20
doing this effort to better understand how the rendering from native=20
code is done. Personally I would just rely on JAWT to do this, but Max=20=

Gilead already mentioned that support for open jvms is important to him=20=

(kaffe, sablevm, ...) and these don't support JAWT yet.
Anyway, in short I'm working on understanding the code, but I'm not=20
sure in which direction further development should be headed. Any ideas=20=

are welcome. Also I don't have access to the gl4java sourceforge=20
project, so if I would want to make my version available I would have=20
to make a separate project.
Next to that I've been busy making an OpenAL binding. A first version=20
is almost complete. If anyone is interested in testing this I would be=20=

more than happy to make it available online (on sourceforge I guess).

Pepijn Van Eeckhoudt

On zondag, apr 27, 2003, at 13:15 Europe/Brussels, Alban Cousini=E9 =
wrote:

>> =46rom what I know, gl4java maps the complete OpenGL 1.4 API and is =
very
> stable. Everytime I thought I had found a bug, I ended figuring out I=20=

> was
> wrong and the gl4java API was good. So actually, we can say gl4java is=20=

> quite
> up to date.
>
> But we have all noticed Sven was much less present on the mailing list=20=

> for
> the past few monthes, and he is not here to answer our concern that =
the
> gl4java API might not evolve anymore towards OpenGL 2.0. Sven=20
> certainly has
> his own personal reasons for being less present, and he has done so=20
> much
> great work on gl4java during 7 years none of us would dare to judge=20
> his lack
> of presence.
>
> Since I have spent nine monthes of full time programming on the=20
> OpenMind
> engine using gl4java, and since OpenMind is the technology I intend to=20=

> use
> for the future game developments of my company, I personnaly feel very
> concerned about how the future of the API. But maintaining the=20
> OpenMind open
> source project already eats an impressive amount of time on my=20
> schedule and
> I know I wouldn't be able to help maintain gl4java as well, though I'd=20=

> be
> interested to.
>
> I think it'd be good that someone who has skills in java, c++ an JNI=20=

> would
> be promoted as a secondary project admin aside with Sven, and could=20
> bring a
> new life to the gl4java API and help animate the community.
>
> There are a few issues that I think should be adressed on gl4java=20
> actually :
>
> - Set up a compilation script that can easily be run on a cross=20
> platform
> basis. As some of you may have noticed from the numerous messages on=20=

> the
> mailing list, the make script of gl4java is not easily portable, and=20=

> many
> people have hard time compiling gl4java on Windows and MacOSX. On=20
> OpenMind,
> one of our open source developers -Robert Cadenas- has setup a=20
> compilation
> script for apache ANT. ANT is a "make like" tool coded in java and=20
> targeted
> to cross platform compilation. Compiling OpenMind has never been so=20
> easy and
> it works perfectly on Windows, MacOSX and Linux. Creating such an ANT=20=

> script
> for gl4java would make it more accessible to new open source=20
> developers.
>
> - Ensure CG compatibility and provide some demo featuring vertex and
> fragment shader code
>
> - I would personnaly get rid of Java 1.1, 1.2 and MS JVM compatibility=20=

> in
> order to simplify the code, the compilation process, and drive people=20=

> to use
> java 1.4
>
> - Eventually make a lifting to the web site, and animate the =
community.
>
> I am personnaly commited to use gl4java with the OpenMind scene graph,=20=

> and
> I'd sincerely like to continue working with it. If I succeed selling =
my
> video game project using OpenMind I could eventually have some=20
> employee help
> developping the gl4java API, but if I don't have this chance and the=20=

> API
> should die slowly, I may have no other choice than moving the scene=20
> graph on
> some other binding that gets a more dynamic support.
>
> I wish someone would have the time and the interest to bring gl4java=20=

> back to
> a more dynamic development.
>
> Regards,
>
> Alban Cousini=E9
>
>
> Le 27/04/03 11:12, =AB=A0Jens G=FCnther=A0=BB =
<jen...@ag...> a=20
> =E9crit=A0:
>
>> no, i think its stable...
>> Jens
>>
>> ----- Original Message -----
>> From: "Pac" <pa...@tu...>
>> To: <gl4...@li...>
>> Sent: Saturday, April 26, 2003 10:58 AM
>> Subject: [gl4java-usergroup] Is GL4Java dead ?
>>
>>
>>> Hi  all,
>>>
>>>
>>> no new release... since a big time
>>>
>>> Is GL4Java dead or frozen ?
>>>
>>>
>>> Best regards
>>> --=20
>>> R.Pac
>>>
>>>
>>> -------------------------------------------------------
>>> This sf.net email is sponsored by:ThinkGeek
>>> Welcome to geek heaven.
>>> http://thinkgeek.com/sf
>>> _______________________________________________
>>> gl4java-usergroup mailing list
>>> gl4...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> gl4java-usergroup mailing list
>> gl4...@li...
>> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
>

Hi Pepijn :)

> Just a small correction, gl4java maps openGL 1.3 (at least the cvs
> version does). So no vertex/fragment programs yet :)
Well we'd need 1.4 support for sure.
About gl4java updates, I personally have access to the gl4java sourcefore
CVS so I may update some code for you. But I guess Sven could register you
as a gl4java developer if you ask him.

I'd be very interested to integrate an OpenAL binding into OpenMind if it i=
s
LGPL. I'd like to review yours if you are ok.

Regards,

Alban

Le 27/04/03 14:50, =AB=A0Pepijn Van Eeckhoudt=A0=BB <pep...@lu...=
>
a =E9crit=A0:

> Just a small correction, gl4java maps openGL 1.3 (at least the cvs
> version does). So no vertex/fragment programs yet :)
>=20
> I've been hacking away at the gl4java source code lately. I reworked
> the make script to be a bit more readable. My version works fine on
> linux, windows(using cl/link instead of gcc/ld) and solaris. No mac os
> x yet. Gerard Ziemski's port uses pbxbuild to build the everything and
> I would prefer to use gcc directly, but I haven't figured out how to do
> that yet. You said that a colleague had made an ant build script. Is it
> practical to use ant to compile c code?
>=20
> After reworking the makefile I started playing with the GLCanvas class.
> While hacking away at the code I ended up removing 2/3 of the source
> code. Strangely enough everything still works fine :). I do have to
> admit that I did strip out some functionality (the ancient jvm support
> (like netscape and ms builtin ones), offscreen rendering, etc). I'm
> doing this effort to better understand how the rendering from native
> code is done. Personally I would just rely on JAWT to do this, but Max
> Gilead already mentioned that support for open jvms is important to him
> (kaffe, sablevm, ...) and these don't support JAWT yet.
> Anyway, in short I'm working on understanding the code, but I'm not
> sure in which direction further development should be headed. Any ideas
> are welcome. Also I don't have access to the gl4java sourceforge
> project, so if I would want to make my version available I would have
> to make a separate project.
> Next to that I've been busy making an OpenAL binding. A first version
> is almost complete. If anyone is interested in testing this I would be
> more than happy to make it available online (on sourceforge I guess).
>=20
> Pepijn Van Eeckhoudt
>

Alban Cousinié wrote:
> Hi Pepijn :)
> 
> 
>>Just a small correction, gl4java maps openGL 1.3 (at least the cvs
>>version does). So no vertex/fragment programs yet :)
> 
> Well we'd need 1.4 support for sure.
> About gl4java updates, I personally have access to the gl4java sourcefore
> CVS so I may update some code for you. But I guess Sven could register you
> as a gl4java developer if you ask him.
> 
> I'd be very interested to integrate an OpenAL binding into OpenMind if it is
> LGPL. I'd like to review yours if you are ok.
> 

Great, I'll send you a version as soon as I get it up and running. If 
you wish to integrate it into your engine LGPL is fine for me.

Pepijn

> Regards,
> 
> Alban
> 
> 
> Le 27/04/03 14:50, « Pepijn Van Eeckhoudt » <pep...@lu...>
> a écrit :
> 
> 
>>Just a small correction, gl4java maps openGL 1.3 (at least the cvs
>>version does). So no vertex/fragment programs yet :)
>>
>>I've been hacking away at the gl4java source code lately. I reworked
>>the make script to be a bit more readable. My version works fine on
>>linux, windows(using cl/link instead of gcc/ld) and solaris. No mac os
>>x yet. Gerard Ziemski's port uses pbxbuild to build the everything and
>>I would prefer to use gcc directly, but I haven't figured out how to do
>>that yet. You said that a colleague had made an ant build script. Is it
>>practical to use ant to compile c code?
>>
>>After reworking the makefile I started playing with the GLCanvas class.
>>While hacking away at the code I ended up removing 2/3 of the source
>>code. Strangely enough everything still works fine :). I do have to
>>admit that I did strip out some functionality (the ancient jvm support
>>(like netscape and ms builtin ones), offscreen rendering, etc). I'm
>>doing this effort to better understand how the rendering from native
>>code is done. Personally I would just rely on JAWT to do this, but Max
>>Gilead already mentioned that support for open jvms is important to him
>>(kaffe, sablevm, ...) and these don't support JAWT yet.
>>Anyway, in short I'm working on understanding the code, but I'm not
>>sure in which direction further development should be headed. Any ideas
>>are welcome. Also I don't have access to the gl4java sourceforge
>>project, so if I would want to make my version available I would have
>>to make a separate project.
>>Next to that I've been busy making an OpenAL binding. A first version
>>is almost complete. If anyone is interested in testing this I would be
>>more than happy to make it available online (on sourceforge I guess).
>>
>>Pepijn Van Eeckhoudt
>>
> 
> 

Guys,

For my part, I have noticed that GL4Java has some bugs
in it that it seems should be addressed going forward.  So
I am trying to work through those on my own.  One of the
biggest is the fact that multiple canvases cannot be displayed
and removed from a container ad infinitum on the Windows
platform.  Another problem is of course the lack of Shader
support.  I have not heard of anyone yet solving these
problems, and they even exist in the latest sourceforge
cvs version.  The shader problem is trivial to fix so I will not
make sport with your intelligence by addressing that here.
However, the multiple canvas problem appears to me to
be non trivial.  Perhaps this is not the case and someone else
has already fixed it, if so please forward a clue.

The point I am making is that Sven has given us a gift of a
GREAT DEAL of source code.  Are there bugs in it? Yes.
Does it need to be updated going forward? Yes.  But in the
final analysis you're getting something for nothing more than
a little elbow grease.  If we all team together and move in a
coordinated fashion perhaps many of you would not have
these concerns.  Check out the source code.  Build it.
Despite what people say, it is not THAT difficult, and that's
coming from a guy with a linux desktop, a Dell Win2000
laptop, and a TiBook.  OpenGL 2 WILL BE available in
GL4Java if I have to do it myself, but I would appreciate help.
Shaders are trivial to implement, if you look at the code you
will see exactly how to do it.  Add the necessary functionality
to the OpenGL_JauJNI14_funcs.c file and the GLFunc*.java
files and rebuild.  It IS NOT dead, as long as you are willing
to do what it takes to use it.

                                                         -TOBY

> Guys,
> 
> For my part, I have noticed that GL4Java has some bugs
> in it that it seems should be addressed going forward.  So
> I am trying to work through those on my own.  One of the
> biggest is the fact that multiple canvases cannot be displayed
> and removed from a container ad infinitum on the Windows
> platform.  

What is the exact problem there? Personally I've had problems with the 
component being disposed too early and then not reiniting itself. I 
searched through the awt documentation and gl4java source code and came 
up with the following:
- The GLCanvas is inited(first paint iirc) and released in a variety of 
places. It is for example released in response to windowClosing events. 
- AWT components init and release their peer inside the addNotify and 
removeNotify respectively.
I've modified the GLCanvas to behave in the second way. This seems to 
work just fine for me. The only real issue I could come up with is that 
you will lose your context if you remove the GLCanvas from the AWT 
component tree. If you then add it again later, a new context will be 
created and all you're display lists, textures, ... will have 
disappeared. Do you think this is an issue, or should the GLCanvas 
generate some kind of contextLost event allowing applications to handle 
this gracefully?

> The point I am making is that Sven has given us a gift of a
> GREAT DEAL of source code.  Are there bugs in it? Yes.
> Does it need to be updated going forward? Yes.  But in the
> final analysis you're getting something for nothing more than
> a little elbow grease.  If we all team together and move in a
> coordinated fashion perhaps many of you would not have
> these concerns.  Check out the source code.  Build it.
> Despite what people say, it is not THAT difficult, and that's
> coming from a guy with a linux desktop, a Dell Win2000
> laptop, and a TiBook.  

I didn't mean to say the code itself was difficult, only the way in 
which it is built. (Although I have to admit I find certain bits of the 
java code very strange. Maybe a study group would be a good idea ;) )

> OpenGL 2 WILL BE available in
> GL4Java if I have to do it myself, but I would appreciate help.
> Shaders are trivial to implement, if you look at the code you
> will see exactly how to do it.  Add the necessary functionality
> to the OpenGL_JauJNI14_funcs.c file and the GLFunc*.java
> files and rebuild.  It IS NOT dead, as long as you are willing
> to do what it takes to use it.

In the current state it's not that straightforward. Well actually it is 
but there are some complications. The OpenGL_*_funcs.c file is largely 
autogenerated, so you have to add the new code that you program by hand 
to the files in the C2J/manual(iirc) directory. To me this is what 
initially caused the most confusion, because everything (generated bits, 
manual bits and concatenated files) is all checked in to the cvs 
repository. This is the reason why I cleaned up (imho) the build process.
I've been wondering if it's worth it to keep this autogenerating stuff. 
The C2J parser is great to generate the inital version of the file, but 
is it worth it to have it in the cvs with the rest of the code and 
actually invoke it in the makefile?

Pepijn

>> OpenGL 2 WILL BE available in
>> GL4Java if I have to do it myself, but I would appreciate help.
>> Shaders are trivial to implement, if you look at the code you
>> will see exactly how to do it.  Add the necessary functionality
>> to the OpenGL_JauJNI14_funcs.c file and the GLFunc*.java
>> files and rebuild.  It IS NOT dead, as long as you are willing
>> to do what it takes to use it.

>In the current state it's not that straightforward. Well actually it is

>but there are some complications. The OpenGL_*_funcs.c file is largely 
>autogenerated, so you have to add the new code that you program by hand

>to the files in the C2J/manual(iirc) directory. To me this is what 
>initially caused the most confusion, because everything (generated
bits, 
>manual bits and concatenated files) is all checked in to the cvs 
>repository. This is the reason why I cleaned up (imho) the build
process.
>I've been wondering if it's worth it to keep this autogenerating stuff.

>The C2J parser is great to generate the inital version of the file, but

>is it worth it to have it in the cvs with the rest of the code and 
>actually invoke it in the makefile?

Gerard Ziemsky (who has ported gl4java to MacOSX for those who don't
know) told me lately : 
" i have pretty much given up on gl4java and have no intentions of
supporting it any further. gl4java grew too complex and too hard to
support. however, there is an ongoing work on a new gl binding for java.
i'll be porting that one to MacOS X. the new binding will work with
Swing. i can't say when it will be ready or anything more about it since
it is not my project"
After asking him, this new binding is not LWJGL, but a third OpenGL
binding.

I guess we are seeing the emergence of these 2 competing OpenGL bindings
because people are no longer satisfied/confident with the gl4java
project, otherwise I guess they wouldn't bother wasting their time
working on a new binding.

As Gerard Ziemsky said, gl4java has grown too complex. I think we should
learn the lessons of what's going on and improve gl4java so people feel
satisfied and confident with it and programmers don't get scared by the
complexity of the build process.

Since some people are being interested by keeping the compatibility with
older Java VMs, I suggest we could start a new module on the official
gl4java sourceforge CVS that we may call "gl4java2", without modifying
the regular gl4java module. People in need with prior JDK compatibility
would stick to the current stable release. People in need for the latest
OpenGL features and better performance would go for the gl4java2
version.

This new module would have the following features :

	- true "plug and play" cross platform compilation script (ANT
based)
	- clean build process (remove the complicate C2J generation)
	- code lighter and easier to maintain (remove code compatibility
for VMs prior to 1.4, and ensure compatibility with Java 1.4 and future
releases) 
 	- support for OpenGL 1.4 with shaders and, when appropriate,
OpenGL 2.0.

Though I barely have any free time, I could handle the ANT compilation
script. But I need some of you to provide me a "C2J free" version of
gl4java.

Alban.

<snip>

>I guess we are seeing the emergence of these 2 competing OpenGL bindings
>because people are no longer satisfied/confident with the gl4java
>project, otherwise I guess they wouldn't bother wasting their time
>working on a new binding.
>
>As Gerard Ziemsky said, gl4java has grown too complex. I think we should
>learn the lessons of what's going on and improve gl4java so people feel
>satisfied and confident with it and programmers don't get scared by the
>complexity of the build process.
>
>Since some people are being interested by keeping the compatibility with
>older Java VMs, I suggest we could start a new module on the official
>gl4java sourceforge CVS that we may call "gl4java2", without modifying
>the regular gl4java module. People in need with prior JDK compatibility
>would stick to the current stable release. People in need for the latest
>OpenGL features and better performance would go for the gl4java2
>version.
>
>This new module would have the following features :
>
>	- true "plug and play" cross platform compilation script (ANT
>based)
>	- clean build process (remove the complicate C2J generation)
>	- code lighter and easier to maintain (remove code compatibility
>for VMs prior to 1.4, and ensure compatibility with Java 1.4 and future
>releases) 
> 	- support for OpenGL 1.4 with shaders and, when appropriate,
>OpenGL 2.0.
>
>Though I barely have any free time, I could handle the ANT compilation
>script. But I need some of you to provide me a "C2J free" version of
>gl4java.
>
>Alban.
>
>  
>
I think that setting up a fork and separate project is the only way 
forward.  Sven seems to be AWOL.  I've tried to contact him about 
getting developer status on the SF project and there's no response.

gl4java is in need of work (esp. the documentation), but it can't be 
done under the current regime where no one can commit anything to the 
repository.

I'd be keen on helping out with any new work (I know java, ant, openGL 
all pretty well).  I might be able to do the work to create a java 
version of c2j - that could be made an ant task, I suppose?

Anybody else interested in helping move the codebase forward?  I'd 
particularly like someone who has experience with gl4java to document 
the code more fully and clearly.

Cheers,

Peter.

It seems like there are a bunch of motivated people willing to put some 
effort into this project... So how do we get started? I.e. who's going 
to set up the sourceforge project :)
After that is done I guess we should do some kind of mini conference 
thing (irc, some instant messenger, ...) to define what we're actually 
going to modify/implement/..., from what codebase we should start, etc.

Pepijn

GL4Java is NOT Dead!!!

All we need is a standard way to cooperate, making things easier for the
final users, writing docs, and finally implementing new opengl specs.

The better way I see to perform such a task (or so many tasks) is to set-up
a web-centric community (maybe source forge site itself) in wich everyone
find a proper task to accomplish depending on each one skills.

First, Obviously, we need to catalogue the skills of everyone who wish to
cooperate...

I would focus my efforts into writing (in my poor english)& translating user
manuals & tuts into my own spoken language: Italian.

Long life to GL4Java.