Slashdot Mirror
Have a Nice Steaming Cup of Java 5
wap writes "The language/VM/religion that everyone loves to hate is now serving another cup: Java 1.5 is ready for download. The new features of 1.5 have been discussed here before. I, for one, welcome our new virtual machine overlord. I have been using the release candidate, and startup times are noticeably faster, as is overall performance, and the new features like typesafe collections and static imports are great to have. Let the Java flames begin!"
I wait for the first bug reports ... and version 1.5.1 ...
In typical /. style, as soon as Java is as much as mentioned, everybody expects the flame wars to erupt, and they always do...
I try to stay pragmatic about the programming languages that I use. For some jobs, Java would be my last choice, and for some it seems a natural fit. When writing hardware near code, or platform dependant stuff on driver level, nobody in their right mind would attempt to use Java. For high level rapid prototyping, Java is a often a quick and easy way of getting things done.
Java should never have memory leaks...
All the memory managment should be done by the VM as far as I know...
unless there is some advanced stuff i'm just not aware of?
Not memory leaks as such, but "memory leaks" for all practical purposes. How? Well, if you forget to nullify references to objects you no longer use, the garbage collector obviously cannot reclaim that memory..
Whilst code that uses the new language features must obviously be compiled with the v1.5 JSDK, this means that it must also be run on the v1.5 JRE.
This may inhibit the use of Java 5 by projects that want their programs to run on a v1.4 JRE.
- Brian.
I hate to say this, but:
your cut is the fact you can use it for free!
A. Coward
That's not interesting, that's cliche. People have been saying that for years. Let's be honest: virtual machines are where business code is going, and business code (enterprise applications, server side stuff, etc) is the primary focus of Java these days. .NET is a clear indication that this trend is a real one, and that that's where the industry is heading.
No, I don't think you should write ls or grep in Java. However, I'd say that you also shouldn't be writing an invoice processing system in C or C ++.
Fairies have wings, not tails.
I agree though, the naming of Java is consistently confusing. Should I upgrade from Java 2.. err.. J2SE.. err.. Java 1.3.1_08 to Java 5 or to Java 1.5 or indeed Java 1.5.0. Oh, and is J2EE 1.4 compatible with this new one?
It could be much simpler..
~Cederic
The new For loop may seem to be just syntactic sugar, but it isn't. It really does make the code look a lot cleaner isn't that the definition of syntactic sugar?
You can't hate any language as much as some people hate Java until it's really reached critical mass.
.jar libraries required by a "Hello World" app
There are two things that make any really big language a target: 1) people start using it for everything, including things its not suited for. 2) junior folks without a lot of compiler or cross-language experiences will cut their teeth on Java, and at that point in one's career it is sometimes considered cool to blame a bad application's flaws on the language it's written in.
Java has plenty of problems. There are brilliant essays written on it; some of them by Sun engineers. But the complaint linked to in story was so bad by comparison, however, I doin't feel offtopic in addressing some points it raised:
there are a thousand "super-efficient"
No.
it takes 12 objects instantiated in 4 containers to flip a bit in a byte
Oh, I see. You're flipping bytes.
there is the substitution of native performance of compiled code to code compiled "Just Too Late" combined with exceptional memory usage that entails
The VM is more work. Strangely, you will have trouble finding benchmarks that make other comparable high-level languages look way faster than Java on the same _non-user-facing_ application.
As always, code in C, assembler, or another specialized language if you really need to.
The speed thing is well-addressed elsewhere. Enough said for now.
we get the garbage collector which is scientifically fine-tuned to run just when user is expected to interact with the application in most time sensitive manner
People love to bitch about client-side Java. It's as if all the flaws they're used to from other client side systems are fine, because they're used to them, and every foible of Java is worth agonizing over as if it were the worst thing in the world.
I dunno what else to say, but I wrote an enormous graphic-intensive video game in it and it runs fine. And what I did is nothing; somebody cloned the QIII engine to the point where it plays actual Q3A maps (with multiplayer) at respectable framerates.
Once again, someone shows me a shitty client app written by a team of 30 22 year olds in Thailand and claim it's proof that Java sucks. Congratulations.
multiple, insideously incompatible with each other, versions of the so-called "universal" VM
Yes, leaving aside the fact that Microsoft deliberately broke VM compatibility. Not just in one or two big ways. In a lot of little ways. As in on purpose. Great example. Very honest.
There is a giant test suite. Gets better all the time. Reputable VM's pass it. Most of all, though, I just don't run into the cross-VM problem in the first place unless I'm doing 1.1 development for browsers, see above...
We actually abandoned DB2 8.x release because noone could deal with the havoc the DB2 admin tools were causing with various other retarded banking related Java apps.
There we go. The truth outs. You overpaid for a shitty product. Congratulations. You can do that in C or Fortran, too.
Blame the language, though. Don't blame yourselves for picking a bad app.
Oh well, time to have me shot on sight.
Have a nice day.
Want to Know How to Cheat the GPL? Read On!
Java's garbage collection sort of creates a general laziness among some coders who don't clean up because they don't have to.
This is a missconception of yours. In Java, you CAN'T clean up. In C++ you say , in Java you just say Probably I should correct my sentence above: freeing memory IS CLEANING UP, nothing else, so all Java programmers clean up automatically.
All it takes is one pointer *ahem* reference to some object that contanis a reference to another, that contains an array... If you've got a few hashes and arrays in the way, it may be difficult to tell exactly where memory is being used, thus memory leaks.
Well, for a GC that is not difficult to tell at all. Not harder as for a human
In C++ somewhere somehow one had called delete. So at the point where in Java a hughe amount of memeory is referenced, and probably never used again, you have a dangling pointer in C++.
but would what happen if two objects referenced each other but nothing else referenced them. Would gc know to follow the links between the two and see that nothing in the main app is using them?
Of course, thats the point about garbage collection
If you have a memory leak in java then it comes from things like that:If you do somewhere something like this you will run into an OutOfMemoryException sooner or later
It is really no difference if one "forgetts" a delete in C++ somewhere or one forgets a x = null; in Java somewhere, but the Java program won't crash indeterministic, thats a difference.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Sir, I regret to inform you that you've demonstrated "critical thinking" within a hostile forum. You are no longer allowed to read Slasdot. Move along.
Joking aside, it kills me to see the amount of research and due-diligence that goes into debunking a Microsoft-sponsored benchmark, but when it comes to Java most everyone starts spouting nonsense. People will remember their experiences from 8 years ago, or a bad app, etc. and immediately conclude that Java must suck for every conceivable application.
Java is a tool - no more, no less. Use it where you think it is useful and leave on the shelf if you don't think it will help solve your current problem. Most mature developers know when and where a tool should be applied.
Generics in Java have a smaller scope, when compared to C++ templates. The objective in Java is to provide a type-safety mechanism for containers. In C++, it is much more than that. Unfortunately, it is this extra ability in C++ that makes for some really complex code. Not sure if this has already been mentioned in this story, but it has been theorized that C++ templates are themselves turing complete (though I havent seen a proof to that effect).
I'm a bit puzzled by all the generics nay-sayers. I have tried out the feature, and they augment the language. I have yet to see a downside to this feature in Java (unless one counts the inability of the compiler to fully utilize the additional type-safety in compiler error messages). What is all the flap about?
There is no such thing as luck. Luck is nothing but an absence of bad luck.
While I think "write-once, run-anywhere" is a bit of a misnomer, it does actually live up to the hype, imho.
You can't really appreciate it however, until you've spent weeks porting C code between platforms, and a few hours porting similar Java code.
I've had headaches porting perl too (though I must admit its much better now). Things these days are much better for people *trying* to develop cross-platform applications in Java and a number of other languages and APIs, but when it gets sprung on you as a requirement late in the game (latter revisions, new customers, etc) porting a Java app is a godsend.
There's alot of valid reasons to hate any language (I've studied 22 languages and in their own way, I think they all suck), but that particular reason doesn't apply to Java.
The key difference between a Programmer and a Senior Programmer is that one of them is Mexican.