Slashdot Mirror

what you're looking for is called jython

Exactly! Ganesh Prasad has hit the nail precisely on the head with his comments about .NET versus J2EE. Forget the marketshare issues, the meat of this article is that J2EE is here, today, and that complete OSS implementations of J2EE are achieveable this year ... as long as the open/free community stops trying to change Sun, and instead works around Sun. It would be much less effort than doing a full implementation of .NET, and much of the work is already done.

All of the myths about Java's speed (slow) are just that -- myths. I've built real-time data collection applications that run perfectly fine with Java/MySQL/Linux on Pentium 166s with 32MB of RAM -- Java was more than fast enough for our needs, and the development cycle was a lot faster than would have been possible with C++. Java is more than fast enough for server applications where JIT compilers can truly optimize the code, since it is compiled once and then kept in memory and run repeatedly. Benchmarks have shown that for typical server applications, modern JVM/JIT combinations are as fast as unoptimized C++ code. While an expert can still hand-optimize C++ to out perform Java, in reality, you'll have to ship your applications before you have time to apply those optimizations ... and Java's development cycle is (in my experience) still much faster than C/C++, simply because you can rely on the JVM to protect the OS from your code (and vice versa).

I'm also tired of hearing about how Sun's JVM only supports a single language -- Java, while .NET supports many languages. There are literally dozens of languages that can be compiled to run on Sun's JVM, even if Perl isn't one of those languages. Anyone who thinks that they'll be able to easily port existing C code to run on .NET and use .NET services hasn't looked at how virtual machines (and the CRL in particular) are implemented. Yes, the JVM is optimized for Java (and vice versa) but you can still use the JVM to allow you to write your applications in non-Java languages and deploy them on any platform that supports a JVM. Some languages, like Jython (a version of Python written in Java), allow you to create non-Java classes that inherit from Java classes, as well as Java classes that inherit from non-Java classes.

Anyone who claims that Sun's control over Java makes it impossible to build an open implementation (because Sun would just change the spec) and then in the same breath says that they won't have the same problems with .NET and Microsoft needs to wake up and smell the brimstone. While Sun does control the Java specification process, they still have to work with their partners and licensees, and the specification process is open -- and most of the reference implementations for the higher-level APIs are open as well. They can't change the Java language without breaking backwards compatibility for thousands of applications and millions of users, and Sun doesn't have any monopolies to fall back on. Microsoft, on the other hand, controls the desktop OS market, and can use that and .NET to conquer the server OS, and since the implementations for .NET are closed, Microsoft can switch the back end and the desktop without breaking applications deployed on Windows ... while simultaneously breaking non-Microsoft implementations. What more can a monopolist ask for?

And the best reason to work with Java/J2EE instead of .NET -- Java/J2EE is here, today, and has been working for years. While it isn't perfect, the bugs have been worked out, and it works. .NET is still beta code, and once it ships, it will still be a version 1.0 Microsoft product. It will take two more iterations (and who knows how many years) before .NET is truly stable, useful, and reliable. I need to build and deploy applications today -- not 3 years from now.

The CLI and the JVM are comparable in this instance. As for which is better, I'm still not sure. For example, Python (through the use of Jython) can be compiled to Java bytecodes and can extend/be extended from Java classes (or anything else appropriately compiled to Java bytecodes). The same is true for ECMAScript (Javascript) through the use of Rhino.

Through the use of gcj, Java can be compiled to native code and has excellent two-way hooks to C++ for "native" code with CNI. C bigots can still use JNI (ugh) if they so choose. Java VMs are definitely more mature and "battle tested" than .NET's CLI, but I'm hard pressed to really pick a theoretical (intrinsic technical merits) winner. The more I hear about .NET, the more it truly does look like some things that Java has been doing for years.

And who knows, maybe the Java language will be ported to .NET. It can't be too hard considering the similarity with C#. If this is the case, Java becomes the more flexible solution again in that it could have three targets: Java bytecodes, CLI bytecodes or compile to native.

"Remember, .NET is a platform for distributed computing. Platform/language neutrality is a key part of that."

Distributed computing is one part of it (a big part when you factor in Passport), but no bigger than EJBs (and related techs such as RMI-IIOP, CORBA, JNDI, etc.) are for Java. The distributed aspects are dependant upon the language/bytecode aspects, not the other way around. What good is Passport without the language/platform support and the CLI? What good are EJBs, Jython and Rhino if there is no JVM? Slightly different comparisons, but not by much.

And for the record, OpenBSD *is* better than Perl. ;)

I have been doing this for 2 years on Java and Linux. See jython.

Why does everyone here assume C# will be better than Java? It's irrational. Or it's ignorance?

Well, alright, MS won't ship XP with their proprietary VM based on Sun's Java.

Instead, they'll ship it with their proprietary VM inspired from Sun's Java.

Alright, I have to admit I'm not entirely fair here; the whole C#/.NET thing is a little more than a ripoff of Java, but still. :)

Anyway, maybe we're just seeing a turning point in the history of compilation... Who knows, maybe in the future, we won't compile stuff for a given architecture, but for a given VM. That's the way Python, among others, was already headed with its Java implementation. Now it's also supported in .NET. Yep, there's in .NET's CLR native support for a lot of languages, which proves at least that MS means business, for real.

