Java-Gaming.org    
Featured games (78)
games approved by the League of Dukes
Games in Showcase (429)
Games in Android Showcase (89)
games submitted by our members
Games in WIP (466)
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  
  "Better, faster, stupider Java"  (Read 5282 times)
0 Members and 1 Guest are viewing this topic.
Offline Bombadil

Senior Member





« Posted 2005-11-23 07:24:16 »

Javalobby brought my attention to this:
"Better, faster, stupider Java" by Ed Burnette.
http://www.eclipsezone.com/eclipse/forums/t54318.html

I like many of the new Java 1.5 features (namely generics). However I think there are some good points in the article.
Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #1 - Posted 2005-11-23 11:16:51 »

Yes, I've read the article too and I think it's spot on.
Generics was a fair addition, but java should not try to be the same as C#.
All those syntactic changes in C# only makes it difficult to keep up, makes many things complex to keep compatible, increases the learning curve and afaik most changes are not useful at all in the first place. C# is turning into the mickey mouse equivalent of C++ in many ways, let's not do the same thing! Let's keep it clean and simple.

Offline Bombadil

Senior Member





« Reply #2 - Posted 2005-11-23 11:59:14 »

Generics was a fair addition, but java should not try to be the same as C#.
(..)
C# is turning into the mickey mouse equivalent of C++ in many ways, let's do the same thing! Let's keep it clean and simple.

Erik, I agree 100% with your article.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zero

Junior Member





« Reply #3 - Posted 2005-11-23 14:12:27 »

Quote
My suggestion? Hold the line at the JSE 1.4 level or earlier.

That may be a good idea for enterprise stuff, but I really don't agree with that for games.

Aside from some vesion 5 language extrensions are compatable with 1.4 (e.g. generics with the right erasure type) games are end-user applications and therefore you only have to bother whether the code is running and not for developer support. Either put the JRE in the installer or use Webstart, same do most game developers with DirectX, IMHO the worst problem for java games ist still that the user either don't have the latest opengl driver installed or none is available for their notebook and of course that's not a java problem.


I like every new Java 5 Feature, even more: I probably would use java without them;). On the otherside, one reason I prefer Java over C# is its simplicity (yes, I still see it clean and simple) therefore I agree that new C# 3.0 features should be analysed very carefully before thinking about cloning them.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #4 - Posted 2005-11-23 15:25:42 »

I like every new Java 5 Feature, even more

even "no profiler" ?

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

Senior Member




Giving Java a second chance after ludumdare fiasco


« Reply #5 - Posted 2005-11-23 23:39:15 »

I was sitting in a meeting with folks from a company with $150+ billion in assets and they were grilling one of our head IT guys on our policy of supporting new os's.  Apparently they'd had alot of trouble with one of our applications that had started out life as a windows 95 c++ project and then switched to .net/c# and upgrading to winxp (not even sp2).  Then they started talking about supporting 'alternate oses' in the future.  These guys were frustrated.

The message I got from that entire exchange was; the big boys don't care about technology, they just want stuff to work, be maintainable, easily enhanced, and 'do what they need'.  Today we're not limited by processor speed, memory, or bandwidth.  We just need the simplest most straight forward solution.  Changing .net every couple years gains MS no friends in my industry, that's for sure.

edit; and note my company still uses jre 1.3.1 for production java work.  Financial companies are very risk averse...
Offline hvor2

Junior Member




Beyond mind, there is an awareness...


« Reply #6 - Posted 2005-11-23 23:49:52 »

The message I got from that entire exchange was; the big boys don't care about technology, they just want stuff to work, be maintainable, easily enhanced, and 'do what they need'. 
That's part of my experience, too. Our bussiness application could be made in anything, as long as it works and is easy to maintain.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #7 - Posted 2005-11-24 04:10:27 »

Financial companies are very risk averse...
They're also theiving weasels.


In general I don't agree with holding java source code at the Java 1.4 level.  By all means check your target market and do proper testing if you are thinking of moving to a newer release -as you always should, but to not use a new feature just because somebody down the street isn't- that's just lame.  People that write articles like that are in my opinion overly cautious.  Move forward with care, but keep moving.  The need to stay in the dark ages forever because it is "safe" is a myth.  It's thinking like that that gives us stupid things like 8.3 filename limitations still in Windows programs, and various bits of lame MS software that converts your file names to upper case for no apparent reason.  Those sorts of frustrating 'features' are what you get by trying to remain compatible with yesterdays technology.

It's one reason I like my Mac.  Except for security fixes, Apple doesn't  look back after a new OS release is out.  All your old software still works with your old OS if that is where you want to stay.. but the new stuff is going to require and use the new OS features, they don't cripple everything for the dinosaurs.  Java 5 for Mac doesn't work on OS X 10.3, only 10.4+, and I couldn't care less.  If you aren't willing to pay $100 to keep your OS up to date (the one piece of software you are guarnteed to run every single time you use your computer) then you deserve to be stuck with yesterday's applications.  In that sense the JRE is like the OS, it's the virtual OS for Java programs. 

