Okay. So, a lot of what this new group is about is listening to game developers and getting things moving in the right direction for them. We have a lot of ideas about what needs fixing, but we would like to see our list validated and updated with input from all of you.
So, what do you want to see fixed? (With a new #2 pencil sharpened in hand)
Doug.
PS - Cas, we know about structs. 
LOL ;D
So, what do you want to see fixed? (With a new #2 pencil
sharpened in hand)
1.4.2 Beta brought some much needed performance improvements. It is now feasable to do 2D at resolutions higher than 640x480. So I guess Iād say, keep that working, make improvements to what is hardware accelerated by Graphics2D (i.e. primitives like boxes should be accelerated), MAKE FULL SCREEN WORK FOR X11!!!, and fix JavaSound. JavaSound I think is a bit embarassing. Here you have an API thatās capable of awesome sound manipulation, itās based on HeadSpace which has support for everything from wav to MOD XM/S3M files, yet the volume control doesnāt even work!
Thanks for asking tho.
Combine the server and client VMs so we get faster startup followed by even faster running.
Provide a CDC J2ME profile based on this hybrid VM. Chuck out everything thatās not necessary to make a VM execute bytecodes. Add everything else as optional packages. Adjust license to suit this arrangement.
Fold in those VM startup improvements that Apple have sorted out.
Donāt be providing any APIs as āstandardā like ImageIO or JavaSound. Let the community come up with APIs to solve problems instead of choking them off with a bloated alternative.
Add special feature that gives me Ā£100 every time someone creates a new Thread and then complains when their animation runs weirdly.
Cas
Iād like to see lightweight objects in Java. And by this, I donāt mean the structs proposal on the bug parade. I just want to get rid of the cost associated with temporary objects. Iām tired of making my code ugly to avoid doing news. Even if the GC ever gets fast enough that doing news of temporaries is a non-issue (it isnāt there now), you still have the problem that following references is cache-unfriendly. For example, if I have
class A {
float v1;
float v2;
float v3;
}
I know that once I reference v1, v2 and v3 will also be loaded in the cache so accessing them will be fast. However, if I have
class A {
Vector3f v1;
Vector3f v2;
Vector3f v3;
}
Iāll be jumping all over memory accessing v1, v2, and v3. I want v1, v2, and v3 to be inlined in memory just like primitives are. I want to not have an 8-byte per object overhead, just like primitives donāt have. I donāt want to be able to extend v1, v2, and v3, just like I canāt extend primitives. I donāt even want operator overloading. I want lightweight objects.
I think everything is wonderful.
No changes needed.
Herk wins!
-SG
Improve the native code already used in the JRE. For example the JPEG decompressor and software blitting with alpha mask can all be accelerated significantly with SIMD instructions.
Reduce garbage generation inside the JRE, or the need to make temproary objects or copies to work with the existing APIsā¦ e.g. sometimes data from a Direct Byte Buffer must be copied to an array so that it can be passed to other APIs (e.g. JMF, ImageIO)
Improve JMF. It doesnāt work that great or get much support from Sunā¦ but has great potential. It could be used to send voice chats to other players in a networked game, play cutscene animations, etc.
I think I disagree with Casā #4ā¦ The rich set of APIs is part of what attacted me to Java. If they arenāt part of Java they wonāt get ported (because it wonāt be ārequiredā)ā¦ if they donāt get ported, there goes WORA. But I agree that there needs to be provisions to include only parts of the JRE, particularily if you are installing it only as a private JRE for your application, and not a system wide JRE. Extend WebStart to handle automatic installation of JRE subcomponents to the JREs that it is aware of. That way my WebStartable game can specify what APIs it needs and if the user doesnāt have a full JRE they will only get what is required by my programā¦ the next program may use a different API and WebStart will only need to download that small subcomponent before the program can runā¦
Finish the support for hardware accelerated 32-bit sprites.
As above Improve JavaSound (all of JMF actually)
Make a place to register codecs with java.sun.com for JavaSound, JMF, ImageIOā¦ make sure there is a link from the JavaDocs to those registered lists. (e.g. someone reading about Java Sound should easily find a link to the Ogg Vorbis codec)
Thatās all I can think of at the momentā¦
Wow, this really sounds incredible. Canāt wait to see what happens next. I imagine something amazing is planned for Java One this yearā¦ Any hints?
-Z
The worst problems in my last, quite comprehensive, Java3D project had to do with the JMF, Java Sound and Java3D sound integration, as well as integration between JMF and Java3D rendering. A robust sound implementation that works well with all the other media APIs would be a great improvement.
Another problem that came up on the horizon but never really affect my project in a serious way was again the lack of extensability in Java3D (specificly, the lack of shaders), but we all seem to be painfully aware about that one.
Better tool integration to support the graphics content pipeline would be nice, but the Xj3D folks seem to be doing a great job in that area and now it is mainly up to the 3D-modeller companies to start supporting X3D in a serious way.
I would hate to see Sun drop the productivity focus for Java and stop supporting libraries though, even if the libraries that are provided should be made more open and extensible. My most recent project is a great testament to Java and Java3Dās productivity. I modelled a virtual world in Maya, built a new physical interface, scripted and recorded cutscenes and dialogue, wrote a 3D-engine etc. in just nine weeks, much thanks to all the APIs provided by Sun and the Xj3D group.
How about the ability to overload operators, like in C++? That is the feature of C++ I miss the most.
[quote]How about the ability to overload operators, like in C++? That is the feature of C++ I miss the most.
[/quote]
There are two problems with operator overloading - syntax and value objects. You can have operator overloading with java by using one of variant java compilers - kiev for example (althrough it is a bit outdated, it still supports a lot of interesting possibilities, like mentioned operator overloading, multiple inheritance through delegation etc).
Real problem is cost associated with creating new object every time you use operator. It cannot be resolved without lightweight objects or really smart immutable object/escape analysis and until then, operator overloading will not be suitable for high-performance math - and IMHO, math is only area where you really need it.
Please check out
http://java.sun.com/people/jag/FP.html#overloading
LWJGL in the Jre and swing/awt optional ;D ;D
Ditto; the fact that Java started off with āstandard librariesā whereas C and C++ had to wait a looooong time before getting them has IMHO had a huge but subtle positive effect.
In fact, my only truly catastrophic problems with supporting java applications have always been caused by failure (of a JVM author) to do the standard libraries properly. One example is Apple (and a few other platforms) JVMās which only included parts of the standard libraries - in the end, I usually persuaded my employers to stop supporting Apple entirely, for the simple reason that the cost-benefit ratio was far far too high.
The other obvious example is the massively irritating state of Fullscreen mode. Releasing 1.4.x with the new fullscreen API, but without support on major platforms (unix, linux) must be having a bad effect. Just look at the number of people who state āIām not doing a fullscreen version of my game/app because it doesnāt work on all platformsā. Iām not complaining - just trying to point out how much pain comes about when a āstandard libraryā isnāt actually a complete standard.
This must surely be one of the most popular sensible suggestions. I just want to add that - if you follow this route - please be very careful to make it a VERY good packaging/deployment/versioning system. Linux, for example, is suffering hugely these days because of the widespread use of RPM, and the major failings in that deployment system.
I know from experience that a really good packaging system is much like a really good Data-Structures library - it takes a lot of thinking and planning to get just right, but the payback is felt again and again and again for many years to come. Positive or negative. These systems really need a lot of effort, and typically you canāt make big changes later on if you realise you did something badly.
Authoritative, UP TO DATE, documentation (probably in the form of tutorials) on the subtle, low-level issues. The BufferStrategy documentation is a good start, but it doesnāt go far enough. If you take those docs, add in everything that Jeff has said on JGO on that topic, add in the comments by the guy in the Java2D team about some of the experimental hardware support in 1.4.x, add in some of the comments by people on JGO, and you get the right level of docs.
The typical problem here is that if you are trying to use all the advanced graphics stuff āproperlyā, it is very hard to get it right first time. There are so many subtleties (e.g. āthis isnāt implemented on linux yetā) and unanswered questions (e.g. ācan I use Swing and AWT components with fullscreen mode? Are the problems Iām seeing my fault, or because of some incompatibility?ā).
Obviously, weāll have all those SPECIFIC examples cleaned up pretty soon. However, with each new release and API, if you are pushing hard at the boundaries of what is included in Java (e.g. adding a full OpenGL pipeline in 1.5 from scratch), the same kinds of problems will recur. If the release notes for each version were about 10 times as detailed, this wouldnāt be a problem. If the API documentation were perfect, this wouldnāt be a problem.
But we live in the real world, so Iād be happy with a subsection of JGO which was just an up-to-date FAQ on these gotchas. Searching JGO forums, and reading hundreds of posts to find a gotcha (the only way I currently know of dealing with these problems!) everytime you THINK you may have found one is far too time consuming.
[quote]How about the ability to overload operators, like in C++? That is the feature of C++ I miss the most.
[/quote]
Iām not trying to be facetious, but ājust because you miss it, isnāt a reason for porting itā.
There are damn fine reasons not to have operator overloading (and, of course, good reasons for having it - although Iāve been convinced over the years that the former outweigh the latter).
ā¦but if youāve got a really good reason for having it, then illuminate us (unless you were just trolling ;))
Number one reason for not having it:
Code maintenance often becomes much more expensive, because you have a much poorer concept of what, precisely, is happening when you read the code.
This is strongly related to some of the good reasons for doing away with header files and compile-time includes: reading and comprehending source code quickly becomes an exercise in remembering things, or fast-switching between lots of source files, just to read one of them; encapsulation typically flies out the window, and most of the advantages that go with it.
Blah blah blahā¦good programmers donāt make these mistakesā¦blah blah. But thatās what they said about BCPL, and typeless languages. I havenāt yet met the developer who would prefer NOT to have a compiler which was able to automatically catch programming errors (apart from Martin Richards, who is still in love with BCPL, all these years later 
).
[forgive the gross generalizations, in an attempt not to wander too far off topic, and into the wastelands where the Trolls liveā¦]
Overloading operators can be a nightmare for maintenance, since you loose consistancy when reading code, however the same can be said when you start getting badly named methods, or methods that have subtle but vital side effects which arnāt immediatly obvious when looking at the method signiture.
Just because some people can abuse overloading, doesnt justify their total removal. I can write bad code with or without this feature 
Likewise, what about this:
String head = "Some text";
String tail = "more text";
String list = head + tail;
So, what is that except operator overloading? I doubt youāll see people complaining about the readability with this (especially vs. the fully expanded form generated with chained string buffers). This is clearly a special case, and so breaks consistancy. </devils advocate>
I donāt particularly mind either way, but whatever the decision is, make it consistant!
Indeed. I have a vague memory of finding a bug in someoneās code for them, that was cause by the plus overload for Stringās, but Iām not sure; seems very unlikely :).
EDIT: I remember now. Just irritating problems that prevent compilationā¦You cannot do:
int x, y;
String s;
System.out.println( "something: "+s+", and x+y"+ x+y );
You have to bracket the x+y, to make the compiler interpret that plus as an integer plus, rather than a String concatenate. Minor irritant.
I have also seen problems when the implicit call to ā.toString()ā doesnāt happen. The call is normally triggered by the use of a non-String with a String-concatenate-plus, but if you pass an Object to a method that takes a String argument, the conversion doesnāt take place. This is kind of weird for some people, because the get used to the fact that you can insert an Object where a String is expected, and that the implicit call will ājust workā.
However, I have seen MANY major bugs because of javaās op-overloading for arithmetic on basic datatypes. The most common one is, of course, the difference between integer divide and double divide. Itās rational to overload float and double divide to be the same, but I frequently see people doing something like:
int x = 1; int y=2;
double d = x / y;
and being screwed by the unexpected value of 0.0d. Sigh. And this is a trivial example that you can learn to avoid by roteā¦things can get much worse if you add general overloading.
(Of course, the actual code has the variables separated up much more, and it is less obvious what the problem was!).
What really really irritates me about this example is that javac will refuse to compile (which is a whole separate stupidity: compiler warning? yes please ā¦ refuse to compile? Please, NO!) if it thinks I didnāt actually want an automatic cast for this:
float f = f * Math.sqrt( f );
when I often do want the cast, but WILL NOT do the same behaviour for the painfully common accident I highlighted above.
Ditto the stupid stupid stupid bug whereby:
Object i = null; // you HAVE to explicitly reference null, or it won't compile
// do something with i
is forced upon you by the compiler because otherwise it refuses to compile because āi may not have been assigned toā. What do I gain? If I try using it without assignment, Iām STILL going to get a NullPointerException; the only difference is that now Iāve had to write extra codeā¦Sigh.
[quote]There are damn fine reasons not to have operator overloading (and, of course, good reasons for having it - although Iāve been convinced over the years that the former outweigh the latter).
ā¦but if youāve got a really good reason for having it, then illuminate us (unless you were just trolling )
[/quote]
Iām not trying to troll here. Iāve just always found > or < more intuitive than a.compareTo(b). For instance, Iām implementing the storage of the map in a rts game as a sparse matrix. Since the elements are sorted in each LinkedList, it would be more intuitive to have > or <. But no, no troll here. I love Java. Iām not going back to C++. 
The solution to the problem with
f = f*Math.sqrt(f)
would be the addition of a full set of Math methods taking (and returning) float values. I gather this was omitted due to a defficiency in an early compiler (couldnāt overload on float/double). There ought to be an RFE for this, but I canāt find one.
As for operator overloading I think the only group with an undeniably strong claim are those using complex numbers and similar numerical types.