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.
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.
Erik, I agree 100% with your article.
[quote]My suggestion? Hold the line at the JSE 1.4 level or earlier.
[/quote]
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.
even “no profiler” ?
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…
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.
[quote=“nonnus29,post:6,topic:25300”]
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. 
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.
Alan
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.
[quote]there are bits that need to go and bits that are missing.
[/quote]
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.
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
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.
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
Kev
Thread.stop() is deprecated. This doesn’t mean it should be unaccessible.
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…
My earlier post was made in rather a fey mood :
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.
Alan.