Sure I realize everyone can't jump to the latest bleeding edge version as soon as it is available, but the idea of holding back the new because of the old seems wrong to me.  If V1.0 works for you , great, if V2.0 requires an updated JRE, so what?  V 1.0 was already good enough for you, remember? Keep using it if you don't want to upgrade your JRE and stop your whining. Smiley

Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #8 - Posted 2005-11-24 09:49:06 »

Sure, staying up to date is all fine, until you have to start upgrading everything every 3 months. Software developers with money to spare are happy to do that, but it annoys the hell out of the rest of the world. Since 'the rest of the world' is kind of a large market, it makes perfect sense to keep some compatibility and stability.

But really, keeping compatibility is just part of the story. It's also language cluttering like in C# that I don't want, even though I'm all for improvement and going forward.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #9 - Posted 2005-11-24 20:19:21 »

I guess part of my argument is "why do you HAVE TO keep up to date?"  Update it you want to.  And realize that it isn't economical to cater to people that only want one or two thing out of many in a new product.  So you either have enough reasons to update or you don't.  The stagnation that would result from not updating at least occasionally is more of a bother to me.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #10 - Posted 2005-11-24 22:37:00 »

I update software when the new features are needed, or more likely these days (sigh), when the old version has had some fatal security flaw, just waiting to be exploited by criminals.  I could do most of my work with a copy of Windows for Workgroups & Word 2 if I had to.  Maybe add a trumpet TCP/IP stack (remember that) & some crappy email software.

[rant]To me it seems that software goes through a lifecycle.  It's born and meets a need, although liable to piddle on you at inopportune moments.  Then it grows up a strong youth, useful & reliable.  Then sadly it becomes middle-aged bloatware, developing an unsightly spare tire, or even in extreme cases becoming clinically obese.  At which point it gets upstaged by a younger fitter piece of software & promptly keels over from a fatal heart attack.

I think Java 1.5 definitely has developed love handles & is working its way towards a pot belly & a spare tyre.[/rant]

Good thing this is the off-topic forum.  I don't know what came over me.

Alan

Time flies like a bird. Fruit flies like a banana.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #11 - Posted 2005-11-25 02:23:31 »

Very true...  Microsoft Word is a perfect example of software that is disfunctionally obese.  Most of he features are useless and the few basic things you need are difficult to use.   but I think Java the language is probably a the sweet spot now with Java 5.  Java the platform needs some refinement... there are bits that need to go and bits that are missing.

Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #12 - Posted 2005-11-25 05:03:40 »

Quote
there are bits that need to go and bits that are missing.

You mean type erasure?
I would really love to know when(not if) Sun will get rid of that.
The entire community is so fed up with it.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2005-11-25 12:41:27 »

Type erasure was a nice compromise between completely breaking all existing libraries and code and getting us more compile-time checking. The more I use it, the less I understand it, haha, but the more I understand why they had to do it that way.

Cas Smiley

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #14 - Posted 2005-11-25 15:11:06 »

Yeah, I have no particular problems with type erasure.  It was a reasonable compromise.  The only moderately annoying thing is those few places where casts are still needed and you get the warning about casting from the erased type so you don't have the type safety.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #15 - Posted 2005-11-25 15:17:39 »

The things I meant to get rid of are the bits like Enumerations, when we have the Collections stuff now.  That and much of the deprecated stuff.  Or how about all those classes that have get(int n) and getElement(int n) or elementAt(int n) or item(int n) etc..  I mean come on guys, pick something and stick with it!
Considering the amazing refactoring tools we have available, you would think that a tool could be made such that you could get rid of all the redundant methods in the JRE and have a loader tweak older classes to use the correct method.  If not a loader than at least a developer tool that would safely update old code.  Or better yet, just before the VM decides that a method doesn't exist it can see if it is a method in the java.* package that has a replacement.. so it will cost nothing unless a legacy method is actually called, and even then the cost will all be on the first call from that call-site only.

Offline kevglass

JGO Kernel


Medals: 85
Projects: 22


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #16 - Posted 2005-11-25 15:53:39 »

It'd be nice to make "deprecated" an access level like private, public, protected etc.. It would mean it was only visible at runtime not compile time Smiley

Kev

Offline Raghar

Junior Member




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #17 - Posted 2005-11-25 23:33:15 »

Thread.stop() is deprecated. This doesn't mean it should be unaccessible.
Offline Jeff

JGO Coder




Got any cats?


« Reply #18 - Posted 2005-11-25 23:42:11 »

Having gotten used to the changes I have to honestly say they DO make my code cleaner.

My only worry is the usual power-tools worry that naive users will cut their fingers off and blame the tool.

We've already seen this with people throwing autoboxing around and just assumign that somehow because ist part of the syntax, its free...

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #19 - Posted 2005-11-26 09:06:39 »

