Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (580)
games submitted by our members
Games in WIP (499)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Sometimes I hate javac  (Read 1692 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Posted 2004-03-23 12:43:04 »

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 Sad.

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();

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2004-03-23 13:08:14 »

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

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2004-03-23 13:49:33 »

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 Wink, is whether retroweaver will support them?

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mark Thornton

Senior Member





« Reply #3 - Posted 2004-03-23 14:05:08 »

Quote
The real big question, of course Wink, 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.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #4 - Posted 2004-03-23 20:04:52 »

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?).

Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2004-03-23 20:10:31 »

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

Kev

Offline rreyelts

Junior Member




There is nothing Nu under the sun


« Reply #6 - Posted 2004-03-23 20:22:26 »

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

Cas Smiley


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

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #7 - Posted 2004-03-23 20:44:43 »

Quote
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 Smiley) 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)"

malloc will be first against the wall when the revolution comes...
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #8 - Posted 2004-03-23 21:16:34 »

Quote

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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2004-03-23 21:48:46 »

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 Smiley

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (44 views)
2014-04-15 18:08:23

BurntPizza (40 views)
2014-04-15 03:46:01

UprightPath (56 views)
2014-04-14 17:39:50

UprightPath (38 views)
2014-04-14 17:35:47

Porlus (54 views)
2014-04-14 15:48:38

tom_mai78101 (77 views)
2014-04-10 04:04:31

BurntPizza (136 views)
2014-04-08 23:06:04

tom_mai78101 (236 views)
2014-04-05 13:34:39

trollwarrior1 (197 views)
2014-04-04 12:06:45

CJLetsGame (205 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!