Sometimes I hate javac

[blahblahblahh]

1   2   3   4   5   6   7   8   9

interface a {  public a geta(); } interface b extends a {  public b geta(); }

Doesn't compile. The method signature provided in b does not (and CANNOT) violate the method signature from a - but the compiler insists they "clash" by "returning an incompatible return type". Is this just to make JVM implementation easier? Sigh. Getting really fed up of how hard java makes OO development sometimes .

I really don't enjoy having to write pointless methods:

1   2   3   4   5   6

/** This is exactly the same as someMethodName, except javac  * won't compile it unless we give it a separate name. All  * implementations of someMethodName will just return the  * result of this method.  */ public blah someMethodName2();

[princec]

Fixed in JDK1.5 I believe "Covariant return types" I think - Toby will be along to correct me.

Cas

[blahblahblahh]

Yeah, I was under that impression too. I've only read a little about the covar stuff but it seems that this is one of the use cases for it.

The real big question, of course , is whether retroweaver will support them?

Games published by our own members! Check 'em out!

[Mark Thornton]

The real big question, of course , is whether retroweaver will support them?

I don't see why not --- the JVM has always supported covariant returns, it is the compiler which has rejected them in the past.

[swpalmer]

I'm not getting it.  I would expect that code not to compile, since Java does not allow two methods in the same class that differ only by return type (right?).

[kevglass]

1.5 should. Thats what co-variant return types are apparantly.. the ability to have two methods differ only by return type.

Kev

[rreyelts]

Fixed in JDK1.5 I believe "Covariant return types" I think - Toby will be along to correct me.

Cas

Lol @ Cas. Yes, blah^3 is complaining about covariant return types, yes they are supported in 1.5, yes they are supported by Retroweaver, and yes they are implemented totally by the compiler without VM support - which is why they're broken in regards to backwards binary compatibility.

God bless,
-Toby Reyelts

[blahblahblahh]

I'm not getting it.  I would expect that code not to compile, since Java does not allow two methods in the same class that differ only by return type (right?).

From a pure OOD perspective, they arguably aren't two methods but in fact one, and can be safely merged, just as interfaces are always merged (but classes are not, allowing only single inheritance).

This merging ought only to exist at the compiler level - it shouldn't be noticable at runtime, unless you use reflection (at which point there is food for debate about what signatures should be returned on particular searches for methods).

I'm not saying "it mustn't be like it is now", only that "it didn't need to be the way it is now, and I struggle to see any advantage to java developers of the present design AND I'm confident *I* could write a compiler that handled this so surely Sun (who are a million times better at it than me ) could have too".

PS I'm thinking of writing an article "1.5: syntactic sugar and boilerplate elimination? No way!", showing how most of the 1.5 changes are actually really heavy-duty stuff not lightweight eye-candy (as they seem to come across to many people). I can cite hardcore use-cases for quite a lot of the things that I at first thought "neat; will save a little time; not really *essential* though, is it?" and eventually realised were "without this, it's practically impossible to write application BLAH (and BLAH is only mildly specialized/niche)"

[Orangy Tang]

PS I'm thinking of writing an article "1.5: syntactic sugar and boilerplate elimination? No way!", showing how most of the 1.5 changes are actually really heavy-duty stuff not lightweight eye-candy

I'd really like to read something like that. I'm staying firmly rooted with 1.4 for the time being because (IMHO) the advantages with 1.5 just aren't quite worth it. And I will freely admit that most of the changes do seem (to me) like eye-candy and time savers rather than actually allowing me to do something new. Maybe in a month of so I'll actually get time to crack out retroweaver and give it all a proper try.

[princec]

The advantages of 1.5 are just so worth it!
Apart from the VM being, sometimes, like, 2x faster for no known reason (found this out by accident with a random cave generator I just wrote), and the new syntaxes making correct programs 10x easier to write, and the startup time being hugely reduced, and the memory consumption being hugely reduced, and the garbage collectors being even more efficient, and Webstart being loads better than in 1.4, er.... oh bugger too much brandy. Well it's the dog's, and no mistake guv.

Cas