The big question is, I guess, will we be able to choose the VM we prefer, like we can currently do for Java? Knowing MS, that's unlikely. I suspect that there's a catch, and that the key components will remain in MS' possession, so that they don't give a darn about what OEMs install or don't install. Could a more MS-informed reader provide more information?

... Geeze, was that off-topic... Oh, to hell with it, it's only karma.

-- B.

According to their license and their sourceforge site the Jython license is OSI-approved, but GPL-compatibility is not quite the same thing.

Jython is cool because it allows Python code to be compiled into Java class files, but you need to distribute those files along with the Jython class files... but if you're distributing them together, doesn't that break the GPL?

--Cycon

According to their license and their sourceforge site the Jython license is OSI-approved, but GPL-compatibility is not quite the same thing.

Jython is cool because it allows Python code to be compiled into Java class files, but you need to distribute those files along with the Jython class files... but if you're distributing them together, doesn't that break the GPL?

--Cycon

One place .NET shines over Java is that you are not forced to do all your development in Java but instead can use the right tool for the job in different parts of your project and combine them seemlessly. Utilizing Perl classes from VB or inheriting from C# classes in C++ is very attractive and extremely cool.

This is something that's said pretty often and has almost become conventional wisdom, but I take exception to it on two points:

• Java can do that too. There's no reason other languages can't be written to compile to JVM bytecode, as Jython has. Multiple language functionality is not CLR advantage (although you could make the case that active support for so many languages is a .NET advantage).
• It's bad programming practice to mix and match languages like that. Take your first example - utilizing Perl classes in VB. What happens if the developer who put your application together leaves? Now instead of finding of Perl developer or a VB developer, you have to find someone who knows both, and even if you do, it's going to be much more difficult for the new guy to get up to speed in a multi-language system.

.NET may have some advantages over J2EE, but I don't think that's one of them. And, as a side note, I think multi-vendorism is the best selling point of J2EE. Right now, I'm building an application using Linux, PostgreSQL, and JBoss (GPL'ed EJB container). If its use takes off, I can very easily upgrade it to Solaris, Oracle, and Weblogic, with almost no code changes.

Oh, and I believe Guido has actually taken JPython into account into the past, he's written at least one evangelical article describing it as a good match with Java.

But does that mean I want to use GNUstep? Not really anymore. I view Java, Java2D, and Swing as the direct descendent of NeXTStep and OpenStep. Java as a language has many of the same dynamic features as Objective-C, but Java adds runtime safety and garbage collection, two really important features. Java2D has an imaging model very similar to DPS. And Swing is a mature, powerful toolkit that has borrowed a lot from its predecessors. In terms of size and performance, a Java installation is probably smaller than a full OpenStep (or GNUstep) installation, and Java performs well enough on modern hardware.

So, I understand the appeal of GNUstep. Some things are still easier in it than in Java/Swing. But, on balance, I think Java is a pretty decent successor, and problems are getting ironed out. If you find Java programming itself too cumbersome, you can always use some of the more dynamic languages built on top of Java, like Jython.

I realise this is a joke, but actually, Jython offers a PythonInterpreter Java class that lets you do exactly that, embed Python scripts in Java. It is v. cool :)

The standard Python implementation is interpreted, it's as cross-platform as Perl or Java or whatever. There's also a pure Java implementation of Python, Jython, which I've found very useful as a scripting tool in a Java environment, as you get full access to Java classes from Python.

Python is a scripting language, so I use it in preference to Java where a script is called for, eg - rapid development environments.

1. Java is the most common language used to develop programs for the JVM, but nothing prevents you from writing a compiler which translates the source of any given language into JVM bytecodes; Sun does nothing to prevent this, AFAIK. See www.jython.org for an example of this which exists today.

2. Java already does JIT and native code generation. JIT is more common because it is more flexible.

3. This is the first I've heard of .NET being cross-platform. But I'll accept your assertion and point out that Java already runs quite well on every significant enterprise platform.

4. Java already has a robust security model.

5. Java servlets are already garbage collected.

6. This sounds cool but I'm dubious about it's success. Besides, you can already achieve the same goal by using Java applets or Java WebStart.

7. Java already does this, but I am glad to see Microsoft finally address the "DLL hell" problem that they created themselves.

Keep in mind that Java delivers all these things robustly *today*. It will be years before .NET will be usable for real enterprise systems. I think the point of the original posted question is that .NET is almost a wholesale rip-off of the current Java platform. There is little to nothing proposed for .NET that is not already implemented in the Java platform.

.NET is basically two things: (1) an adminssion by Microsoft that Sun is right regarding the Java platform and its goals, and (2) vaporware to try to slow the "steamrolling" rate of adoption of Java for enterprise computing. Have you noticed MS's recent ads touting their "enterprise computing." They know where the money is going, and they know who currently owns that market...*today*!

As for automatically blasting MS, either you're really clueless about Java, or you are guilty of automatically preferring .NET "just because it's from Microsoft." As a beta tester, I think the latter is more likely.