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!"
"This release was made possible by our world-wide development community.
Oh, yeah, and ridiculously large settlement payments by Microsoft."
bug.gd: error search engine. Humanity working together to solve all errors.
I wait for the first bug reports ... and version 1.5.1 ...
I've been waiting for this for a long time! Now waiting for Eclipse to release a working plugin (well, there's this ,but it's not that great.
Microsoft was right to be afraid, developing in Java is a delight.
Sam
After they took all that time to rewrite it with the latest API they claim they can closely track Sun releases. This will be the first big thing since then, so it will be a test of Apple to get it out quickly.
Brennan Stehling - http://brennan.offwhite.net/blog/
Don't you know, we don't hate Java anymore. These days we all love Java due to its major new feature -- its not C#
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
I look longingly at typed collections to save yet another ClassCastException on anonymous iterators. *sigh* oh well, maybe 6 years from now...
[% slash_sig_val.text %]
we still gotta wait....come on Steve, get out of the hospital and give us our static imports and generics!
Monstar L
Now let the slashdotting commence!
If any one is interested in reading the release notes, they can be found at http://java.sun.com/j2se/1.5.0/docs/relnotes/featu res.html
I, for one, welcome our new virtual machine overlord.
Dude you know you are not supposed to say these things in the story itself.
Banu
Well, some may call the 1.5 as being increasingly bloatware, but, why in some aspects this may be true, I think all by all there are considerable improvements over the former releases, especially 1.4.2.
JVM 1.4.2 (at least some sub-versions) were riddled with bugs, which, for instance, become apparent when people use systems that rely on it in a special way, as with Freenet. It comes as no surprise, that there were numerous reports of some errors on OSX and BSD, as well as on linux, when running JVM 1.4.2. For some time, we had to say "If you experience any difficulties, please try/revert to JVM 1.4.1 or 1.5.x and see if that solves the problem."
It is crazy to recommend reverting, but the main devls of java were unwilling to remedy the bugs in 1.4.2, claiming it was a Freenet-problem, while our devls said it was a JVM problem. Though it must be said some within freenet claim their is little to no problem with it (probably windows-users, or maybe some sub-versions that worked on specific linux-distributions). Anyway, my advice has always been, and will be (certainly in the light of the stable 1.5 release), to NOT use the 1.4.2, especially when using OSX or another 'nix based OS.
And also; be sure to get the JRE, and not the full SDK, unless you plan to develop Java software.
--- "To pee or not to pee, that is the question." ---
I wonder if IBM will have a 1.5 JDK? For a company that is putting a lot of juice behind Java, it seems odd that they don't make the JDK available to others...
Linux IT Consulting and Domino Development in Michigan
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 when you are iterating over a collection or an array. The type safe collections are also very handy--no more class cast exceptions and stuff like that.
.NET
It would be nice though if Sun would make Groovy or Jython a standard part of their java distribution. That would definitely make it competitive with
Click here or a puppy gets stomped!
Actually no, it is an app problem. Sun has introduced weak references way back in 1.3 to cope with that problem. And I have to admit, I never had any of these problems since 1.3
But it also could be that your program simply needs a tad more ram.
Following, check out the -Xmx and -Xms parameters of your application startup file and add more ram (java fetches 32MB in without any params and fills it up before it starts the GC for the first time) That might help.
But never count memory leaks out, they are very rare, but can happen if somebody has tangling references, pretty much the only case where the Garbage Collector can do basically nothing.
The VM itself is not flakey, I have a few servers running here, with an uptime of a year already.
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.
> ok, it got faster, but still not as fast as C++ too.
;-)
> I guess this will finally come but when ?
Errr...
Java 1.4 was comparable in speed to C++ (except obviously for Trig which got a huge overhaul in 1.4 and slowed down some)
It really depends how you write you code... Sloppy C++ code can be slow too..
Nice that Java VM is now faster; it's one of the major drawbacks of java on the desktop. But how does this compare with the new and shiny Mono? Mono with its distributed system, and if it still beats Java, then java is in for a tough fight.
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.
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 ++.
Yes, Java's GC would notice that nothing is referring to them and remove the objects. This unlike a simple reference counting gc such as python's which would not notice this. Java's GC can even relocate memory on the fly to minimize page misses and avoid memory fragmentation.
Considering that nearly 100% of the justification I've heard from people who like C# is along the lines of "It's not Java".
...
Come to think of it, this entire situation is sort of starting to sound like, um, something else...
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
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
> Its' not the case in Java where it sounds like there's only 1 way to do each thing
I take it from this comment that you haven't actually tried java. You can "explorate" to your hearts content, and there are many ways of doing the same thing (some obviously better than others)
> mostly because of the plethora of APIs (WebLogic, etc.) that corporations force you to use over it...
Now this comment just has me bamboozled... You mean that Weblogic holds sway over you and force you to code in one way over another? Surely weblogic is just an appserver? Which runs code designed to the standard J2EE API spec? The same as using Tomcat , JBoss or Geronimo or even Hibernate? (All of which are free and opensource, and follow the same J2EE spec that Weblogic does -- they just solve separate parts of it, and can be combined to do it all if you require)... I fail to see how this is a corporation forcing you to use one method of coding?
Sure, if you are only going to look at one way of achieving your goals, then there is only one way to go...
Sorry, Dude, but the Java VM still is faster than .Net and Mono is significantly slower than .Net (since it is just a basic VM with a basic jit and no runtime optimization)
.Net programs sometimes can be faster than java programs because they are heavily integrated into windows wheras java has to add abstraction layers for not losing portability.
.Net unless they move to another VM which is maintained by a dedicated team (parrot comes to mind) but then they will lose compatibility on binary level to .Net (which is not really there anyway since Microsoft plays cat and mouse with them on a classlibrary level)
Despite the having a slower VM, the
But back to Mono it will probably never be able to catchup speedwise with
First off, Websphere 4.0 is J2EE 1.2 only. You need Websphere 5.0 to get to J2EE 1.3.1. In Websphere 5.1, you at least get JDK 1.4, and a few J2EE 1.4 tidbits (JSTL 1.1, for example).
However, your ClassCastExceptions will only get bumped to compile time in JDK 1.5, true. But I must admit that in eight years of Java programming, I've never had this particular problem where it didn't take more than a few seconds to find the source of the bug.
I really just want the metadata stuff (which was obviously ripped off from C#, but it's a great idea). That, and EJB 3.0, which gets rid of the stupid deployment descriptors.
In an interview given just last night, the spec lead for 5.0 is asked what in his view the coolest new feature of the language is. Calvin Austin replies: If I just restrict myself to the language it would be metadata (JSR 175). We've only scratched the surface of its potential. For the platform, it's a bytecode insertion for profiling (JSR 163).
No Hjelfsberg is totally right. The extensions are syntactic sugar. But still they are useful, because, you gain coding efficiency that way. Autoboxing, foreach, generics are all implemented in a way not to break the byte format, but you still need less code for doing jobs like iterating lists fetching elements from data structures and so on. Day to day stuff which you used every 10th line or os.
Priority #1 for Sun was not to break the bytecode format. Priority #2 was to ease the life of programmers
The only thing which really will make a difference on code generation level will be the meta data, this one will make life easier for the implementors and for the users of servers. Soap instantly comes to my mind with the C# like @webmethod metadata. No more post and precompilers for doing that stuff, yiehaa.
Hjelfsberg is a smart guy, although I dont share his views on unmanaged exceptions, he is dead right with his comment on this.
This does indeed work too, I have played around with it and graphically intensive Swing applications really fly with OpenGL activated (given that your graphics card and drivers are sufficiently bug-free and modern). Read about it here
And yes, it does work under Linux, and Windows and Solaris (and most likely will under OS X, though that is up to Apple to implement).
Even without OpenGL acceleration the Swing responsiveness improvements are very impressive, coupled with the much better both default theme and theme mimicking in 1.5 I'd say it is time to retire the Swing troll.
Here's why:
t ml
.NET that's fine. Unfortunately MS's revenue stream requires that they change your environment on a regular basis. In my opinion that's the worst thing in the world for professional developers. Proficiency comes with experience and if you shift the syntax and grammer around on me every couple of years it's pretty hard to get really good at anything. At least Java is, pretty much, the same now as it's always been for nearly 10 years. Can you say that about VB?
http://www.joelonsoftware.com/articles/APIWar.h
If you like C#, VB and
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!
The Eclipse 3.1 betas support 1.5 constructs. I normally use the integration builds.
Archie - CIO-for-hire
Yes, Java's GC would notice that nothing is referring to them and remove the objects. This unlike a simple reference counting gc such as python's which would not notice this.
Your information about Python is about four years out of date.
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.
Java Developer needed. Must have 3+ years experience with Java 1.5, to start immediately.
"A witty saying proves nothing." ~Voltaire
"d'Oh!" ~Homer
I work on a minor, highly targetted Linux distribution. I'd love to include Java, and I actually get a lot of requests for it. But, here's an excerpt from the license agreement you'll find if you look to download the software:
(Yes, it really does just end abruptly without finishing the sentence. That trailing "and" there doesn't lead into the next section; it's just not done. Obviously I'm the only one who bothers to read these things -- *including* the people at Sun. Anyway....)
My wish to give the software to my users fails almost every test....
i: I don't want to distribute it for the "sole purpose of running [my] Programs". I want to distribute it so people can run other people's programs, including possibly their own.ii: uh, well, actually, my "Programs" don't add any functionality to Java, let alone "significant and primary".
iii: oops, I include gcc, which has a Java compiler. And I'm definitely not going to drop that.
iv: ahh, now this one I can agree with -- fine keep your copyright notices, etc.
v: my distribution as a whole is under the GPL. I'd have to run this by our lawyers, but this looks like it'd conflict by requring additional restrictions (even if I could get special dispensation to deal with the other issues).
vi: I don't really have the resources to defend and indemnify Sun "from and", even if I wanted to, thanks.
And frankly, that's why I wish people would stop writing things in Java. It's a pain to deal with. I want to make everything as slick, integrated, and as easy as possible for my end users. Sun makes that impossible for Java applications. If you want your code to be easily integrated and made available to users like mine -- and really, that's users of any Linux distro targetted more broadly than the super-geek sector -- please don't use Java. If you must, at least design it to work with gcj instead of Sun's virtual machine.
Unless Sun changes the license terms, their Java can never fill the "write once, run anywhere" goal -- but cleanly written source in an open language can.
You can only run it on a machine with a perl interpreter on board. Now tell me exactly how that is materially different to Java?
Justin.
You're only jealous cos the little penguins are talking to me.
IBM no longer ships standalone JDKs- according to the license with SUN, they only ship JDK included in a product. IBM will definately have a 1.5 JDK, just don't hold your breath.
As much as I might hate Java, I repeatedly have to throw this one thing into the fray: I had exactly zero former experience with network programming, and still, I was able to produce a basic telnet-like application in under 30 minutes, using only the Java API doc and some logical thinking. And I only had a very brief introduction into the language. Transferring this to C (although the basic structure is exactly the same with BSD and Java sockets) took me about a week, with all those damn low-level error conditions.
Fight hunger. Filet a politician and send him to a 3rd world country of your choice.
Test I did: Run 'ant -lib lib checkstyle java' on XINS 0.207)
Preparation command:Timed command:I did 3 tests in a row for each Java version. I added the 'user' and 'sys' times and the averaged then. Results on my Gentoo Linux system with 2.6 kernel:
Java 1.4.2_05 34.5s Java 1.5.0-rc: 42.9s Java 1.5.0: 41.6s
Over 50% of the .Net libraries have not been ported to Mono and may never be. Mono is pretty cool but until it is fully ported it will remain years behind Java and .Net. You cant compare them like you cant compare java to perl. Java and .Net are very much competitors and will continue to dominate the industry in their niche. Companies need security (as in a future) for their multimillion projects. It took Java ~6 years to self promote. If Mono severely ramps up their efforts, they MIGHT reach the plateau. Java was first to the punch, which is a huge advantage. I would wager my hunting dog that Mono will not overtake java in the next ten years. If MS is lucky and throws enough money at .Net, it has a decent chance.
.Net. Dont believe me? Go count job postings for programming at Monster in a city near you.
.Net
You dont see companies developing 5k class projects in Mono, but thousands (if not more) do with Java and
My city last month?
60% Java
15% Perl
10% C/C++
5%
5% COBOL
5% other
I cant hire Java and Perl programmers fast enough.
Are you intolerant of intolerant people?
You mean 1.5.1_03.1
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
Why don't you try this?
1) go to java.com
2) click the big "get it now" button
3) download the EXE
Now quit trolling.
Yes, Java's GC would notice that nothing is referring to them and remove the objects. This unlike a simple reference counting gc such as python's which would not notice this. Java's GC can even relocate memory on the fly to minimize page misses and avoid memory fragmentation.
Python actually uses a generational garbage collection system that can break cycles to reclaim unused objects. It also performs certain optimizations to avoid unnecessary memory allocations and deallocations.
In Python, reference counting is a combination of a historical artifact and a performance optimization.
Are you aware that the vast majority of games you play on any phone (except Verizon phones) are written in Java?
Thought not.
I was surprised to find that the ObjectOutputStream has a static HandleTable inside it that creates an entry for each HashMap that I put through, and it keeps a reference to each HashMap. I searched around, and this is a common problem that is not mentioned at all in the javadocs. You're supposed to reset the ObjectOutputStream periodically to free up the HandleTable. I had assumed that reset was like InputStream's reset and never would have guessed that it had to do with Object caching in the stream.
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.
"...if you forget to nullify references to objects you no longer use, the garbage collector obviously cannot reclaim that memory.."
That's the whole point of the garbage collector:
a = new Class1();
a = new Class2();
The Class1() object will be picked up by the garbage collector and deleted (assuming the garbage collector is not broken).
a = new Class1();
a = null;
a = new Class2();
This defeats the purpose of having a garbage collector.
However, you are quite correct. It can be quite difficult at times to ensure that all objects are correctly cleaned up after usage. As soon as you introduce items such as HashMaps, etc, you run into potential for these problems.
We once had this issue when we embedded the mozilla javascript interpreter in our app. The problem was that you have to create a scope object, with all sorts of predefined classes and functions and so forth. This was expensive, so we pooled them. Unfortunately this left a memory leak, as objects declared in scope by the javascript itself would not tidy up at the end of processing.
Indeed it turns out the library has parent scopes, so we could create a new child scope cheaply each time, but the point remains.
dominionrd.blogspot.com - Restaurants on