And the rather large number of us using vector algebra.
But then I’ve always advocated alphanumeric syntax for operators, which solves the pain of bad syntax and unreadability and project differences at a stroke:
a = a dot b;
and
if (a isGreaterThan b) {
}
Looks nice doesn’t it?
All the advantages of C++ operator overloading… none of the disadvantages…
Cas 
[quote]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.
[/quote]
Well, that’s just because the expression is evaluated in left-right order. The String’s + operator has the same precedence as the int’s + operator, so you need to explicitly bracket things.
[quote]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.
[/quote]
Well, it’s all logical I’m afraid! 
In the sqrt expression, (float * double) is promoted to (double * double), which is evaluated. It then tries (float = double), which fails to compile as it’s a narrowing conversion.
In the integer divide expression, (int / int) is evaluated first (as an integer divide, as both operands are integers), then it attempts (double = int), promotes it to (double = double) via a widening conversion, which then works fine. ;D
N.B. Some languages get around this kind of problem by having a different operator for integer divides.
[quote]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]
Nope, not a bug - there’s a big difference there.
Local variables are NOT implicitly initialised - you have to do it yourself. (Member variables are automatically initialised at object creation.) If you didn’t explicitly assign a value to a local variable, you wouldn’t get a NullPointerException, you’d get garbage - a reference pointing to some random bit of memory somewhere. The Java compiler refuses to allow this to happen, so you have to initialise it.
And why doesn’t Java implicitely initialise local variables? It’s to allow you to perform late-initialization of local final variables!
For me, main reason is to catch errors. Simple example:
String str1;
String str2;
if ( quiteOften ) {
str1 = “AAA”;
str2 = “BBB”;
} else {
str1 = “XXX”;
str1 = “YYY”;
}
This one is simple, but sometimes, with try/catch/finally etc, every help from compiler is useful in spotting such errors early.
;D. Yes, indeed it is. I only mentioned those issues because they tend to waste development time and/or be the source of additional bugs…
…And they are all due to operator overloading. Your N.B. summarises my point perfectly - if that operator were not overloaded, the problem would not occur. I’m just trying to illustrate that operator overloading already causes significant problems.
Sorry, I shouldn’t have said “bug” :). And I forgot the reason that abies gave…I too use that behaviour, so perhaps it’s just another case of “the cons are bad, but the pros are just good enough to tip the balance” :).
I think I tend to forget the “lazy/final” reason because this kind of feature (something that enables late or delayed or selective initializations) is missing in some other places, so that you cannot in general assume java provides the mechanisms to do this.
For instance, the rule that you cannot delegate to another constructor EXCEPT in the first line of another constructor. The sensible version, that would fit nicely with the feature you’ve pointed out, is if it said “you may not make any method call/etc that has any effect on the object-under-construction prior to delegation”.
I CAN execute statements before the delegated constructor call, since I can do things like:
public constructor( Object obj )
{
this( "a string"+a+", "+obj.toString() );
}
…but it won’t compile if you move the toString() method call into a line earlier, and use a temporary variable.
I’ve wondered for years if there is any reason for this. I’ve written pseudo-code for a compiler that decides quite easily whether a pre-delegation method call is OK. I can’t see a problem with it; doesn’t mean there isn’t one, of course ;). I can’t recall precisely what I wrote, but I seem to remember it did a check for things like whether you were assigning to a final variable, and made sure that final wasn’t assigned to again in another constructor, etc. It wasn’t difficult.
[quote]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.
[/quote]
Way out of topic for this thread - but we’d like to know what your project was and if you have a public page for it. We like to link to other sites that are successfully using Xj3D in their projects. PM me with the details if you don’t mind us linking to it.
Oh, the project is very public. It’s called Nevermore and you can find a poster about it at http://www.saar.se/nevermore_poster.php (PDF-file) and more details about the project at http://www.saar.se.
I really just use Xj3D for loading static VRML models, but I can see it become a really important API in the future if Java3D manages to stay alive and AliasWavefront implements full support for X3D-export in Maya.
Thanks guys!
We have a long way to go yet but yes this is what we’ve been bursting at the seems to tell you. The client effort will all be discussed next week and yes we still see it as critical.
I should mention, since the press release didn’t (sticks tounge out at the “marketing guy who get HIS name mentioned”) I’ve got a new title too…
Jeff Kesselman
Architect, Game Technologies
Software Advanced Technology Group
I’m doing two things primarily right now. The first is doing everything I can to make the transition of the tech we worked on in JSR-134 over to open-source smooth and fast.
The second is that I’m leading the effort at defining the software part of the Sun server solution set for MMOL games. As some of you might remember I’ve had a long standing interest in back-end infrastructure for thsese kidsn of games. DOn’t betoo surpised to see some of the ideas we’ve discussed here in times past making it into that stack
JK