Java goes back to the PC (ZDNet) [LWN.net]

ZDNet talks with James Gosling. "In 1995, Sun Microsystems introduced Java as a way to endow Web surfing with fancy graphics and more sophisticated interaction than just basic pointing and clicking. By introducing JavaFX Script this week at the JavaOne conference here, Sun is trying to reinvigorate that original idea. Gosling helped invent the Java programming language, initially called Oak in the early 1990s. He was involved in its early spread as a Web browser plug-in and its commercial success in server software and mobile phones."

to post comments

i'm willing to give it a chance

Posted May 11, 2007 22:08 UTC (Fri) by b7j0c (guest, #27559) [Link] (1 responses)

after years of rejecting client java for performance, stability and licensing concerns, i am considering re-evaluating

and there is a need for re-evaluation. the web stack is a document-centric stack that avails itself to "lite" dynamic and interactive functionality, but it is clear that it is extremely difficult (if not impossible in many cases) to use this current stack to craft tomorrow's multimedia-aware, dynamic, graphical, networked apps. networked apps are going to look a lot more like WoW in ten years than lwn...we need an open stack to get us there and we don't have it now.

the other current choices are silverlight and apollo. at this point the java stack seems like the lesser evil. silverlight-on-mono may at one point change this debate, but for now its just a plan.

i don't care for the javafx script syntax, but i haven't really given it much of a shot. maybe it isn't as painful as it looks. the saving grace is that there are other languages that can be hosted on the jvm, so it appears that at least we have this flexibility for development.

rich apps are going to be the target for the highest-margin ads (multimedia, interactive ads) on the network, so there is a compelling business interest in advancing these stacks.

i'm willing to give it a chance

Posted May 11, 2007 23:11 UTC (Fri) by drag (guest, #31333) [Link]

Well and things like squeak/smalltalk.

But java seems much more established.

Java goes back to the PC (ZDNet)

Posted May 12, 2007 0:44 UTC (Sat) by mikov (guest, #33179) [Link] (21 responses)

This is just silly. What can JavaFX do that Java can't already ? Nothing. It is beyond me why people assume that a scripting language running in the same environment will magically change anything.

Java still starts extremely slow (especially on Windows with a anti-virus installed) and is not pre-installed on most PCs.

Not only that, Java is slow. Don't get me wrong. I program mostly in Java these days and I know all about HotSpot, etc. I spend most of my development time in Eclipse. So, I speak from experience. It is very powerful but it sucks. It is barely usable on anything with less than 2 GHz CPU and 1 GB RAM. Even on much faster machines there are noticeable delays. This is the nature of Java.

The idea that a JVM-based scripting language will fix this is stupid stupid stupid. Just marketing nonsense.

Are we seeing the beginnings of the next bubble ? The "scripting and web 2.0" bubble ?

Java goes back to the PC (ZDNet)

Posted May 12, 2007 1:00 UTC (Sat) by phgrenet (guest, #5979) [Link] (13 responses)

I also spend most of my days with Java (and the rest with C++). From my experience Java is NOT slow; it is quite comparable with C++. In some situations where multi threading is involved it can even beat the pants off C++ (OK, this doesn't happen often, but I have some pieces of code using java.util.concurrent that I dare anyone to get faster in any language).

That being said you are right that it is slow to start, because the JVM is a big program and because it has to compile itself (rt.jar) and then your code. It also uses 3 or 4 times more memory than the equivalent C++ program, and again there are good reasons why.

I don't see Java succeeding in lightweight applications because of this, whether they are on the server side or on the client side.

Java goes back to the PC (ZDNet)

Posted May 12, 2007 1:30 UTC (Sat) by mikov (guest, #33179) [Link] (11 responses)

Well, it is difficult to be objective without concrete benchmarks to compare. One particular benchmark is Eclipse and I swear than on Athlon XP 2000 with 512 MB RAM under Linux it is terrible.

I agree that Java in general is not unacceptably slow. My point is rather than it has fundamental performance limitations (built in the language) which can't easily be overcome, if at all. Still, in many cases the trade-off is worth-while. One must however be aware that he is making it.

I often have to deal with Java in a low power environment - for example a 200MHz x86 embedded CPU with 64 MB RAM (which, come to think of it, is much more powerful than my first machines running Windows NT :-) - and it definitely shows. On that hardware, Java is a pig :-) You can't really run more than a couple of Java applications at the same time. On top of that, whenever their working set reaches above 25-30 MB (which happens often, because it starts at about 10-15 MB, IIRC), the garbage collection times become noticeable.

Here is an example which I always give when people claim that Java is as fast, if not faster, than C/C++. An array of 3D coordinates and code to do a simple transformation - e.g. increase x, y and z by 1. The C version is several times faster even with array range checking disabled. How come ? Java _requires_ a pointer indirection which _cannot_ be avoided for most accesses. So, it exacerbates one of the most serious problem for performance these days - the memory wall.

Java goes back to the PC (ZDNet)

Posted May 12, 2007 2:10 UTC (Sat) by jwb (guest, #15467) [Link] (10 responses)

That computer is just not big enough to run Eclipse. It's not big enough to run Visual Studio, either, and that's written in C++.

On your embedded platform, have you considered using j2me instead of j2se? 64MB of memory and a 200MHz CPU is comparable to the resources available on a BlackBerry or a Nokia N95, and nobody runs full j2se apps on those machines.

There's absolutely no question that C is faster in the type of byte-fiddling applications you are talking about.

Java goes back to the PC (ZDNet)

Posted May 12, 2007 2:42 UTC (Sat) by mikov (guest, #33179) [Link] (4 responses)

That computer is just not big enough to run Eclipse. It's not big enough to run Visual Studio, either, and that's written in C++.

Eclipse is just an example familiar to everybody, that's why I used it. Other Java GUI applications (e.g. ones which I help develop), much smaller than Eclipse, running on the same hardware are also sluggish. Not unusable, but definitely not what I know I can expect from such hardware. On the other hand, Visual Studio 6, for example, just flies. I think most of can it fit permanently in the L2 cache :-) KDevelop isn't bad at all either.

On your embedded platform, have you considered using j2me instead of j2se? 64MB of memory and a 200MHz CPU is comparable to the resources available on a BlackBerry or a Nokia N95, and nobody runs full j2se apps on those machines.

Well, that's the problem, isn't it ? "Full" Java applications are "not meant" for such hardware, and yet, in absolute terms, a 200MHz 64 MHz machine is in fact more than powerful enough. As pure functionality there isn't anything extraordinary in j2se that makes it unsuitable for such a configuration.

Everything, including Java, works well on a Core 2 Duo. It is only in the corner cases like this when the generic claim that Java is as fast as C begins to unravel.

Again, note that I am not saying that it is unacceptably slow. In my case, it actually works sufficiently well, but is obviously not "as fast" as C. AFAICT, the two major culprits are runtime compilation and especially garbage collection times.

There's absolutely no question that C is faster in the type of byte-fiddling applications you are talking about.

What bit fiddling ? :-) Seriously, why do you think that 200MHz/64MB is only good for bit fiddling ? You probably remember that even when HDDs were much smaller than 64MB, people used to run software doing much more than that. Bit fiddling is what we used to do in a 68705 with (IIRC) 64 bytes of RAM :-)

Java goes back to the PC (ZDNet)

Posted May 12, 2007 3:19 UTC (Sat) by b7j0c (guest, #27559) [Link]

look at it from another perspective

apollo, silverlight, and javafx are being marketed as advanced replacements for the web stack in certain application environments.

for example, IM client communication. multimedia playback (and possibly editing). photo collection management.

run any tool like meebo, the flickr editor, or any of the embedded media players and you will see that resource consumption and performance are significant issues. this is the yardstick, not a C-coded matrix manipulation.

Java goes back to the PC (ZDNet)

Posted May 12, 2007 16:38 UTC (Sat) by nlucas (subscriber, #33793) [Link] (2 responses)

On the other hand, Visual Studio 6, for example, just flies.

Maybe because VS 6.0 was the last actually using C++. Latter versions are in C#.

Java goes back to the PC (ZDNet)

Posted May 12, 2007 21:14 UTC (Sat) by Los__D (guest, #15263) [Link] (1 responses)

AFAIK, VS.Net is still coded in unmanaged C/C++, even though it is an IDE for the .NET laguages.

Java goes back to the PC (ZDNet)

Posted May 12, 2007 21:41 UTC (Sat) by nlucas (subscriber, #33793) [Link]

I was going to tell you to go get Process Explorer from sysinternals.com and check that the IDE was a .NET process, but it seems since Microsoft bought sysinternals, ProcessExplorer doesn't allow to select the highlighter for .NET processes (this could give a nice conspiracy theory).

But one thing is probably right: it was probably recompiled/ported in managed C++, not C#.

Java goes back to the PC (ZDNet)

Posted May 14, 2007 5:41 UTC (Mon) by bronson (subscriber, #4806) [Link] (4 responses)

> That computer is just not big enough to run Eclipse. It's not big enough to run Visual Studio, either, and that's written in C++.

Not in my experience. I run Eclipse and Visual Studio simultaneously on my Thinkpad T42p (currently moving computer vision apps from the developers' Windows-based workstations into the cluster's Linux-based compute nodes). Switching from Eclipse's CDT edit to debug perspective is just painful to watch. When I hit F11, it takes over one second of window redraws, chunka chunka chunk, before the debugger is ready to go. 1 sec doesn't sound like much but when you're switching 2-3 times a minute, it starts to add up. It's just enough time that my mind wanders and I sometimes forget what I'm trying to do.

Visual C++, running under VMWare on the same exact machine, switches instantly. F5, *blam*, the debugger is ready to go. No chance to lose focus. And this generally true: Visual Studio respons right away while Eclipse pretty much always at least one heartbeat before showing search results, opening the prefs dialog, etc. (Eclipse is running native)

I'd blame it on poor Eclipse code but NetBeans has this same exact problem. The Java apps that I use just feel tedious, even on my 64-bit 3 gigs of mem screamer. I've already quadrupled Eclipse's heap. Are there any other ways I can try to make them feel faster?

Java goes back to the PC (ZDNet)

Posted May 14, 2007 7:31 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

I'd blame it on poor Eclipse code but NetBeans has this same exact problem.

Have you tried IntelliJ Idea ? I was also sure it's unsolvable problem with Java till I've switched to IntelliJ...

Java goes back to the PC (ZDNet)

Posted May 14, 2007 16:26 UTC (Mon) by bronson (subscriber, #4806) [Link]

As far as I can tell, IntelliJ doesn't support C++? The comments on http://plugins.intellij.net/plugin/?id=1373 don't look promising.

I hope I'm mistaken... I'll try anything at this point!

Java goes back to the PC (ZDNet)

Posted May 14, 2007 17:13 UTC (Mon) by mikov (guest, #33179) [Link] (1 responses)

Thanks for posting! It proves that I am not crazy :-)

(In all fairness, Eclipse, at least when used for Java, does a bit more than Visual Studio, so I personally find the trade-off worth-while)

You mentioned that you have increased Eclipse's heap. Could it be that it is actually hurting performance because garbage collection times are more noticeable ?

Also, you said that Eclipse is running native - I presume compiled with GCJ. In my experience that is a 2x slowdown right there. (GCJ is a great compiler for embedded, but as pure speed it definitely loses to HotSpot).

Lastly, SWT/GTK is known to be slower than SWT/Win32. Unfortunately IBM does not seem a bit interested in fixing that. There used to be a project to port SWT to Fox, with very impressive speed gains, but alas it appears dead now.

Java goes back to the PC (ZDNet)

Posted May 14, 2007 19:14 UTC (Mon) by bronson (subscriber, #4806) [Link]

Bad wording on my part. By native, I meant that Visual Studio is running under a VMWare guest while Eclipse is running on Sun Java 6 directly on the host.

I tried various heap settings. Doesn't seem to make a lick of difference as far as responsiveness. (the boosted settings do allow me to work 6+ hours before a memory leak takes out the 3.3 M7 development build, but for 3.2 it seems to make no difference whatsoever).

Azureus has very poor interactivity too. Yes, SWT bottlenecks sound like a distinct possibility. I expect IBM would respond if enough people complained about this problem. I'll have to scour the Eclipse bugzilla later on today.

Java goes back to the PC (ZDNet)

Posted May 12, 2007 10:51 UTC (Sat) by Cran1988 (guest, #44982) [Link]

Ha ha ha ! Java is slow BUT technology is fast !

Java goes back to the PC (ZDNet)

Posted May 12, 2007 3:18 UTC (Sat) by akumria (guest, #7773) [Link]

Java still starts extremely slow (especially on Windows with a anti-virus installed) and is not pre-installed on most PCs.

I'm not aware of any data about "pre-installed software" and who installs what. Empirically, though, all the HP and Dell machines I've recently bought have had it.

Together they account for if not over 50% of the PC machine, then certainly close to it.

Java goes back to the PC (ZDNet)

Posted May 14, 2007 4:41 UTC (Mon) by jpick (guest, #29470) [Link] (5 responses)

Calling it "JavaFX Script" is just incredibly bad marketing. I understand that they are trying to tap into the Java and JavaScript developer base, but the branding and nomenclature is just confusing.

At it's core, this is just a new declarative language and runtime that sits on top of of the JVM. There is a lot of really interesting development happening in that area. Look at the buzz around Haskell, Jaskell, PUGS, etc.

Getting away from strictly imperative scripting languages is a really important evolution in the way we write code. If an entire problem can be described as a single expression, it pushes the problem down to the compiler to figure out the best way to produce the results. So instead of having compilers that can only do optimizations for little blocks of code, we can start building compilers that understand the whole problem, and produce truly optimal code.

They did their demos with Swing first, which is unfortunate, since nobody really wants to write Swing apps. It's understandable though, since that's probably the easiest thing to get some demos out quick with. This stuff is really going to start to shine when it gets bound to web frameworks and databases and 3D engines, so watch out!

So we're really talking about a higher-level language than just another scripting language, and they're doing it in an open source manner, which is going to enable them to get truly optimal compiler stuff happening on the back-end. I can see 20 years of future development heading down this path...

Apparently, Per Bothner is on the team working on this stuff, so I'm going to watch it very closely. :-)

Java goes back to the PC (ZDNet)

Posted May 14, 2007 7:35 UTC (Mon) by khim (subscriber, #9252) [Link] (4 responses)

So instead of having compilers that can only do optimizations for little blocks of code, we can start building compilers that understand the whole problem, and produce truly optimal code.

Why do we need yet-another-language for this ? Why not write JIT for JavaScript, for example. Even primitive JIT should give you 10 times speedup, perhaps 100 times if you include some more aggressive optimizations...

Java goes back to the PC (ZDNet)

Posted May 14, 2007 15:10 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

It's kind of hard to aggressively optimize ECMAScript for much the same reason that it's hard to aggressively optimize Smalltalk: the method lookup rules and intensively dynamic-at-runtime nature of the beast incur high overheads that can't be eliminated, certainly not for any but the simplest cases (construct an object then use it *right here*).

Java goes back to the PC (ZDNet)

Posted May 17, 2007 9:59 UTC (Thu) by lysse (guest, #3190) [Link]

Actually, what seems to work best for aggressively optimising Smalltalk (and presumably other dynamic languages too) is to take advantage of its dynamism - a simple last-method-called cache at each call site can turn a method invocation into a single unconditional call some absurdly high percentage of the time; at which point it'll comfortable outpace anything based on virtual tables, which have to incur the direct and indirect costs of an indirect function call every single time they're used. And then there are the famous examples of rewriting one's own object code at runtime for a 30% speedup.

It's ironic that a machine which is fast enough to do extensive complex static analysis and optimisation is probably also fast enough to render it quite unnecessary...

Java goes back to the PC (ZDNet)

Posted May 15, 2007 2:06 UTC (Tue) by doogie (guest, #2445) [Link]

Um, there are bytecode compilers for python(jython), javascript(rhino) and php(quercus). In my testing of a simple program written in each of these 3, compared to java, I saw a 2-times slowdown against pure java. I didn't test against the standard interpreter for each respective language.

Java goes back to the PC (ZDNet)

Posted May 15, 2007 3:55 UTC (Tue) by jpick (guest, #29470) [Link]

Javascript JITs are being done (eg. the Tamarin project from Adobe that's going into Firefox). That's definitely a good thing.

But compilers are capable of much more than just generating machine code that runs through processor pipelines at great speed.

For example, sophisticated compilers can be used to automatically generate code with all the necessary stubs and proxies to run as a distributed system. Compilers can generate vectorizations automatically to generate DSP algorithms. Dynamic compilation techniques can employ statistical gathering techniques and control systems theory to tune applications in real time. These things would be very difficult to do by hand without the help of these new compilers.

But for the more sophisticated techniques to really work, they need to have more of a "bird's eye view" of the entire problem space. The new crop of languages have new tools to let programmers describe exactly what the whole problem is in closer-to-human terms, and the computer can be left to crunch the numbers to figure out what the best way to actually implement it actually is. Faster computers mean that our compilers can get really, really, really smart. But programmers are human and slow to learn new things, so it will take quite a few more years for the language side of things to catch up.

Java goes back to the PC (ZDNet)

Posted May 12, 2007 14:40 UTC (Sat) by djabsolut (guest, #12799) [Link]

And also in 1995, Sun Microsystems attempted to make lots of PR noise and create vendor lock-in via Java (tactics usually associated with Microsoft). Oak (the predecessor to Java) was a well intentioned, but a misguided attempt at making a better C, while trying to counteract the perceived issues with the nascent C++ (the rather glaring and deliberate omission of operator overloading in Java is a prime example of the shortsightedness). At that stage C++ wasn't even standardised, and the Sun folks were spruiking Java by saying how much better and "safer" it was than C++. Nevermind that C++ wasn't well understood back then nor that not many people knew what a template was, much less what one could do with them. That said, Java (along with Python et al) did give a good kick in the butt of the C++ folks and made them get out of their glacial pace in evolving the language (mainly in the library department). These days serious application work continues to be done in C++, and the language has changed very significantly since the 1990s (with many thanks to the Boost folks). Calling Java a success is like calling Microsoft Windows a success - it's more of a case of brainwashing enough people in conjunction with enough clout and market pressure.

Java goes back to the PC (ZDNet)

Posted May 12, 2007 22:58 UTC (Sat) by landley (guest, #6789) [Link]

This is a _new_ interview?

Oh companies like Apple say they want user interface consistency, and
sure they sell more units in any recent quarter than sun has in its
entire corporate history, but what people REALLY want is what we were
cramming down their throats ten years ago: skinnability out the wazoo,
ala Swing. Swing was the future, man. Just wait. It's perfectly
natural to require people to master model/view/controller in order to
pop up an "ok" dialog. You'll see.

Nowhere in this article did I notice even a hint that they've LEARNED
anything over the past decade, just continual insistance that they were
right all along and the rest of the world will someday catch up to them.

They're still flogging that dead horse?

Posted May 12, 2007 23:03 UTC (Sat) by alextingle (guest, #20593) [Link] (3 responses)

They're still flogging that dead horse?

A one-trick-pony flogging a dead horse?

Posted May 13, 2007 9:51 UTC (Sun) by man_ls (guest, #15091) [Link] (2 responses)

Gosling is stubborn. Swing has failed in most of the Java application space, not because of the (bad) implementation but because the idea was wrong from the start. SWT has taken over in some popular applications (Eclipse, Azureus), because it is well designed.

Now he wants to start all over again. Skinnable interfaces...

A one-trick-pony flogging a dead horse?

Posted May 13, 2007 21:58 UTC (Sun) by mikov (guest, #33179) [Link] (1 responses)

I am afraid you are wrong about SWT. SWT is not well designed. It is nothing but a thin wrapper around Win32. It is very primitive. It is really exactly on the same level as MFC, including the need to do manual resource deallocation. Unfortunately, unlike MFC, SWT is buggy and incomplete. For example (at least in version 3.1.1), it doesn't actually contain the necessary tools to construct a 100% Java custom control.

As another data point, on the same hardware, SWT/GTK is about two times slower than SWT/Win32. On Linux, Swing is actually faster than SWT. Make your own conclusions.

A one-trick-pony flogging a dead horse?

Posted May 13, 2007 23:30 UTC (Sun) by man_ls (guest, #15091) [Link]

Hmmm, maybe you are right. In any case, at least you can build a decent win32 application with it.

The JavaFX Script Programming Language

Posted May 14, 2007 14:59 UTC (Mon) by tjc (guest, #137) [Link]

Here's a link to some information on the language itself, just in case anyone reading this thread is interested in that sort of thing! ;-)

https://openjfx.dev.java.net/JavaFX_Programming_Language.html