The server maker expects major PC makers soon will begin bundling Sun’s software for running Java programs on their computers.
Sun Plans to Get Java on PCs
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Sounds good.
Finally we might be able to see some more Java stuff out there…
But it has taken a couple of years…
I can’t help but think that this is a good thing. My guess is that within the next few years, we’ll be seeing more and more applications written in .NET making their way onto mainstream PCs. If Java is to survive anywhere outside the server room, then I think that the VM needs to be in place on consumer PCs. With SWT being so much faster and smoother than SWING and more powrful than AWT, now more than ever it seems feasible to have cross platform GUI applications.
This is a lot better than Sun’s previous tactics of trying sue their way into Windows. It was a “if we can’t beat ’em, lets sue ’em” tactic which is just pathetic (*cough* SCO *cough*). But if they can convince OEMs that including the VM is a good thing, then I’m all for that. It’s still a big download for those who have dial up access, so that’s probably a fairly major hurdle to those who’d like to try some of the excellent Java software out there (jGnash, etc.).
I can feel my computer getting slower already
This next comment goes out to all you gung-ho Java desktop developers out there:
If you have any sort of common decency, stick with native apps, PLEASE!!!!!!!!!
The last thing I want is to have to get a new PC because all my fast native apps have been replaced by dog-slow Java versions. And I don’t give a ding-dong didley if Java makes it easier for YOU to write cross-platform stuff – if you’re going to make (for example) a text editor in Java, unless it can start up as fast (or faster) than UltraEdit, I don’t want it!
I know that you see .NET as a threat, but I don’t think building apps that run slower than my grandma (and she ain’t got no legs) is the solution. In this instance, might it be possible that the cure is actually WORSE than the disease?
Ask most end users who know what Java is (and who don’t have political agendas) what they think about Java based on what they’ve seen so far, and see what kind of answers you get …
If a native app is better than a Java app, then it will not be replaced. This is just one more option, not one less.
SUN really needs to develop or license a shared memory VM like apple has. This is the only way to reduce startup times to an acceptable limit. And they need to reduce the cache consistency issues created by the absense of value types. If they do that, java desktop applications might become viable. But .NET is still much better designed. It would win the competition for the desktop even without the monopoly power of microsoft.
“Native” apps will become a niche product in the next five years. And the perception that native apps are nessecarily faster than apps using a runtime is definitely false. This perception is largely created by the inappropriate* design of the java bytecode.
The question is which runtime will be the dominant one? The java VM, .NET or an outsider like the parrot VM? I think that .NET will win. It is much better designed than the java vm and has microsofts support. The only technical thing I do not like about it is the absense of first class functions for functional programming languages. But at least they have a tailcall.
*The design of the java bytecode is fine for small embedded devices, but it is very hard to JIT-compile into efficient native code.
“And the perception that native apps are nessecarily faster than apps using a runtime is definitely false.”
However the experience of slow VM applications has been backed up with benchmark results a hundred times. And it is not only about speed but memory consumption too which is nothing but enormous at least in the case of the two most popular VMs — Java and .NET. Naturally a compiled program without runtime is faster and more memory friendly than a program running inside of a VM. Maybe the difference could be reduced quite a lot but the current major VMs are *very* slow and huge.
i keep hearing comparisons between .net and jvm. i wasnt aware .net is a cross platform environment.
Take a look at this paper: <http://www.hpl.hp.com/techreports/1999/HPL-1999-77.pdf>
It is about Dynamo, a VM for hp pa-risc code that runs on a hp pa-risc machine. By using runtime profiling information, this VM manages to execute native binaries *faster* than if they were running directly on the processor. It is really quite amazing. This proves that VM based languages can be faster than native code if the machine code is well designed.
Another successful example of code running in a kind of VM is the transmeta processor. It basically runs the x86 code in a VM and JIT-compiles it to a VLIW instruction set. Despite the bad design of the x86 machine code, it gets more mips per watt than native processors.
You are right about the memory consumption though. Runtime code translation has a memory overhead. But if this memory overhead of a few megabytes is shared by all processes like on the transmeta processor, on the mac java vm or in .NET, it is not a big deal.
Memory consumption in .NET is much less than in java. Of course you have the overhead of the runtime, but 20 to 30 megabytes shared by all .NET applications is not a big deal. If it is 20-30 megabytes *per application* like in sun java, it sucks.
The performance of .NET is already close to C++, and it will get much better when they do more aggressive inlining and optimization. You can decrease the startup times for .NET programs by precompiling them during installation. Unfortunately this is not supported by the java vm.
.NET technically is a cross-platform environment. If the microsoft version of .NET runs only on windows, that is a political decision by microsoft. But the mono project is making nice progress, so at least the ECMA part of .NET will be cross platform wether MS likes it or not.
And the perception that native apps are nessecarily faster than apps using a runtime is definitely false.”
However the experience of slow VM applications has been backed up with benchmark results a hundred times.
Yeah, and the fact that I have never seen any app running on a VM that ran effeciently either.
tuttle pointed out some examples of VMs that seem to be able to get the job done, so let’s use something like those and kick Java to the curb.
The question is which runtime will be the dominant one?
Um, I bet the majority of people who aren’t programmers would vote neither. If programmers are going to insist that their apps be cross-platform, then please don’t make the end users suffer because you’re too fucking lazy to come up with a C++ solution, or something else that doesn’t suck.
I think the average user could not care less wether the programs he uses are written in java, c# or C++ or assembly. He just wants programs that look nice, start in seconds and react instantly. It is impossible to write such programs in java using swing, but it *is* possible to write such programs in c#, c++ and even python with qt bindings.
This will certainly break our ClearQuest systems at work 🙁
You see, it was designed with Microsoft Java in mind, hence it doesn’t work with Sun Java.
Where I work Java programers are in high demand (big company 100K+ employees). In my area the java programmers are writing high reliability embedded apps in java which allows us flexibility in our HW (and OS) platform selection. We can write the user interface and refine the task flow before locking down the physical platform. Great stuff and highly efficient now. It took a little investment in time and tools development in the begining but now we have sooooo much better flexibility at the midpoint of our project that it is really paying hugh dividends over the previous methods used.
We are tweeking the user interface now to allow the move to handheld devices running a Java VM in the future. The smaller screen space is a challenge but it looks like with a little creative redesigning we will be able to pull it off although it is not a done deal. We will have a new tool available which will allow diagnostics to be run wirelessly on our embedded devices. The bulk of the code resides on the handheld while the embedded device remain streamlined and stable. Diagnostics will be running mostly on the PDA and will be able to refined and improved over time (on the PDA) without touching the embedded device.
“Native” apps will become a niche product in the next five years.
I suggest you read http://www.joelonsoftware.com/uibook/chapters/fog0000000061.html on why failure to use native widgets is a major barrier to application acceptance.
And the perception that native apps are nessecarily faster than apps using a runtime is definitely false.
This is an imperical observation easily accessible by anyone. Running a language in a virtual machine is slow.
This perception is largely created by the inappropriate* design of the java bytecode.
No, it’s created by the weight of having a run-time environment.
It is about Dynamo, a VM for hp pa-risc code that runs on a hp pa-risc machine. By using runtime profiling information, this VM manages to execute native binaries *faster* than if they were running directly on the processor. It is really quite amazing. This proves that VM based languages can be faster than native code if the machine code is well designed.
Except profiling can be done on compiled code as well. ICC supports profiling, and gcc is getting support for it as well.
You are simply kidding yourself if you believe that a program executed within a runtime environment can be faster than code executed outside of one, simply because the runtime environment itself is fettered by the same constraints as the “natively” compiled application, and these constraints are vested upon the program running within the virtual machine as well.
Darius
Are you that sure you never used a VM when you thought it was native. Remember long before Java came on the scene the C compilers from MS no less allowed different parts of the Windows app to be compiled either native x86 or Pcode (may have been slightly different). Look in your older VC IDE, I don’t know if its still there in VC6 but it was there in VC1-4 I am sure.
So many Windows apps including the early MSWord IIRC used Pcode for the GUI part and x86 for the high speed stuff. This might also explain why it was fairly easy for MS to have Mac versions of many of their apps, just a different VM + 68K code. Ofcourse the Pcode eventually called in Win/Mac libs written as native. Now I consider that to be both elegant, & practical. Not much loss in speed overall and a much smaller .exe file.
If Java & .Net were to allow that up front then that would be fine too. I also believe that for very carefully designed languages VMs can appear to be faster than native since they are by definition calling precanned code sequences while decoding the vm codes as they go, as long as most of the vm ops do alot.
If a program is entirely vm code, then it likely to go slower since most statements are usually tiny, but selective use for calls on big ops that are rarely called (GUI) is optimal. Its the 80-20 rule.
What beats up Java is that it is endless. If I write C code, even C++, I can quite easily trace through the asm code to see roughly how big it is. Not so for Java. Also it is the hidden use of New that also kills Java. Since C++ apps force the developer to think through mem management, every New/Delete is accounted for. Not so in Java.
If I am writing in Java, I would check to see if New is called for things I wouldn’t expect and try to program in a way that all New calls are accounted for and reasonable. Only then can Java get close to C++. But I admit Java threw up bigger road blocks than that so I rarely use it, but I still like it (when its fast).
IIRC Early versions os VB didn’t compile the code natively, it wasdone in Pcode.
That would make the installed base of Win apps that used a VM pretty big indeed given the huge no of VB devs.
Did VB later go to mixed code or just go full native? (Prev .Net)
VB 5.0 and greater allow you to compile to either p-code or native.
There is an MSDN article dated 1992 that provides a desciption of MS P-Code entitled: ‘Microsoft P-Code Technology’
What about the potential money than Sun have loose due to Microsoft unfair monopoly during last years? And what about the clients than have decided not to use Java due to it Windows lack of support. Is Sun going to demand this money to Microsoft?
All this talk of MS inplemented .Net services just make me shiver. Here we have people making MS sound good yet we all know that once MS get’s a hold of the market they will totally bash all competition out the way and have the public more tied into their systems. I just hope this doesn’t become the case but I must admit at the moment Java apps suck from an end user point of view. Bloody slow and clunky, makes my Dual AMD system feel like a 286.
W00t – whould give LWJGL a better chance (Hardware accelerated Java Game toolkit for java)
http://java-game-lib.sourceforge.net/
“@Darius
By tuttle (IP: 81.210.153.—) – Posted on 2003-03-29 22:32:13
I think the average user could not care less wether the programs he uses are written in java, c# or C++ or assembly. He just wants programs that look nice, start in seconds and react instantly. It is impossible to write such programs in java using swing, but it *is* possible to write such programs in c#, c++ and even python with qt bindings.”
i agree with you Dariu.
Sun wants java to succeed for Sun. Java is way too overhyped. Am i right or wrong, Sun pushes java hard for it’s servers ?
If you want to see everything java should be.
http://www.rapideuphoria.com/index.html
How much do you know about euphoria? I read quite a bit in their reference material, but I couldn’t find anything regarding objects, and I also don’t care at all for the syntax.
Those two things aside, I’m curious how this differs from languages like Python; and what benefits, if any, it has over languages like Python.
Using wxPython as your graphic toolkit you can write Python applications that have a native Windows, GTK, and Motif look depending on what system you run the program on (I mean real native look, not the Java “native look”). While I don’t particularly care for the way Python implements object orientedness, I find Python very useful and a lot faster than Swing apps (Java apps using other toolkits run much better of course).
Can Euphoria utilize various toolkits? Does it support a native look (their demos try hard, but don’t quite get the job done)? I’m just curious to know why Euphoria is what Java should be.
>I suggest you read >http://www.joelonsoftware.com/uibook/chapters/fog0000000061
>.html on why failure to use native widgets is a major
>barrier to application acceptance.
I did not say anything about native *widgets*. .NET with Windows.Forms, Mono with gtk# or qt#, java with swt or cocoa and python with wxWindows are all examples of VM based languages using native toolkits.
>Except profiling can be done on compiled code as well. ICC
>supports profiling, and gcc is getting support for it as
>well.
I am not talking about normal profiling. I am talking about runtime profiling. For example if you have a branch, it is often impossible to determine which branch is taken more often without seeing the program run. A JIT compiler that does runtime profiling would analyze the behavior of the branch while the program is running and recompile it in such a way that the branch that is most often taken runs fastest. Given the heavy losses modern processors with deep pipelines have when mispredicting a branch, this makes a huge difference.
>You are simply kidding yourself if you believe that a
>program executed within a runtime environment can be
>faster than code executed outside of one, simply because
>the runtime environment itself is fettered by the same
>constraints as the “natively” compiled application, and
>these constraints are vested upon the program running
>within the virtual machine as well.
This would be the case if the program would be *interpreted* by the runtime environment and thus would really run *inside* the runtime environment. But modern runtimes do JIT-compiling, and when they are finished with it, the program runs directly on the processor without any intermediate layer.
This discussion reminds me of the discussions when C++ was new. People used to argue that C++ will never be as fast as C since it has all this neat extra stuff. It took some time to write really efficient C++ compilers, but nowadays a good C++ compiler produces remarkably efficient code.
I am not talking about normal profiling. I am talking about runtime profiling. For example if you have a branch, it is often impossible to determine which branch is taken more often without seeing the program run.
You obviously have no idea how profiling works.
With profiling, you execute a program, and it is analyzed at runtime. Its run-time profile is then generated, and the program can be recompiled with the profile information so that it is better optimized. It’s the same process you’re describing for p-code, except there’s no nasty VM hampering execution.
Here’s a good article on Aceshardware, discussing the differences between static(languages like C++) and dynamic (Java) compilation. Its a little old, but the results are still more or less the same with the latest version of GCC, MSVC and Sun JVM. http://www.aceshardware.com/read.jsp?id=153
With profiling, you execute a program, and it is analyzed at runtime. Its run-time profile is then generated, and the program can be recompiled with the profile information so that it is better optimized. It’s the same process you’re describing for p-code, except there’s no nasty VM hampering execution.
Are you saying that GCC then automatically takes that profiling information into account, and generates runtime code that mirrors it? Does it de-virtualize function calls? If it does, how do I enable it?
One thing that HotSpot is very good at, is optimizing away virtual function calls. That is something that I have yet see a static compiler do.
Um, I bet the majority of people who aren’t programmers would vote neither. If programmers are going to insist that their apps be cross-platform, then please don’t make the end users suffer because you’re too fucking lazy to come up with a C++ solution, or something else that doesn’t suck.
The majority of people don’t really care what language something is written in. If it works, reasonably fast, then cool.
I know 2 very frequently downloaded application that are written in Java. (LimeWire and Morpheus, not that I approve of their use
The only barrier to Java being widely used on the desktop is the lack of VM sharing, and the dog ugly Swing look and feels. *ugh* I have nightmares about Metal.
Java is a great language. And, given the fact it runs on a VM, it actually runs quite fast.
The issue isn’t the language. It’s the VMs. And, to be truthful, I’d rather run a VM so I can program once, run anywhere (As the saying goes) rather then have to retool it, or be stuck on one platform.
http://www.gaffer.org/ptc/distributions/Java/ptc.html
This is a gfx lib for various platforms including Java. It’s very good.