My earlier post was made in rather a fey mood  Roll Eyes

Actually, I really like Generics.  The lack of C++ style templates has always left me uncomfortable when using Collections.  I keep (kept?) agonising on whether to cast everytime I extracted something from a Collection, or whether to create a class, inherited from the relevant collection, but with the cast built in.  The latter has more overhead, but better compile time checking.   This I'm really pleased to see Generics, because it catches miscasting at compile time, but without runtime penalty.  Many thanks to the Sun team Smiley

However, I don't feel the same way about autoboxing.  Ok, this means I can put basic types in & out of Collections without manually encapsulating them in a class, which is nice.  But, as has been said earlier, these are not 'free' operations.  It probably doesn't matter if code performance isn't an issue.  I guess, it's more of an issue when games programming, as it would be easy to overlook inadvertant use of autoboxing in a tight loop, which could slow things down and produce lots of garbage.  It disguises cases where it would be better to declare things as Integer, Float etc. throughout.  Really, this is an aid to sloppy programming.  I prefer to type in a few extra characters, so that the compiler knows I really wanted those encapsulations.

Since it is possible to have more then one JRE installed at a time, I think it should be possible to phase out depreciated methods over (say) 3 to 5 years.  However this does raise the issue of how long maintenance releases of earlier JREs should continue to be made available.  So phasing out depreciated methods is not really free.  However if it isn't done, the language begins to suffer API bloat, so I'm largely in favour.

Alan.






Time flies like a bird. Fruit flies like a banana.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #20 - Posted 2005-11-26 12:01:34 »

Sure I realize everyone can't jump to the latest bleeding edge version as soon as it is available, but the idea of holding back the new because of the old seems wrong to me.  If V1.0 works for you , great, if V2.0 requires an updated JRE, so what?  V 1.0 was already good enough for you, remember? Keep using it if you don't want to upgrade your JRE and stop your whining. Smiley

There's also a trust issue here: many of us - with decades of extremely good reasons - don't trust anything that's "bleeding edge", because that phrase more often than not means "untested pieces of crap that sort-of manage to do something new and funky, but can't do basic things the previous version did". That's the "bleeding" part of "bleeding-edge" Tongue

Now, if I could *trust* developers, if I knew they didn't subscribe to the MS view of software engineering ("ship it before you even know what the requirements are, if the marketing depts' branding strategy for this quarter needs a new release of *something*"), it would be a different story. For instance, I upgrade nearly all debian software as soon as it's available. Sometimes I get bitten, but 99% of the time the upgrade has been sanity checked and refused by someone else if it's not up to a minimal level of quality (I find it sad that it's a victory for modern software to hit "minimal" quality).

The "we removed the profiler from java 5" example I cited above is classic - I trusted Sun not to do anything as fundamentally destructive as that in the move to 1.5; maybe,I thought, maybe you'd see something like that in an alpha or early beta. Clearly, my trust was misplaced.

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

Junior Member




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #21 - Posted 2005-11-26 20:27:44 »

Hprof is out from JDK? From what subversion. IIRC I did profiling on 5.0 without problems.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #22 - Posted 2005-11-27 00:11:12 »

The "we removed the profiler from java 5" example I cited above is classic - I trusted Sun not to do anything as fundamentally destructive as that in the move to 1.5; maybe,I thought, maybe you'd see something like that in an alpha or early beta. Clearly, my trust was misplaced.

They have put the caveat on the -X options since forver, that they are subject to go away at anytime.  Sun trusted you to heed the warning Smiley.  Considering Sun still ships Java with a profiler, just not the one you were using,  it isn't really that bad, is it?

Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #23 - Posted 2005-11-28 10:20:07 »

Quote
They have put the caveat on the -X options since forver, that they are subject to go away at anytime.  Sun trusted you to heed the warning .  Considering Sun still ships Java with a profiler, just not the one you were using,  it isn't really that bad, is it?

Well, -Xprof is still there, but it's broken and unusable. It's not like the JVM reports "Hey you used -Xprof which is not there anymore, use -Xsomeotherprof instead". No, it seems to work, but it really doesn't.
Sure, they could have simply removed it alltogether because it's an -X option (which would have saved me a lot of time trying to find out what the hell was going on since the 1.5 JVM), but since they didn't, it's fair to say that Sun broke something that many people depended on (including myself), which *is* a bad thing. It doesn't change anything that it is a -X option. -X is for 'out-of-spec' options, not 'lets-ship-something-buggy' options.

What if they decide to break -Xmx, and just silently set the max heap size to maximum 32MB, no matter if you set it to 1GB using -Xmx?

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #24 - Posted 2005-11-28 17:02:49 »

Ah, I misunderstood the issue.  I agree.

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 (81 views)
2014-04-15 18:08:23

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

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

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

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

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

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

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

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

CJLetsGame (223 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!