Slashdot Mirror

No, it isn't. Don't just brainlessly repeat marketing blahblah, neither MS's nor anybody elses.

In any place where a run-time behaviour plays a part, the specific implementation/design choices of the run-time environment, and its dynamic semantics, are quintessential.

There is no single runtime to host the wide scope of run-time semantics of the various programming languages. Being able to use the superficial syntax to get something running does not mean that you're using that particular language. More is involved, and the CLR does NOT provide an abstract runtime-environment, and all possible designs and implementation choices for it.

Have a look at the runtime semantics for a few languages -- Python, Java, C++, Objective C, Smalltalk, Common Lisp, C#, for example.

And then have a quick glance at "One Runtime to Bind Them All".

>The one good thing I've seen in all of this so >called ".NET" is the language-agnosticism technic.

As reported here on slashdot

Playing with the .NET SDK, the cross-language support looks impressive, but the illusion holds true only until realizing that all languages in the mix are virtually identical. Microsoft has actually invented the concept of skinnable language : changing a language[base ']s most superficial aspects, and claiming the result to be a new language. There is only One True Language that is C#, and "skins" offered by Microsoft and third parties. Just like in GUIs, these skins will alter the system[base ']s look and feel, add a few features, but never compete with a fully new toolkit.

And you're ignoring the fact that .NET doesn't magically make the object model compatible -- it basically forces apps to use the C# object model. The ars article gets fairly caught up in the marketing that Microsoft has put out on .NET, without addressing the limitations inherent in MSIL. For the other side of the coin, you should read http://www.javalobby.org/clr.html, which is the perspective on .NET's components marketing claims from the perspective of a Java engineer. It is, of course, biased, but he does have good technical arguments.

When your friends ask, just tell them "It's a language-neutral Java knock-off..."

"but 'beats visual C++' ? firstly - what is that? you mean C++ (why should the ide affect benchmarks!?)."

I'm not sure I follow you. You can't debate the performance of languages without referencing specific compilers, since by definition a language doesn't perform without a compiler (or interpreter or VM or whatever). MS Visual C++ is a good choice for comparison, because the vast majority of commercial applications were compiled with it.

According to the Java Performance Report, the IBM JVM beat VC++ in a variety of standard benchmarks. These aren't artificial "allocate a million objects" benchmarks; they're things like neural nets and FFTs which are actually done in real life. Go read the report.

It's worth noting that the Intel C++ compiler did a lot better, but the fact is that if Java is better than Visual C++, it's good enough for the masses considering that the masses are happy with Visual C++. (Remember that GCC sucks ass performance-wise, and most Linux fans are perfectly happy with it).

The page below has an interesting discussion of why the implementations of many languages on .NET will be just C# with a new "skin"

http://www.javalobby.org/clr.html

Of course, I haven't checked the facts, so it could just be FUD.

For a discussion of this, you can check a detailed discussion which has just appeared on javalobby. Be aware that the author is a staunch Java advocate, but I think it's interesting anyway...

"The problem with the Java VM is really that it's written to run Java, and Java only. All features and optimizations are geared towards this. For a few languages that turn out to have much the same features, it is doable, but for other languages it results in some incredibly ugly - and slow - hacks. CIL:s advantage is solely - but importantly - that it's designed to accomodate multiple languages (sort of the difference between a FORTH processor or signal processor and a general-purpose CPU). "

