A shamei

I just poked around on the two web sites that you gave me, and I honestly didn't see any code that I would want to use unless for some reason I were already required to use Java. I mean, there were dozens of projects, but as far as I could see they were all middleware, databases, development tools, and other infrastructural bits which are only there because someone somewhere decided that all of their infrastructure had to be rewritten in Java.

I can think of exactly two pieces of software which I might want to use that are written in Java:

1. The E language. http://erights.org/ Every time I play with E, I have another round of headaches because of the fact that it is implemented in Java. Fortunately there are several active projects to implement E in a different langage.

2. Eclipse. I haven't really used it -- I'm perfectly happy with XEmacs and affiliated tools at the moment -- but I can see how it might be nice.

So at the end of the day, I'm afraid that the final great result of all of the time and money spent on the free software java efforts will be that we can run Eclipse.

Oh yeah, and there's Limewire. That's three open source projects that are written in Java that someone might want to use even if they are not required to use 100% All Java by their pointy-headed boss.

I would be interested to hear about any more such projects.

Regards,

Zooko

How can I filter so that Language=Java and License="OSI Approved" in the same search?

There must be real alternatives out there, but they are not as known as, say, JSP... IMHO anyway.

My favorite thing about Java is just how safe and predictable it is. When I declare a member variable private, I know that nothing outside of that object will be messing with it, no matter what. No worries that some code someplace trying to copy a string will accidentally get a bad pointer and scribble randomly over my stuff.

Java's built-in threading control primitives and its ubiquitously thread-safe libraries are also great, as is RMI, the GC system, and its exceptions system.

There are a lot of things Java isn't good for (see John Carmack's recent comments on Java for some really good details there), but for a large class of programming problems Java is excellent.

Portability can be great as well, my Java server and client code runs just fine on Windows, Mac OS X, FreeBSD, Linux (x86, amd64, powerpc hosted on an AS/400 system), AIX, Solaris, and more, without any ifdef's or recompiles.

Yeah, there's a lot of things that would have been fixed many years ago if Sun were more open with the environment (I've had important bugs outstanding on Sun's Bug Database for 7 and 8 years, now), but you do wind up having to take the bad with the good, and the ubiquity and consistency of the platform is a notable good.

• Evidently the consequences of declaring a virtual member are still not very widely understood. A class with virtual members presents two interfaces: one to the user (who calls the members) and another to the deriver (who overrides the virtual members). The first presents an abstraction, while the second manipulates implementation details beneath the abstraction. If your public interface consists of virtual functions, then you aren't really providing much abstraction at all, and your class isn't really earning its keep. Given this, for members to be virtual by default is profoundly silly.

• Java's exception specifications are markedly worse than in earlier languages. It's true that specs have turned out to be a mistake wherever they appear. (Probably the only form of exception specs that would work is to list exceptions that cannot come from a function. It's not clear how useful that would be, though.) In C++, you can simply leave them off (as everyone does, nowadays) and everything will work. In Java you can't do that; they intrude everywhere, unavoidably. They have actually got worse in Java 1.5 with the addition of generics.

• As I said, a 16-bit internal character representation is frankly silly. An 8-bit UTF-8 multibyte format is defensible, and a canonical UCS-32 works. Either bank is OK, but the middle of the river is all wet.

• To take up C syntax and fix only a few of its flaws is worse than silly. It reeks of cargo-cultism. C++ has C syntax to ease upgrading; users can compile a C program with a C++ compiler, and then start cleaning up. Most of the language's other infelicities are traceable to that requirement. Java had no such justification; no C program is a valid Java program.

• To have to suffer all that the Java type system imposes with no benefit of compile-time error checking is ludicrous. It was known perfectly well how to do (inadequate) generics in the late '80s, as in Eiffel, or Ada. To wait ten years and then paste them on, crippled (because the code generated is the same as if you had done the casts), can only be described as another mistake. C# did only a little better.

• One of the deep problems with garbage-collected memory is that its costs don't show up in profiling. When a program is an order of magnitude slower than it should be, there's a reason. With GC, it's likely to be bad cache interactions. With GC, there's precious little you can do about it. (Non-portable tricks might help, but then your "run anywhere" leaks away; even the next release of your own JVM might break them.)

• The faults I listed were incidental stupidities, to illustrate the lack of understanding by the language designers. I didn't list the deliberate design flaws. It's easy to see why it was taken up most enthusiastically by the worst-organized corporate IT departments. People find ways to use all kinds of languages -- even Forth! That doesn't excuse the design, or the designers, of fundamental misunderstandings of their craft, and it doesn't suggest any reason to take up the language for one's own use.

Free Software has largely avoided being saddled with Java overheads, and can only benefit from continuing to avoid them. Let corporate America mire itself helpless.