It seems that much casting will not be needed in 1.5, will this affect performance any?
Not an expert … there are not so many casts in the source any more, but they are still there, just generated by the compiler.
But I assume a smart compiler can optimize some if them away? Dunno…
Only the JIT can optimise them away.
This is kinda sad because it was an opportunity for a few really good JIT optimisations that can’t be done now.
Cas 
Why?
By proving ahead of time that an object implements a particular method it is possible to both a) remove any casting associated with the object and b) potentially de-virtualise polymorphic methods in some circumstances. A JIT compiler currently has to figure this out for itself, at some cost.
Cas
So 1.5 is BETTER for that!?
So why is it ‘kinda sad’?
Methinks Cas means it would be a better solution to actually generate compiled code without the casts (much like C++ templates) rather than just have the compiler insert casts for you. Then again, how possible is it to implement something like this at a later point?
Since using generics the compiler is supposed to make it impossible to compile code that would put the wrong type in a collection that took Integers for example… does it even need to generate the bytecode for the cast? I don’t know enough about the VM … I mean it should be certain that that the cast will succeed, but does it still need to execute that bytecode to work with the reference involved?
I’m not sure if I understand the question…
The JIT already gets rid of redundant and unecessary checks. (Except for that bug we found in on-stack-replacement 
)
But to my knowledge this has nothing to do with 1.5
If you are referring to auto-boxing then its not a question of casting, but rather wrapping primitives in an object created for the purpose. This will still happen its just that the compiler will do it for you.
or am I totally missing the point?
The new syntax makes the following code:
List list;
String s = (String) list.get(n);
look like this:
List<String> list;
String s = list.get(n);
Now, to the human eye, it looks as if the cast operation has been removed, but of course, the bytecodes generated are still the same as the previous version because the bytecode spec has no notion of generics at all. That means the cast is still there and still costs. If the bytecodes could have declared something as being generically returning a String then the verifier would know already that a cast was not necessary.
A missed opportunity this time round, but then, casting is not a slow operation anyway.
Cas
The Generics help you. If you fetch elements with elementAt() from a Vector, you should do a instanceof before casting it, with generics you do not need this piece of code, so its a small speed up.
Generics are not Templates !
[quote]The Generics help you. If you fetch elements with elementAt() from a Vector, you should do a instanceof before casting it, with generics you do not need this piece of code, so its a small speed up.
Generics are not Templates !
[/quote]
That’s a ridiculous notion.
Where you are the sole inserter of objects into a Collection (it doesn’t matter whether it’s a Vector or anything) then you never need to check instanceof. Unless you really enjoy typing extra letters.
IME this is the norm rather than the exception.
I haven’t got hold of 1.5 yet, but I’m confused, it doesn’t take much, so much so that I’ve just downloaded JSR 14 and read through the spec again.
Section 6 is about translation from code to bytecode and the way I read it, it seems to work just like Templates in C++, i.e.:
If I did this:
public class MyList<A> {
A[] elements = new A[MaxSize];
public addElement(A element) ...
public removeElement(A element) ...
public int size() ...
public A get(int index);
}
And then I used
MyList<String> bob;
Then byte code would be generated for a class that looks like:
public class MyList_ {
String[] elements = new String[MaxSize];
public addElement(String element) ...
public removeElement(String element) ...
public int size() ...
public String get(int index);
}
Which would do away with casting all together (much like what the preprocessor does in C++)?
I don’t get it? Have my (well known) misinterpretations of documentation led me astray again?
Has anyone decompiled the bytecode that comes out just to check how its implemented?
Kev
PS. The instanceof check would only be needed if you hadn’t wrapped up your list of Object in a nice class. Which of course you’d do for super performance reasons.
Ahh - the way I understood it the compiler didn’t generate any new classes at all (like C++ templates), but just simply applied the necessary checks at compile time (“generics”). So it looks like I’m wrong, and it generates classes on the fly - then that’s pretty damned cool, as it will eliminate all the casting. It’ll bloat the code somewhat but never mind, RAM for code is very plentiful.
Hurrah!
Cas
[quote]If I did this:
public class MyList<A> {
A[] elements = new A[MaxSize];
[/quote]
I think that you need to do following
A[] elements = (A[])new Object[MaxSize];
and unless I have misunderstood the spec, no extra classes are generated - everything works on Objects or on some interface/superclass given in generics definition. Declaration of variable with generics does not generate any extra code.
Right, thought I might have misunderstood the spec
This is the example that’s led me up the garden path:
Kev
Hurrah!
Elsewhere I notice that trig speed has doubled as well. More woohoos!
This is shaping up to be, I think, the “watershed” JDK.
Cas
[quote]Hurrah!
Elsewhere I notice that trig speed has doubled as well. More woohoos!
This is shaping up to be, I think, the “watershed” JDK.
Cas
[/quote]
Please post trig link!
Thx