The JDK 1.5’s enum doc tells some nice old truths like: typesafe, namespace, etc.
I see many occasions JOGL could use this.
For example it would hinder the developer to give the wrong const int parameter to many methods which need some int constants (enums). Compile error instead of runtime errors.
Will JOGL support this in the near future?
I think it would be murder for JOGL to use enum, because it’s not supported by all JREs out there. Many people are still developing for 1.3.
/Mikael
JOGL is autogenerated, so it would not be a problem to have separate version for 1.5. If you use other 1.5 functionality, having 1.5-specific version of JOGL does no harm.
I was thinking about it some time ago and done some checks - but as far as I remember, it is quite hard to do. Most of opengl calls have very broad parameter lists - and many, many constants would have to be duplicated in multiple enums. Aditionally, all possible extensions for given function would have to be put inside same enum.
One of benefits in addition to type safety would be better logging - currently, enums have to be logged as numbers in trace file, because multiple things have same number. With enum objects, trace could just print out enum name.
[quote]I think it would be murder for JOGL to use enum, because it’s not supported by all JREs out there. Many people are still developing for 1.3.
/Mikael
[/quote]
Ignore them. They can use Java3d for other type of applications besides games. JOGL is for making games and game programming requires constant updates to use the latest features.
We eventually ditched this idea in LWJGL for two good reasons:
Enums are objects. Pass them into native code and you have to deference them and call a method on them to get some value out. What a pain in the arse.
Many OpenGL extensions, when present, effectively change the set of allowed values to functions, thereby rendering the concept of compile time checking totally irrelevant.
None of the OpenGL constants are redefined anywhere by the way. AFAIK, all values are unique in name but overlap in usage.
So in short - don’t try this, because it won’t work.
Cas 
I don’t know about that. I think they should not limit themselves only with enumerations but also use generics and the new loop facility. EnumSets and EnumMaps work very fast.
Why would they need to call a method to get the value ? Enumerated values are objects so they only need to compare references instead of ints.
Think Java. You can extend Java enumerations i think.
Again thats a C problem.
It’s not a problem, it’s just the way it is, and the way it’s designed. OpenGL is a C API, and if you try to make it Java-ified it won’t go. I’d love typesafe enum args but the plain fact is that you don’t know what values are allowed in any functions until you know what extensions are available in a particular context, which you can’t know until runtime.
The usage overlap is an advantage rather than a disadvantage. It means that given a particular int value you can always decode it to the same human-readable value.
[quote]Why would they need to call a method to get the value ? Enumerated values are objects so they only need to compare references instead of ints.
[/quote]
At some point you have to pass an int to the C APIs.
Cas
[quote] Ignore them. They can use Java3d for other type of applications besides games. JOGL is for making games and game programming requires constant updates to use the latest features.
[/quote]
What an arrogant attitude to take. Do that and watch your target audience for potential developers vanish in the blink of an eye. All those thousands of developers currently developing using J2ME for phones will go, all the developers doing servers for games will go. All of us doing multiplatform software will go. There’ll be you and two others using JOGL and it will die a very quick death.
[quote]It’s not a problem, it’s just the way it is, and the way it’s designed. OpenGL is a C API, and if you try to make it Java-ified it won’t go. I’d love typesafe enum args but the plain fact is that you don’t know what values are allowed in any functions until you know what extensions are available in a particular context, which you can’t know until runtime.
The usage overlap is an advantage rather than a disadvantage. It means that given a particular int value you can always decode it to the same human-readable value.
At some point you have to pass an int to the C APIs.
Cas
[/quote]
What you are saying makes some sense. But still it could not be such a big impact after doing some tests. The most limitating part of a game is rendering huge amounts of poligons and shading them. It may depend on the method used to set up the scene before being rendered. It could still be good to give it a try and actualy test this stuff.
You must ask yourself if you want Java games to compete
for the same market where C++ developers are already established. Thats the several million dollars market that gets you the money.
Forget about staying compatible with old versions of the language. This is a very bad strategy for Java games development on the big bucks market.
I’d like to agree there too… except that for the foreseeable future one of the most lucrative niche markets, the Mac, hasn’t got 1.5, which rules it out for me.
Cas
The new JBuilder v2005 runs within Java 1.4 on Mac, Win, Linux, Solaris, … and per option it compiles 1.5 sources to target VM 1.4 - provided you give him a 1.5 SDK to help the compilation. Maybe this backwards compiling is similar to Toby’s famous retroweaver compiler?
Anways, this way it’s possible to compile and deploy 1.5 sources on J2SE v1.42 and higher machines. With ones exception[quote]If you’re compiling enums to deploy on an earlier JDK, don’t use static methods of the java.lang.Enum class or enum runtime exceptions will occur. Also, when compiling annotations, they will compile but won’t be contained in the class files.
[/quote]
(JBuilder doc)
Of course using a library like JOGL is another thing, when 1.4 Mac users need to use it…
Still, I see Zingbat’s points. The games market is different to the normal market. On Windows for example new games typically need the newest libs (DX blabla).
Because Java 1.5’s generics and enums and bla give me much more type safety at compile time, I’d like to use them now wheresoever possible.
Let Java enums be objects (I didn’t read that doc yet): Do the few casts hurt, which are needed in order to Java instruct the 3d HW to fill millions of pixels? Hardly.
The main problems with the enum approach are that:
The decoding of the enum to integer may not take particularly long (although it really does take some time, and it’s not insignificant), but it will greatly increase the size of the library.
The fact that the OpenGL specification mandates which enums are allowed in which positions, and that the specification is dynamically altered at runtime depending on what extensions are available. So you have it bad both ways - Java successfully compiles the code but you still have to check for GL errors anyway because that’s what you have to do to use the GL API properly; and Java fails to compile the code because someone hasn’t kept the sets of allowed enums in sync, and it’s a very, very complicated job and may not even be possible.
Cas
[quote] You must ask yourself if you want Java games to compete for the same market where C++ developers are already established. Thats the several million dollars market that gets you the money.
[/quote]
I don’t care. I care about my applications, which are not games, working on as many platforms as possible. Game developers can do whatever the hell they want. If they want to use Java 5 in their application development, then go for it. There is nothing stopping them from doing so. Keeping JOGL compatible with JDK 1.4.2 is not going to stop game developers moving to latter versions of Java. There is no reason to require that every single library also move up to a new specification version. In fact, it’s typically a really bad thing to do because you’ll lock out all the users on other platforms that specifically don’t want to upgrade. What about all those games out there using JOGL right now. They would suddenly fail to run - and Java suffers yet another hit to it’s already bad perception by the general public.
If you want to play dick-wagging games, be my guest. My market is bigger than your market, for example. In the development space that I work in (visualisation of all kinds), my annual market is measured in the hundreds of billions of dollars in the US alone, not tens of millions. I’d like to be able to still make money there. My company alone has made bids for just over 100 million dollars worth of projects in the last 2 months for one part of one government agency. That doesn’t include the private sector work in the resources, civil or auto industries. Moving JOGL into a space that would remove that market is just plain stupid. Just don’t assume that the only reason for JOGL’s existance is to satisfy a small niche of game developers.
[quote]Let Java enums be objects (I didn’t read that doc yet): Do the few casts hurt, which are needed in order to Java instruct the 3d HW to fill millions of pixels? Hardly.
[/quote]
Quite the opposite. Remember that OpenGL uses enums in almost every single GL call made. That’s potentially tens or hundreds of thousands of casts per frame. Hardly an insignificant number. Also, remeber that these enums are going to have to be performed on the native side. That means the native code needs to lock the object in the JVM, convert it to a real integer, then unlock the object. That object locking is still a very costly operation, so there’s more to the cost than a simple cast. Also, finally, OpenGL uses bit masks in a lot of places. Enums just don’t work at all in this situation. You end up needing to pass Sets of enums, which then incur far greater overheads which includes iterating through the set object on the native side, (lots and lots of JNI->Java code crossing again), as well as assembly of the bitmask to pass to the real OpenGL call. That’s far more work than is needed currently and will serve only to make JOGL far slower than using C to access OpenGL. Which, since the gaming market is so performance sensitive, it will lead to game developers fleeing faster than workers at a burning fireworks factory. Your percieved benefits will actually work as a negative.
Like i said use java3d. Don’t mess up with technology that is meant for people who are interested in making games. Your market and the c. game market should clearly used different technologies. C. games is tech intensive and requires constant evolution while yours is a conservative.
We just need something that is on the technological edge and cannot be bothered with compatibility trash code. This is something that needs to be done for game developers. Otherwise Suns better give up on any plans they may have to use their language in the competing game market.
Well, actually… JOGL is meant to be a general purpose binding to OpenGL, and OpenGL is meant to be used in all the spaces from games through to scivis and CAD/CAM. So JOGL fits nicely with this goal.
If you want to write games you ought to use LWJGL because it’s explicity and ruthlessly designed for the purpose
Cas
[quote]Like i said use java3d. Don’t mess up with technology that is meant for people who are interested in making games.
[/quote]
Ah… excuse me? Did we conveniently forget history or something? Please, go and find a book or six and read about OpenGL. Let me prime you by telling you that OpenGL in gaming is a relatively new aspect.
[quote] Your market and the c. game market should clearly used different technologies. C. games is tech intensive and requires constant evolution while yours is a conservative.
[/quote]
Exactly. That’s why you should be using DirectX, not OpenGL…
OpenGL, by nature is conservative. DirectX is not. Telling people to get lost because they are conservative is no way of gaining friends and influencing decisions.
[quote]We just need something that is on the technological edge and cannot be bothered with compatibility trash code. This is something that needs to be done for game developers. Otherwise Suns better give up on any plans they may have to use their language in the competing game market.
[/quote]
Right. Care to back that up with facts, or is that just your wish? Who is “we”? Show me how many game companies have released a commercial JOGL game so far. How many have not done so because JOGL was not using latest features of the JDK? How many have because it was not using it? How many are in the final stages of a 3 year development cycle that are based around a known quantity that is JDK 1.4.2 and if you shifted the entire API under them to force them to JDK 1.5 would just not bother to continue with the development and go back to programming in a more stable environment of C++?
Right now, there are two very strong arguments for why JOGL should not perform major surgery to use features of Java. You’ve completely ignored one (performance), and done a small amount of handwaving of the “but I want it to happen” type for the other. You’re going to need to be a hell of a lot more persuasive than that.
And, for what it’s worth, we also happen to do professional game development. We’re doing one right now that will be released at the end of October. We don’t want JOGL to be exclusive to Java 5.
Actualy for what you guys are telling me i don’t intend to use neither one or the other. To use LWJGL or JOGL without being able to use java enumerations, generics and all the rest of the magic in 1.5 is worst than working with C++.
At least C++ enumrations are ints but give some sort of type checking which doesnt happen when using java ints. As for the performance argument sure there will be a certain performance but first research an implementation of java bindings for OpenGL using enums and do some tests with a real game, then say it doesn’t work. I think you are giving up on this too soon.
Besides you have to build an engine on top of an extra layer that is worst than C++ and keep rebuidling it completely every one or two years.
Why ? Because thats how it is. Just check Doom3, Half-life 2, Morrowind or any other successful game. Game engines are complelety rebuilt every two years (sometimes more).
I sugest you guys read more:
or
the management sections. Its very rare for someone actualy reusing an old engine.
Let me restate my arguments. What are the advantages of using java for building games that can compete with the best C++ products ?
The advantages are more advanced programming techniques, better developement tools with refactoring and contract programming, less programming effort, less money spent on writing and testing code, more stability on the project, product is delivered sooner and more stable.
The high-level language really pays off when the code complicates itself with advanced AI and a complex scenes that require advanced lod techniques and resource management. So java, in principle, can help making better games.
Forget about engine reuse and don’t mix PC games development market with visualization market or mobile phone games or internet games or any other thing.
You will need to convince a publisher to sell your game and they have these numbers they get from their sales department that tell them when games are bull and when they can be sold. They may be wrong but they wont buy our games unless we tell them what they want to ear.
First it must run and it must run with a small performance difference.
Second it must be well integrated with the most common art development tools like 3d studio or maya.
Third it must look good and have the latest firworks depending on the game class.
Also depending on the game class (an rpg for instance) you must avoid things like turn-base, 2d isometric, and stuff like that have a very low selling value.
Fourth being a C++ game or based on a known and realtively recent engine. Not saying that a Java game won’t sell but it has to be a very good game and not show any weakness towards C++ games.
So to resume my arguments a publisher won’t be convinced by telling him the game is made in java or not but i must have a significant advantage using java instead of C++ otherwise doing a game in java to compete with games in the same area as Doom3 or Half-Life 2 is a waste of time.
Its much better to have bindings for a native mini-engine that does the bare minimum but allows me to use 1.5 language features, instead of direct bindings to the opengl apis.
But Zing McBat, it just doesn’t work that way! The C++ crowd would have done this already if it were possible, but as it ain’t, they ain’t bothered. You really need an engine on top of OpenGL, not to tweak OpenGL bindings themselves.
Cas
[quote]But Zing McBat, it just doesn’t work that way! The C++ crowd would have done this already if it were possible, but as it ain’t, they ain’t bothered. You really need an engine on top of OpenGL, not to tweak OpenGL bindings themselves.
Cas
[/quote]
I don’t understand you. What would they have done already exactly ? And why wasn’t that possible ?
What i was sugesting was a native mini-engine. Something like the Irrlicht C++ engine for example but only with the irr:video namespace (from that example) and the graphics device related classes.
As for the rest of the engine functionality like events, io, vector math, network, file formats (sound, image and xml loading), scenegraph, 3d gui this could be done using already existing java packages. The main problem with JOGL direct binding is that it is so low level that it doesn’t really fit in Java and it brings C problems to Java code.
I don’t know if any of you ever had to mess up with a C bug caused by misused pointers. These are very hard to check and find. The int arguments in JOGL bindings that are suposed to be enums in C are also very dangerous and error prone. Type checking exists for a reason.
You end up building a layer on top of JOGL to hide the nasty and dangerous coding anyway so why not pushing this code into a mini-engine and get rid of the useless layer that is JOGL ?