Slashdot Mirror

Would you be so kind to explain to me exactly how many technologies that .net has that makes it a superset of Java? Maybe you haven't investigated J2EE, J2ME and all the other technologies that are part of the Java platform. Besides, Java has a much larger free software community. Freshmeat, for example, lists 2382 Java projects (that's less than 100 frewer than C++). To be compared to the 46 C# projects.

Want to implement a SOAP web service? Check out GLUE. It allows you to distribute any java object as a SOAP service using only 2 lines of code (one to start the server and one to register the object).

And if you don't want to listen to me, why not read this list. It contains some good stuff.

Why people spend their precious time on a project like Mono with such an unstable (legally) base is beyond me. Why the Linux community seem to embrace .net more than java is even more boggling.

First off, any chance you could post those benchmarks? 20 requests/second seems low, I'm wondering what the rest of the setup was.

For the first part: we had performance problems on an app where the customer had insisted on xml everywhere. However, in one particularly critical part of the system we were getting hammered by the garbage collection overhead of SAX (its efficient for text in elements, but not for attribute values or element names).

Anyway - we knew what was coming into the system as we were also the producers of this xml at an earlier stage. So we wrote a custom SAX parser that only supported ASCII, no DTDs, internal subsets etc; and wrote it to return element/attribute names from a pool (IIRC we used a ternary tree to store this stuff, so we didn't need to create a string to do the lookup).

It was like night and day. XML parsing dropped from generating 80% of the garbage to about 5% and it just didn't appear on my list of performance issues from then on.

Java strings do a lot of copying, the point is to get yourself as close as possible to a zero-copy xml parser as you can.

You might want to look at switching toolkits entirely as well - GLUEs benchmarks sound a lot better than yours.

I have to agree, most XML APIs are incredible counterintuitive. The only one I like so far is Ruby's REXML (based in Electric XML for Java). If you like Ruby, and you're drowning in useless SAX/DOM code, give REXML a try.

They are apparently expanding this toolkit to a 'grid service platform' called 'Gaia' detailed here.

From the website:

GAIA is a service-oriented grid-computing platform that connects producers and consumers of services and data while shielding them from issues like fail over, load balancing and clustering. GAIA can connect and control web services hosted on any combination of platforms, and uses a P2P architecture for reliability and scalability.

GAIA is based on simple yet powerful concepts, can run on machines ranging from enterprise servers to wireless PDAs, and has native implementations for Java and Microsoft .NET.

They are apparently expanding this toolkit to a 'grid service platform' called 'Gaia' detailed here.

From the website:

GAIA is a service-oriented grid-computing platform that connects producers and consumers of services and data while shielding them from issues like fail over, load balancing and clustering. GAIA can connect and control web services hosted on any combination of platforms, and uses a P2P architecture for reliability and scalability.

GAIA is based on simple yet powerful concepts, can run on machines ranging from enterprise servers to wireless PDAs, and has native implementations for Java and Microsoft .NET.

Apparently you have not heard about glue yet.

How is it "rigid"?

I read your story: 'There wasn't enough room for comments, so we hacked ...'. You then complain that your hack doesn't work.

Further, the current EDI networks are still more reliable and secure than web-based solutions. Many big-name companies don't want to switch until such issues are solved on the web.

Big companies can pay for a subscriber line to their suppliers and/or customers that circumvents the internet. Small companies just have to to take the risk I'm afraid.

Nope! XML takes up more bandwidth than some other solutions because it repeats field/tag-names for each record. I realize that this is generally not a problem, but it does show that you are wrong.

I don't see how this is related to translating. If there is a problem with bandwith, you can simply compress the XML. Do note that we are generally moving away from efficiency towards clarity and simplicity.

And how the heck does the VM contribute to "fast development" and "good features", and "big libraries"?

I wasn't simply talking about the benefits/downsides of a JVM (I never intended to narrow the discussion, the JVM vs P-code was just an example of Java not being incredibly revolutionary). Useful things are usually not revolutionary BTW. They evolve from useless revolutionary technology (which is too complex or slow to be useful). I do claim that all the features of the language (some of which are due to the VM) are good enough to offset the slowless.

I want to refer you to this excellent report on the performance of Java. Some highlights:

"Java has a strong reputation for being a slow language that cannot be seriously considered for real applications. It has not gotten this reputation by coincidence. If you are a C++ programmer then you were probably very tired of all those Java evangelists back in 1995 that claimed that Java was superior in every regard and that 100% pure Java was the best thing there was. They even sometimes claimed that it ran practically as fast as C++, and that any measured differences were insignificant. Chances are that you tried it back then, saw how awfully slow it ran, and then dismissed it as a web development toy and decided that the Java evangelists either was liars or fools. Fortunately, most the hype surrounding Java has since then died out and the compilers and virtual machines has improved significantly in meantime. I heard the same hyped arguments back then and originally dispelled the use of Java as anything but a web applet language, because of the many promises that was clearly not true. I did not return to Java until late in 1998. [...] As we will see in this chapter Java is in fact not as slow as its reputation claims; it all depends on how you use it." [page 32]

Sounds like he had thoughts similar to yours. He changed his mind though:

"One very important factor is the amount of tweaking that has been performed on the Java program. According to the conclusions of chapter 7, a non-tweaked program will be several factors slower than an equivalent C++ program. In my tests it was 2.5 to 4 times slower [on a modern JVM]. [...] However, if the Java program is tweaked (and the C++ program is tweaked too for fairness in comparison) this difference is reduced significantly. Many highly tweaked programs have in fact been shown to be able to run faster in Java than in C++. [...] Judging from the various benchmarks I would say that tweaked Java programs on the average runs 20-50% slower than tweaked C++ program" [page 34&35]

The writer also comments that tweaked code doesn't get the advantage of quick development (about a 30% productivity boost overall), but that will only be true for the 10% of critical code. Furthermore he points out that Swing is too slow. He also shows that JVM's are progressing quickly. A very good point is that Java is plagued by too many poor programmers because the language is easy to learn (the VB-curse). In the end he sees Java as a good option for some games.

Whatta brochure-head you are.

Yep, the kind of brochures with references and benchmarks. And sometimes they are graded at a university with an A+.

Should I put more credit in someone who critiques a language by attacking an article of a random Java supporter, complaining about several style issues, blaming the language for having flaws that are not explained (what is wrong with the reflection in Java?) and using sweeping statements that are unsupported by evidence: "Most heavy OO fans agree". He even attacks the language for being OO ("Java does not make doing procedural programming very easy.").

SOAP and WS is meant to replace non-remote API calls ???????

That might be a good idea (assuming we are talking about calling API's with a few calls only, not basic library-calls). Using GLUE you can reach 300,000 messages/second in the same application. It contains various optimizations for local use.

This is only one implementation of course. But it seems to be possible to get decent performance. I certainly won't dismiss it as a possibility beforehand.