Future of JSR 231

I’m currently debating whether or not to upgrade my code to JSR 231. The big factor against switching for me is the lack of a webstart jnlp on jogl.dev.java.net for it.

How soon will webstart support for the JSR 231 be provided?
When is the expected release date for JSR 231?
Will it be integrated into Mustang?

[Edit]

Also, where can I find the nightly builds? I’ve read several threads that speak of them, but the latest I can find JSR-231 beta 05 - June 8.

Webstart support is already here and has been available for roughly a year. Please check the JOGL User’s Guide for the current extension JNLP URL. It’s on download.java.net rather than jogl.dev.java.net due to reliability problems with files hosted off jogl.dev.java.net.

The expected release date for JSR-231 is within two months. We are basically just waiting for some signatures and then need to produce the final source and build bundles. We are continuing to fix bugs and investigate issues. JSR-231 will not be included in Mustang. The nightly builds are linked off the JOGL home page under the section “Current nightly build”. We don’t archive the nightly builds so only the most recent one is available.

Hello,

Perhaps a stupid question but…
Will JSR-231 be included in any future release of the JVM?

Best Regards
Jonas Forssell

this would be a very bad idea, since OpenGL 3.0 would break the backwack compatibility

Maybe another stupid question, but why would it break backward compatibility? As far as I know the OpenGL APIs have always been backward compatible, haven’t they?

There was a GDC 2006 Session, partly covered in this GameDev.Net Article

Even in the OpenGL 2.1 part you will find the following:

[quote]The update will also include some minor changes, some of which will be backward incompatable:

  • Names will be more C++ like. A name will hide names of all types (functions, variables, structures). You’ll also be able to declare names within a scope, with the exceptions that local function declarations are not allowed, and you cannot redeclare within a scope. The built-in functions are considered to be in a sort of “outermost” scope. If you redeclare them, you’ll hide all functions using that name (e.g. redeclaring texture2D will hide all texture2D functions, regardless of the signature).

  • Function signature matching will change such that the compiler will first try to find an exact match, then it’ll try limited implicit contructors (i.e. int gets promoted to float, ivec3 to vec3, etc.). Multiple implicit matches will result in an error.

  • Arrays are now first class citizens. You’ll be able to use equality, inequality, and assignment operators as long as they are explicitly sized, as well as use array constructors.

  • Non-square matrices will be permitted, and new outerProduct() and transpose() functions and constructors will be added to support them.
    [/quote]

Ok, thanks for the info :slight_smile:

Look at the article again. The changes you quoted are related to GLSL, not the OpenGL API itself. They aren’t breaking backwards compatibility in the OpenGL API.

oops, I just quoted the first part containing incompatible. Some time ago reading he article in depth…
Please read a bit further, you will find some other issues in the OpenGL 3.0 part under ‘Changing the Object Model’. The main difference will be that ‘names’ probably won’t be integegers anymore, but pointers for a faster access…

Of course nothing is 100% decided yet, but it is very likely that 3.0 won’t be backward compatible…