But the CLI is also a hack!
Check out why (or just replace java with c# in the above rant...)
http://www.javalobby.org/clr.html Not truly objective but the facts still aply - CLI is heavily optimized for C# and no other language.

Yes, that's exactly what it is. I think you are misinterpreting the article. The author is trying to say that runtimes can only be optimized for one language, and that the .NET stuff will not be any better at running other languages than the JVM is.

I don't know if that is true or not, but don't try to pretend this article is saying that the JVM is better in some way. The only problems that the author has with the CLR is that (1) it is by Microsoft, and (2) Microsoft is (according to the author) lying about the CLR's capabilities to be cross-langauge.

-Mike

Good article on this appeared today:
One Runtime to Bind Them All

Some quotes:

The reality looks much darker instead. The CLR is not truly language-neutral, and it will ostensibly favor languages that look a lot like C#. Those not in this group will be severely bastardized, producing dialects which are really "C# with another syntax"; look at ISE's Eiffel# (or even Microsoft's own VB.NET and J#) for great examples. Programmers' choice will be limited to superficial features: whether to delimit their blocks with curly braces, Begin/End or parentheses. It's also worth notice that the CTS/CTS do not allow use of the full set of CLR features; for example, unsigned integers are supported by the CLR but not considered language-neutral, simply because many languages share Java's abomination for the signed/unsigned duality (this includes Microsoft's own VB) and there's no good solution for this issue.

-cut-

Playing with the .NET SDK, the cross-language support looks impressive, but the illusion holds true only until realizing that all languages in the mix are virtually identical. Microsoft has actually invented the concept of skinnable language: changing a language's most superficial aspects, and claiming the result to be a new language. There is only One True Language that is C#, and "skins" offered by Microsoft and third parties. Just like in GUIs, these skins will alter the system's look and feel, add a few features, but never compete with a fully new toolkit.

Osvaldo Pinali Doederlein.
The Java Performance Report - Part IV: Static Compilers, and More. August, 2001

The Java Performance Report is an independent study of Java performance, where both virtual machines and static compilers are evaluated. Part IV compares Excelsior JET and two other static compilers with Sun's HotSpot Server VM.

Volano, LLC.
The Volano Report. Dec 26, 2001

The Volano Report covers VolanoMark(tm) - a widely recognized pure Java server benchmark characterized by long-lasting network connections and high thread counts. This report includes Excelsior JET a native compiler.

Excelsior JET Benchmarks

From Caffeine and SPECJVM through XML Transformations to Java2Demo and VolanoMark.

One of the best articles on native compilation is this performance report

Also see on Javalobby the The "native compilation" myth and RFEs for JDK1.5 threads which discuss native compilation.

Yes, there are some companies like Jet and Jove (and GCJ) making native compilers, but I'd like to see a company of the clout of Sun (or IBM) make native Java compiling more accessable by having a "javac -native" option with their JDK and a smaller standardized runtime (instead of the full JRE) specifically for native compiled apps. The most likely target for native compiled apps running w/o a JVM would probably for the client/desktop side which don't have the resources of server boxes. Remember... it would be an OPTION in the JDK... the old bytecode compiling for VM/JIT would still be there.

It's arguable whether the runtime performance of a native compiled app would be substantially better than JIT compiled (if some of the Hotspot tricks were moved upstream into the JDK compiler?), but there are also other advantages, such as a faster startup time (no need to startup a VM processes and JIT compile) better memory usage (no need for VM process as well as the meta data and bytecode which must be held in memeory). There would also be some drivespace savings as the full JRE wouldn't be needed (though at this time, a developer can't include a partial runtime, Sun wants the full thing if they include one... Sun needs a change of heart and make a standardized smaller runtime for native apps). Also, with native binaries an obfuscator (used for btyecode classes) isn't needed for commercial apps for those who want to keep their code proprietary.

There are lots of suggestions going around for the VM/JIT issues such as loading the VM at bootime, a singular shared VM, and JIT caching. These workarounds aren't neccesary with JVM-less native compiled apps.

Of course, there are WORA extremists who don't like this idea of native compilation because it goes against the dogma of only needing to compile ONCE and run on any OS with a JVM. IMO, as long as the source stays the same, compiling natively for different OS's is still pretty near to the WORA ideals. The Java language is VERY tweaked for portability as-is. It's the OPTION of native compiling that should be available in the Sun or IBM JDK.

One of the best articles on native compilation is this performance report

Also see on Javalobby the The "native compilation" myth and RFEs for JDK1.5 threads which discuss native compilation.

Yes, there are some companies like Jet and Jove (and GCJ) making native compilers, but I'd like to see a company of the clout of Sun (or IBM) make native Java compiling more accessable by having a "javac -native" option with their JDK and a smaller standardized runtime (instead of the full JRE) specifically for native compiled apps. The most likely target for native compiled apps running w/o a JVM would probably for the client/desktop side which don't have the resources of server boxes. Remember... it would be an OPTION in the JDK... the old bytecode compiling for VM/JIT would still be there.

It's arguable whether the runtime performance of a native compiled app would be substantially better than JIT compiled (if some of the Hotspot tricks were moved upstream into the JDK compiler?), but there are also other advantages, such as a faster startup time (no need to startup a VM processes and JIT compile) better memory usage (no need for VM process as well as the meta data and bytecode which must be held in memeory). There would also be some drivespace savings as the full JRE wouldn't be needed (though at this time, a developer can't include a partial runtime, Sun wants the full thing if they include one... Sun needs a change of heart and make a standardized smaller runtime for native apps). Also, with native binaries an obfuscator (used for btyecode classes) isn't needed for commercial apps for those who want to keep their code proprietary.

There are lots of suggestions going around for the VM/JIT issues such as loading the VM at bootime, a singular shared VM, and JIT caching. These workarounds aren't neccesary with JVM-less native compiled apps.

Of course, there are WORA extremists who don't like this idea of native compilation because it goes against the dogma of only needing to compile ONCE and run on any OS with a JVM. IMO, as long as the source stays the same, compiling natively for different OS's is still pretty near to the WORA ideals. The Java language is VERY tweaked for portability as-is. It's the OPTION of native compiling that should be available in the Sun or IBM JDK.

One of the best articles on native compilation is this performance report

Also see on Javalobby the The "native compilation" myth and RFEs for JDK1.5 threads which discuss native compilation.

Yes, there are some companies like Jet and Jove (and GCJ) making native compilers, but I'd like to see a company of the clout of Sun (or IBM) make native Java compiling more accessable by having a "javac -native" option with their JDK and a smaller standardized runtime (instead of the full JRE) specifically for native compiled apps. The most likely target for native compiled apps running w/o a JVM would probably for the client/desktop side which don't have the resources of server boxes. Remember... it would be an OPTION in the JDK... the old bytecode compiling for VM/JIT would still be there.

It's arguable whether the runtime performance of a native compiled app would be substantially better than JIT compiled (if some of the Hotspot tricks were moved upstream into the JDK compiler?), but there are also other advantages, such as a faster startup time (no need to startup a VM processes and JIT compile) better memory usage (no need for VM process as well as the meta data and bytecode which must be held in memeory). There would also be some drivespace savings as the full JRE wouldn't be needed (though at this time, a developer can't include a partial runtime, Sun wants the full thing if they include one... Sun needs a change of heart and make a standardized smaller runtime for native apps). Also, with native binaries an obfuscator (used for btyecode classes) isn't needed for commercial apps for those who want to keep their code proprietary.

There are lots of suggestions going around for the VM/JIT issues such as loading the VM at bootime, a singular shared VM, and JIT caching. These workarounds aren't neccesary with JVM-less native compiled apps.

Of course, there are WORA extremists who don't like this idea of native compilation because it goes against the dogma of only needing to compile ONCE and run on any OS with a JVM. IMO, as long as the source stays the same, compiling natively for different OS's is still pretty near to the WORA ideals. The Java language is VERY tweaked for portability as-is. It's the OPTION of native compiling that should be available in the Sun or IBM JDK.

Here is how Rickard Oberg, creator of JBoss, avoids worms through use of EJBs.

Click here to read the highly controversial views of Rickard Oberg, creator of the free EJB container, JBoss. Tell me if you want to use his code again.

"There is no need for a virtual machine?"

This sort of quote sounds very much like you read it off the net in some opinion piece somewhere, because it's meaningless and you offer no support for your assertion.

Let's see how you'd define Java without a virtual machine. Firstly, we'd assume that we'd not want to give up any of Java's features or 'niceness', because after all if there's no "need" for a virtual machine it implies that we can eliminate the VM without compromising anything.

So let's enter an alternate universe in which javac just produces a native executable file. Fine and dandy. Unfortunately, we immediately hit a few snags. How do applets work? Applets are distributed to whatever machine requests them, so unless you already have a compiled version you just can't do it. Hmmm. What about security? Java is a secure language, meaning that untrusted code running in the sandbox can't cause meaningful harm to your computer. You can't make that guarantee about an executable.

What about Web Start, which distributes code to different computers? That will be a problem too. How about a program which requests a few classes from elsewhere? Same thing.

Okay, so scrap that idea - clearly we'll have to give some things up. So instead of javac only producing executables, we'll change it to instead produce an intermediate format, and then have it automatically translated into the final representation as soon as we know what that representation is. Well, guess what, genius! VMs have been doing exactly that for five years.

"VM's are always going to be slower than native code. If you want a cross platform language, implement the cross platform ability at compile time rather than at run time"

Check out the Java Performance Report, in which Java delivers MS Visual C++ a thorough spanking. (Disclaimer: it does lose to Intel's compiler, but gcc isn't anywhere as good as Intel's)

The Slashdot community, at least, should be smarter than this. Never, ever say that technology A will never beat technology B without a mathematical proof of its limitations in hand.

Speaking of templates...

This argument is fruitless, both sides can produce specs to "prove" they are faster. For example here is one showing Java as faster:

Benchmark here

I am sure there are a boatload of tests out there which "prove" just the opposite. The plain truth is that this really isn't an area where there is a definitive answer. Sometimes one is the better and faster tool, sometimes the other is. For those of you who seem to feel that the only way to get speed is to statically compile something (a la c/c++), you might want to have a look at an alternative approach. The following link goes to an article which outlines a different way of measuring the benefits and drawbacks of the static compile vs. VM speed question.

Dynamo

The Java byte code really isn't all that slow. In fact, making the VM smaller would actually probably make it slower since you'd be leaving out things like a JIT or any sort of optimization. Generally speaking, there is a compromize between speed and size - large usually is faster (optimized for speed), smaller usually is slower (optimized for size).

The JVM itself is a nice speedy little thing. It's not slow. It's the Abstract Windowing Toolkit (AWT) that's slow! Since almost all Java apps require some form of GUI interaction, and the AWT is the means of graphical interaction, the AWT becomes a signifigant bottleneck. If Sun spent some time on speeding up the AWT, all those pretty graphical Java apps would receive a nice speed boost.

Even with the JIT turned off, Java bytecode alone usually runs at a decent clip. Unfortunately for Java applications, the AWT is very slow - it actually became slower in JDK1.2 and is picking up some speed in JDK1.3 (it hasn't regained it's JDK1.1 speed though).

If anyone wants to read a more indepth benchmark comparing x86 C with Java code, try here.

The really sad part about the resistance to Java is that the excellent work of the Blackdown Project, Kaffe and projects like Java Gnome seem understaffed, yet Linux is one of the best platforms for running Java. Linux as a platform beats out most other platforms (like Solaris and NT), as seen in the latest Volano Report. And Java as a language keeps getting faster vs. C all the time. If Sun would finally realize Java is bigger than they are, Java would finally get the recognition it deserves.

And in closing, Java on Linux is dope.

F.O. Dobbs
Portal-Potty Founder and Mr. Brown drinker.

But I think neither COM nor CORBA are the answer. COM and CORBA are both rather complex systems because they are trying to patch up deficiencies in the underlying languages, C and C++. In an environment that encourages reuse, you should be able to just serialize and send objects to other components without lots of error-prone declarations. Such systems exist, and have existed for decades. But you simply can't build them reliably on top of C/C++.

Ten years ago, Objective-C was a pragmatic and efficient answer to that problem. Objective-C is simpler than IDL and gives programmers more power. Today, the obvious answer would seem to be Java, although even it is still more complex than it probably ought to be.

While I appreciate the short term utility of Gnome, I think in the long term, the effect of the Gnome project (and KDE, for that matter) is going to be harmful. It continues to encourage people to develop in and for an environment that is fundamentally not well suited to building software components and getting a lot of code reuse.

If people want to do something relevant for end users in an industry-standard environment, I think they should contribute to Java-based desktop application efforts. The Gnome programmers are smart and capable: if even a fraction of the Gnome effort went into open source Java implementation (e.g., kaffe) and Java desktop apps (e.g., JFA), we'd soon have a good environment that would be much easier to extend with new components than a big C/CORBA system.

Some comments on the article:

Limbo avoids the complex object-oriented features of C++ but has more basic types - lists, strings, tuples, etc. - and programming concepts - threads, communication channels - built into the language.

• basic types: lists seem to be the ArrayList in Java, strings exist as instances of the class String. I don't know what a tuple is though.
• programming concepts: Java threads seem to be build in the language, just take a look at the class Thread/.

Also, the collector reclaims memory as soon as the last reference is released, to minimize the memory needed for execution.

Isn't that called reference counting? Something that compromizes execution speed.

Coupled with Limbo's `instant free' property, this eliminates the need even to write special free routines, let alone call them.

Yes, garbage collecting (or reference counting as I said before).

and a few comments to the poster:

Face it, Java was "designed" for appliances, then, made to work for applets and now, we're to understand it's just perfect for server side programming and practically made for XML. Give me a break.

Unix/Linux was designed for servers, then, made to work for the desktop and now, we're to understand it's just perfect for embedded devices.

We'll see... Too little, too late? I don't think so. Despite all the feverish development going on with Java, what real impact has it had? How many people really use Java in production systems today?

At the bottom of the article it says "Since we plan to provide Java support, Inferno is more a complement to Java than a competitor with it. ". The author doesn't seem to think Java's a lost cause.
On a side note: if you want to know how many people use Java, ask on JavaLobby and ask.

---
Besides this, Inferno seems to be really cool! These were just some comments I had to make.

The relevant questions are all about time to market, scalability (hand-helds to mainframes), networking, security, and quality. We should have benchmarks on these. Java would win hands down.

Interested parties should check out the JavaLobby and consider joining. There is a very interesting discussion on JSP vs. ASP performance there now.

• New Atlanta ServletExec 3.0 - I've seen this one used succesfully before, and it was even used for a while with Javalobby.org as a plugin for Apache. It should be platform independant, but it is dependant upon you using a supported webserver (Apache, iPlanet, IIS, etc).
• Orion Server - This is a 100% Java Webserver with built-in support for XML/XSLT/WAP/etc. It also fully supports servlets (of course) as well as JSPs and EJBs. This is the product currently used by Javalobby. Overall, I think that it's a great solution. The performance of this solution is excellent.

• New Atlanta ServletExec 3.0 - I've seen this one used succesfully before, and it was even used for a while with Javalobby.org as a plugin for Apache. It should be platform independant, but it is dependant upon you using a supported webserver (Apache, iPlanet, IIS, etc).
• Orion Server - This is a 100% Java Webserver with built-in support for XML/XSLT/WAP/etc. It also fully supports servlets (of course) as well as JSPs and EJBs. This is the product currently used by Javalobby. Overall, I think that it's a great solution. The performance of this solution is excellent.

Having said that, this reduces the issue down to the simple matter of users knowing that two perl modules are related because they have similar names, while two java classes in the org.java.xml package do have shared visibility.

On the constructive side, take a look at JFA Projects and The Open Source Java Web Ring

Aside from applets, which don't mean much to most people, MS distributing their "Java" does nothing. I think that anyone who really uses Java on Windows (ie, not just applets in web pages) gets it from Sun. MS's VM doesn't support Java 1.2, let alone 1.3 which is very, very nice (makes the GUI run faster among other things). I'd say that with 1.3, Java becomes very feasible for more than "just the server" as some people say Java's future lies. And also, I'd say that Java on said servers has even less influence from MS than Java on the client does.

For some examples of real stuff done in Java, you might want to head over to The JavaLobby and look at the member successes page (a link on one of the pictures in the top left). Everything from games to accounting software to servers has been written in Java with little to no influence from MS, so I hardly think that Sun would "bow down" if MS ended their distribution of their "Java" as you suggest.

I guess not everybody has given up on client-side Java.

RP

If you really want to see what the Java developer community thinks of these issues, check out some of the discussions that went on in JavaLobby last week:

Java and GPL

WORA scorecard

CVS for Java2 Standard Edition - Do You Want It?

I know that for some reason, it's not "cool" to like Java on /., but for those of us who love Java and use it, there's no going back, so we're trying to make the best of what we've got, and what we can get.

If you really want to see what the Java developer community thinks of these issues, check out some of the discussions that went on in JavaLobby last week:

Java and GPL

WORA scorecard

CVS for Java2 Standard Edition - Do You Want It?

I know that for some reason, it's not "cool" to like Java on /., but for those of us who love Java and use it, there's no going back, so we're trying to make the best of what we've got, and what we can get.

If you really want to see what the Java developer community thinks of these issues, check out some of the discussions that went on in JavaLobby last week:

Java and GPL

WORA scorecard

CVS for Java2 Standard Edition - Do You Want It?

I know that for some reason, it's not "cool" to like Java on /., but for those of us who love Java and use it, there's no going back, so we're trying to make the best of what we've got, and what we can get.

I read through the 20 or so comments at JavaLobby. most were against a GPLed Java clone because the GPL allows forking. forking destroys Java's write-once-run-anywhere (WORA) property. these commentators at JavaLobby value WORA over freedom. the best single comment is here. (scrolling up and down brings you to the other 19 or so comments.)

...going on over at JavaLobby, which is where I believe this was first posted.

http://www.javalobby.org/servlet/News?action=displ ayStories&xsl=comm ent.xsl&format=full&id=500400000000620

Deja vu all over again -- the same interview was on javalobby earlier today and I just had to bite on the "incompatible Linux distribution" bait.

I assume that the "incompatibilities" he describes were differences in kernels (2.0.x vs. 2.2.x) and libraries (libc/glibc). If that's the case, I would simply suggest writing for the most recent stable version. It is possible to upgrade kernel and libraries, as we all know. Admittedly, upgrading is a drag -- especially on known-to-be-rock-solid systems. Version control is a problem on every platform, though. Let me tell you about Windows and oleaut32.dll one of these days....

While "Java vs. Linux" does not rank quite as high as "BSD vs. Linux" or "KDE vs. GNOME" on the flamewar meter, it is getting just as tired. More importantly, it is counterproductive to both sides. There is no reason to pick one or the other, either -- Linux works well as a development platform for Java. The only drawbacks right now are somewhat sluggish performance with some JVMs (I saw where IBM's alphaworks JVM actually scored pretty well on the Volano benchmark), and the annoying tendency to be 6-12 months behind the latest version (which may not be a problem if you like waiting for the bugs to shake out first).

I'm going to walk into the flamepit now:

The Java vs. C arguments are also silly. I like C, I use C, C is my friend. If I need to do system programming (OS-level, device drivers, etc.) or anything where speed is absolutely, positively the overriding concern, give me C.

But there is also application development. Here, I want short development time, easy maintenance, and a whole lot of functionality already built in. In this case, Java starts looking really good.

Insert tired "right tool for the right job" cliche here.

The "Java will soon take over" hype from 4 years ago has turned into a huge burden for the language. There are just some languages that do what they do so well that there is no need to replace them with anything (Perl, for instance). Java does have the potential, though, to move into areas where there are still some gaps. I think that Java has tremendous potential in distributed applications, for example. This is also an area where I would like to see BSD and Linux start playing larger roles. The combination will work if the two sides can quit flaming each other long enough to get it done.

Thanks for letting me get that off my chest. Back to work for me, now.

You know, I don't get why so many slashdotters take such glee in "bad" news about Java. I also spend a fair amount of time at the Java Lobby site, and I can tell you that the hostility is not shared.

Every post I see at Java Lobby regarding Linux expresses enthusiasm and praise. Those who use Linux as a platform for Java development (including me) are very happy with it. They want to see Sun loosen their control and they want to see both platforms succeed.

But now, Will in Seattle comes along with a court ruling that says that the original injunction against Microsoft was wrong, but that the case itself has merit. His cute comment? "Abandon ship, all ye Java geeks."

I would love to send Will an email asking him what he has against Java, but I can't. The e-mail link gives me "we.are.lost.at.sea@sun.com". That's cute, but it basically turns him into an Anonymous Coward, just like me. I guess he doesn't have the courage to handle the flames he knows he will incite. Maybe a better solution is to just leave out flamebait comments.

Java 1, Sun 0. A year ago, it was difficult to see the difference between Sun and Java. But now a ruling has been made that's good for Java and bad for Sun, thus making a clear distinction. Anyone interested in this topic should visit the JavaLobby.