Guest post by “After an initial round of testing we’ve declared build 147 to be
the first Release Candidate of JDK 7. There are only thirteen changes in this build. Over half of
them are administrivial updates that don’t affect the actual code; the
remainder are true showstoppers, including several hard VM crashes and
a JIT correctness bug identified by an Eclipse unit test. If no new showstopper issues are reported, and if JSR 336 and the
component JSRs pass their Final Approval Ballots in the JCP, then this
will be the GA build for release later this month per the schedule
posted back in January.”
thats great!
if they just could keep java away from the web…
Several years ago, the mediocre Java performance and the lack of good widget libraries marked Java as slow and memory hungry when the first Java applets appeared, most of them based on AWT or ‘homemade’ widget libraries.
Sadly, these days the myth of Java being slow and memory hungry still remain.
I think if you could compare two current applications running inside the webbrowser, one made with the latest Flash release and the other one using JavaFX running on top of the latest JVMs, the performance would be comparable or, probably (I’m just speculating here) would be better in the Java side.
Yeah, Java has excellent numeric performance, there’s no way flash could compare; to be fair, ActionScript is not really designed for performance the same way Java is.
On the other hand, startup time and Swing performance have been constantly disappointing for normal desktop users: even on my relatively new laptop, IDEA’s menus somehow feel slow and unresponsive to pop up compared to any native program.
With the JVM being such an attractive target for alternative language implementations (hopefully getting tailcalls _someday_), one can only hope Oracle can fix-up these final minor flaws with the new JVM, and who knows what the merger of also-Oracle-owned JRockit’s techniques can further do for performance.
java is great
it gave me the opportunity to watch a gui been drawn line by line on a 500MHz P3 wit 192MB ram
First, I remember using Java on a Pentium MMX at 200MHz and I have seen none of that. Sure, the IDE (what later became Netbeans) was unusable, but we have come a long way since then, both HW and Java-wise.
Second, have you tried flash on a P3? I guess you could see a Pong game bring it down…
P3 (P2 also) days were the time when Flash wasn’t used to solve the wrong problem (video); it was a heyday of vector animations and games. Typically definitely more extensive than Pong, and running rather nicely.
Tailcalls are a part of JSP292. And JSR292 is part of this release of Java platform.
I want to believe, but JSR292 doesn’t seem to mention tailcalls (http://jcp.org/en/jsr/detail?id=292) and the Da Vinci page (http://openjdk.java.net/projects/mlvm/subprojects.html) doesn’t seem to indicate they’re in the jvm yet.
I might have misread. More precisely
http://java.dzone.com/articles/introducing-java-7-moving slides mention tailcalls.
Well, given how bad Flash performance is on most mobile/tablet devices (and even some desktops), comparing Java and Flash performance is like comparing the shit I took last night with the shit I took this morning. Either way, it’s still shit.
At work, we have Java apps running on servers inside of tomcat/resin instances, and we’re constantly having to restart them because of OutOfMemory errors and cpu spikes. For some of them, we have to restart them once or twice a day via crontab, because the architects can’t figure out WTF is causing them to wig out and swallow up RAM/CPU resources like a Hoover. Of course, I did not write these apps, so who knows how well written they are, but it seems like Java is a hog no matter what environment it runs in.
Edited 2011-07-11 02:50 UTC
Instead of bashing Java… have you thought about replacing your architects?
Agreed. I’ve had Tomcat applications run for 6 months without a restart – while in moderate usage. I am a Java developer, so I’m biased, of course.
You may want to look at the application itself. The biggest reason I’ve seen that any Java web application eats up memory/resources is not closing connections to external resources (i.e. databases).
Replacing your architects is a good start here. Anyone called an “architect” should be able to figure out your issues in 2 days, tops. But I guess it’s easier to bash Java itself.
Well, we’ve got perl apps that run side-by-side along with the java ones, and never have any trouble with those. It’s only once the ‘legacy’ perl code gets rewritten to java (I assume because of java’s multi-threading capabilities) does the trouble begin.
But who knows, you guys may be right. I don’t work on the dev team – I’m just the grunt that gets paged at 3am every time one of those f**king apps decides to go on strike. So, I just call ’em like I see ’em. I’ve seen so many badly written apps in java, both on the server and desktop, yet it always seems to be the developers’ fault every time this happens. Maybe other languages make it just as incredibly easy as java to write apps that run like dogshit. *shrug*
Edited 2011-07-11 05:31 UTC
Long running Perl apps?!?!?! WTF? The place you work at should sue the developers of those apps for intentionally obfuscating the source code.
But sure… Call it like you see it. Now let me call it how I see it.
Visa’s transaction handling applications have uptimes in months. Tel-co billing applications are under 90% average load and are restarted once per month for deployment or hotfixes. My own “poor little app” is used quite heavily and runs on a server with 1GB or ram. While mailinator works with Java for an incredible amount of time…
I use Jboss for all my java and java/flex applications at work. We do not have these problems when the applications are coded properly, and on proper hardware.
So … it’s either a coder issue, a tomcat issue or hardware issue. Nothing to do with Java.
Replace those developers, they are a waste of time. Or .. it could be one of those management “decisions”. In that case, replace those managers …
Edited 2011-07-11 18:16 UTC
Ever since Java 1.6.0_u10 *all* of Java2D has been *hardware* accelerated via OpenGL or DirectX shaders (depending on your platform). If your app is slow it is either doing a lot of work, you have poor hardware, or the person who wrote the app is doing work on the Event Dispatch Thread (EDT) instead of in a thread off the EDT.
Plus, Swing with the Nimbus skin looks really nice. Many people I’ve written Swing software for comment how nice the apps look – even better than their native Windows counterparts (plus I can develop on Mac or Linux and they run sweet on Windows).
As for the fella who can’t keep his webapps up, that is just laughable. I’m a consultant developer and it is fairly easy to write programs in Java that can stay up for a long time – if you do a little work using Java’s built-in tools to make sure that *you/me* hasn’t screwed anything up. JVisualVM is really outstanding in the ability to hook into any running Java program and see what is going on – with the ability to also do the same to remote JVMs too (although not to the profiling resolution).
Plus, technologies like Google Web Toolkit (GWT) bring sanity to web development. The only cross-browser issues you have to deal with are CSS issues. It doesn’t matter how many versions of Firefox will be released this year, since GWT will sort it out for you.
Sorry, Java is neither slow, nor particularly memory hungry (roughly comparable to .NET apps), nor ugly. You do have to know something about what you are doing though.
This is why places like Tiobe put Java as the single most popular development language (still!). The simplicity of the language and the breath of its libraries are huge advantages that no language looks close to tipping. Many people hate Java since it isn’t ‘l337’ enough for them, but for those that just wanna get stuff done (no matter what the platform) then it is kick-ass.
ps. Check the numbers at the Tiobe Index at:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
or, Programming Language Popularity at:
http://langpop.com/
Edited 2011-07-11 05:36 UTC
Agreed.
The problem with many Java developers nowadays, or any developer for that matter, is that they do not know how to code.
I still remember the hard times to fit programs in 64KB segments.
Many people nowadays code without regard to program efficiency, thus leading to the general feeling that language X is slow.
I think it is because that is what they teach at school nowadays and that is why it is used as much.
I don’t know if it is a good teaching tool. But I’m not impressed, to say the least, about the programming abilities of the people that do graduate and the programs they create.
** groan ** … not this really …
GWT actually makes web dev harder IMO … jQuery is far quicker and easier to learn and is tested much more throughly … and you still need to know JS when using GWT anyway so you might as well learn JS.
Edited 2011-07-11 09:05 UTC
There is only one way jQuery is easier than GWT, if you use Node.js on the backend.
Otherwise, jQuery is rather easy way of developing the JS based UI. Interacting with the server side is still easier with GWT.
Edited 2011-07-11 09:28 UTC
is it really that hard to do $.ajax ?? … how is GWT any easier in this regard?
Neither JSON nor XML are native structure formats for most programming languages. GWT hides that exceptionally well.
Except they both work well with … JavaScript.
JSON is Javascript … and dealing with XML isn’t exceptionally hard.
What didn’t you understand in my comment that jQuery with Node.js is better than GWT? Other than JavaScript JSON is non native to all programming languages.
And “isn’t exceptionally hard” is not a counterpoint to “no need to”.
I ignored it because Node.js while very cool it isn’t commonly used.
Pretty much every language commonly used for web development has a mature serializer, deserializer.
Instead you have to write a ton of classes in Java which you do anyway in C#, PHP, Ruby or whatever.
Most of the front end code is exactly what you would write in JS anyway … so I forgive me if I don’t really see the benefit of GWT.
Edited 2011-07-11 22:07 UTC
I’ve installed NetBeans and Eclipse in Windows, Mac and Linux and, though NetBeans and Eclipse UI performance is quite similar in Windows and Mac, in Linux I find NetBeans evidently slower than Eclipse. Do not know if Swing does some hardware acceleration in Linux, but in my Linux box, it does not perform as well as in Windows or Mac.
It will be because the 3D graphics drivers on Linux may not be as good as on the other platforms.
What UI are you using for Swing? The GTK look and feel is very slow, as Java is forced to work around GTK’s lack of transparency by drawing each widget twice, once on a black background and once on a white background, then downloading the images from the X server, mixing them to recover the transparency, and finally uploading the recovered image.
NetBeans in my Gentoo starts using the default Metal LookNFeel.
I thought Oracle was supposed to take over making the Mac builds with Java 7, but I see nothing. Maybe they have to wait for Lion?
It is still ongoing,
http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port+Project+Status
So “not even close”. Thanks for the link tho, good info.
Wow, that page says a lot. Now I understand why It took Apple months to patch vulnerabilities. Mac OSX JSE had quite a bit of apple specific changes to it. Much more complicated than just applying the Sun patch.