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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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"

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.

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 . Considering Sun still ships Java with a profiler, just not the one you were using, it isn't really that bad, is it?

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?

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