LWN: Comments on "GCJ - past, present, and future"

GCJ - past, present, and future

toren03 — Thu, 21 Apr 2005 08:16:18 +0000

The JCP defines a reference implementation of Java which has enough in the way of free packages and IDE to make Java attractive to use. The fact that SUN wants to maintain some control of Java is bearable. Otherwise the language could get hijacked into OS specific variants like J++. That would hurt not just Sun but the open source java community as well. Last time I tried using GCJ there were too many features (like JAXP for xml) that just couldn't compile. Ideally changing compilers should not require any changes in the code or in the build tools so that requires that GCJ support generics, the new collection classes and most definitely JAXP. The argument that java is a closed community is interesting, but I think erroneous. Also Stallman's article about the Java Trap doesn't seem that relevant to normal users. Sun, Oracle, IBM are all not about to fade away and the trend has been towards OpenSource tools to encourage migration from Microsoft proprietary systems. Good that GCJ exists, but better that Sun has and will continue to foster a Java programming community. Java has been and will remain a good platform for testing ideas (see the JTXA project at java.net, Proactive Java Grid) and as a source of excellent usable free software as good as C/C++. And I see this as an issue of quality and not just quantity. The projects on apache are worth all of msdn. Commentors seem to overlook the fact that C projects have dependencies too that while may not need licensed software to solve but require a tremendous effort in time (and even then). This is less true with java especially with tools like ant and maven there to lean on. So I'll look into GCJ and IKVM again, but the language is Java 1.5.0

Look again...

zooko — Wed, 20 Apr 2005 09:34:03 +0000

Well, I've now wasted a great deal of my time fruitlessly trying to coax the freshmeat interface into giving me the intersection of "OSI Approved" and "Java". Wow, how frustrating. I've wasted much of my morning when I could have been doing something that worked.

Look again...

zooko — Wed, 20 Apr 2005 08:29:21 +0000

Oh, I have to log in to freshmeat to do that.

Heh, I still remember my password, although I haven't logged into freshmeat in probably three years...

Look again...

zooko — Wed, 20 Apr 2005 08:26:19 +0000

How did you accomplish this filtering? I just spent quite a while poking at the freshmeat.net site, and I can't figure out how to do anything other than browse by category or sub-category.

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

Look again...

bert.kenward — Wed, 20 Apr 2005 03:26:05 +0000

Hi,
I went to freshmeat and filtered the proyects by Language=Java and License=OSI Approved and it returned 2520 projects.

When I added the filter Development Status= 5 - Production/Stable I got 916 projects. No too bad I would say.

Cheers

A shamei

Jyhem — Mon, 18 Apr 2005 17:54:57 +0000

The link to GanttProject is broken. It should read:
http://ganttproject.sourceforge.net/

A shame

jae — Sun, 17 Apr 2005 03:13:28 +0000

Azureus was why I installed Sun's Java. Tried to run it with kaffe et al first, but no dice. So I took the plunge (sad, sad day that was).

A shame

renox — Fri, 15 Apr 2005 20:31:27 +0000

Frankly I think that your reasons are a bit weak for such "definitive judgements".
While Java has many flaws (the number of bugs in it standard library being the number 1 mistake, Swing..), it is not a bad language just disapointingly average (getting out a language with no generics just to release it faster, no comment).
What I find amusing is that you seem to find C++ okay and Java ugly whereas in my book it is just the opposite: C++ *is* bad: a language which needs years for developpers to learn (and from which they use 30% of the features at most) and for which no compiler can be fully conforming years after the specification was made is bad.
Also in my opinion, the 'bolted on' nature of C++ feels is really ugly (reference and pointers, urgg), whereas Java's shallow use of C syntax to ease migration seems sensible.

A shame

ncm — Mon, 11 Apr 2005 04:02:29 +0000

A disappointing feature in a language is a tradeoff only when something was gained in exchange. If you got nothing in exchange, then it's a pure design flaw. Exception specifications are a classic example: C++ has them, but shouldn't. Java has them, too (but markedly worse, despite hindsight!). It's a pure flaw, with no benefit in sight.

One doesn't run across people complaining about how slow programs C++ are, but people frequently complain about Java programs. Java programs, as a rule, really are slow. Garbage collection carries much of the blame. For C++, GC would not be a feature. Rather, it would make encapsulating resource management impossible, as it is in every GC language. The presence of GC doesn't only hint that a language is too weak to encapsulate resource management. GC, by itself, makes that impossible. GC actually sabotages the design of languages, for industrial purposes. It is possible that academia's insistence on GC in new languages is the sole reason that (still!) no language has surfaced that might displace C++ in industrial use.

The whole purpose of exceptions is to make programs simpler and more robust at handling errors. C++ exceptions work superbly: error handling code is reduced to one or a few chokepoints where exceptions are handled, with typically very little code, easy to exercise with minimal testing. Java exceptions, by contrast, fail completely: a Java program that handles exceptions properly is much longer, with error handling scattered throughout. Hard to exercise, it rots. (More commonly, it is just omitted.)

Anybody who can't design an exception-safe stack for C++ has not identified a flaw in the language. Idiocy is a purely personal problem. See http://cantrip.org/stupidity.html.

As I noted before, the macro system in C++ comes unchanged from C, for the strictly practical reason of backward compatibility; most C++ programs use only #include and #if. The template system works fine on mature compilers, of which many are readily available today. (That MS's product remains dodgy tells us way more about MS than about language design.) The problems in template syntax are a product of language evolution: ISO C++ templates are far more powerful than as originally envisioned. Power is worth trading a lot for.

I don't know of any widely-used string type designed after the ISO standard was published. Of course the old ones, and those necessary to interact with C code, hang around. Library apparatus to operate on in-core multibyte strings is no credit to a language. External multibyte text representations (and conversions to and from) are appropriate for interoperability, but it would be foolish to operate directly on strings in that form.

All this is not to claim C++ is especially good; rather, Java is especially bad. If Gosling isn't disappointed with his design, it can only be because he hasn't paid attention. Java has managed to set back the practice of programming by a decade. A whole generation of programmers have had their careers blighted by exposure to it.

A shame

Xman — Fri, 08 Apr 2005 23:05:55 +0000

I think it's sufficient to say that you see design flaws where language designers see design decisions. You may not like the decisions a language designer makes, but that doesn't make them design flaws. Every design decision has tradeoffs, and you make a choice about which tradeoffs you want to work with. A design flaw is when you make a choice without recognizing its short comings. With the exception of exception specifications and ill defined bits in the Java memory model (both of which were the cases where they tried to do something new with unknown implications, rather than borrow concepts that worked well in other languages), I don't think you'll find James Gosling was surprised or disappointed by how things played out.

You've implied with your statements that you think C++ is a "public-standard language that is more powerful and more thoughtfully designed" than Java. Let's look at how it plays out on these issues. Yes, it defaults to non-virtual functions, but it also defaults to private non-virtual inheritence. While most Java code leaves member functions as virtual, most C++ code uses public inheritence and specifies virtual inheritence whenever it is an issue. I'd argue those are issues of style, but if they aren't then I'd have to say C++'s defaults are far more flawed than Java's. C++'s exceptions create so many problems that the people who *worked on the language* couldn't figure out how one would write an exception safe stack for the longest time. C++'s string class can be made to do UCS-32 (you didn't need that memory did you? ;-), but has no notion of using a variable width encoding of strings, and a lot of implementations still ship with 8 and 16-bit character types. Indeed, C++'s string class is so "broken" that there are any number of competing string implementations out there (include C strings) in wide use while Java's String class seems to work just fine for 99% of Java code. C++ claims to be fully compatible with C, but manages to have several subtle differences which turns out to be far more dangerous than being similar enough to help developers understand what they are looking at. C++ is the home of one of the worst macro systems known to mankind and has a powerful templating system who's syntax is so baroque that a number of semantic ambiguities were uncovered at the last minute, forcing some hacked and overloaded uses of the keywords "typename" and "template" to disambiguate the code. Nevermind that the system is so complex to this day few compilers can fully compile code using the likes of boost::lambda. C++ doesn't come with any support for GC, so you end up with people often jury rigging a solution using reference counting that is inherently flawed, increadibly slow and a potential source of deadlocks if you need thread safety, often slower even when single threaded, still leaves them with a fragmented heap and... (wait for it) bad cache interactions.

Despite pointing out all these issues, I like C++, and use it probably more than any other language. The reality is all languages suck, because most design decisions have unfortunate trade offs. It's unfortunate when this intrinsic property distracts from the advantages each language has to offer.

A shame

ncm — Fri, 08 Apr 2005 16:12:03 +0000

Java was taken up by corporate IT departments because its flaws mesh well with theirs. A Java web application produced by seven or more corporate functionaries, each in his own department, could be done much faster by one or two (say, a coder and a graphic designer) using a better-designed system. However, to allow that would interfere with job security for those functionaries and their managers, and would bridge organizational barriers carefully erected by the latter.

A shame

ncm — Fri, 08 Apr 2005 16:03:10 +0000

In detail and in order,

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.

A shame

jonabbey — Fri, 08 Apr 2005 15:10:26 +0000

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.

A shame

hmh — Fri, 08 Apr 2005 09:42:54 +0000

IMHO it is because the best known competition is a ugly joke for anything of a reasonable size. While it takes a LOT of effort, you can write proper, reasonably resilient code in Java to drive stateful web applications that will scale to the millions of transactions per hour range...

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

A shame

Xman — Fri, 08 Apr 2005 09:28:28 +0000

Just to review the faults you cited:

Most OO languages have their methods virtual by default, as it aids in reuse. While there is a performance penalty normally associated with virtual functions in C++, modern JVM's are very good at optimizing this to the point where they often inline virtual function calls. Frankly, I find it annoying how often I have to specify "virtual" in C++. Really, it's a style issue, not a design flaw.
compulsory exception specifications. Well, they did better than their predicessors in this regard, but I'd agree this proved in time to still not be a good design. The thinking at the time (and it was by no means restricted to the folks designing Java) was that exception specifications were a good thing, but just hadn't been done right yet.
16-bit characters. They did start out this way, back when everyone thought all Unicode characters could be represented with 16-bit characters (and they weren't the only ones to make this mistake... for example Windows NT and C++'s STL). They now do 32-bit characters and strings are encoded internally in UTF-16. When writing to streams and such you'll find your locale determines the default encoding (so for example things will often get encoded in UTF-8). This is the same scheme used by Unicode libraries for other languages such as the C++ ICU library. It's really hard to run in to endian problems with the internal encoding of strings because that isn't visible. It's really hard to run in to endian problems with integers in Java, because Sun ensures a consistent byte order. They have their bases covered here.
not being able to mimic built-in types. This was done deliberately, and frankly has a lot to do with Java's commercial success. Talk to Smalltalk component vendors to get an idea as to why this can be a good thing.
They actually did break a lot of C's worst syntax rules and clarified a number of C's ambiguities. That said, they started out originally wanting to be as much like C/C++ as possible while still achieving their design goals, and arguably this was to their advantage.
Java has generics now, so you can actually avoid pervasive casting. They avoided putting generics in at first because they weren't 100% sure how to do it right, and they figured doing it even slightly wrong would make generics more of a hinderance than a help (I think they ended up being a little wrong on this, but it was a pretty rational decision as they had no way of knowing how successful Java's initial design would be). Even if you don't use generics and do lots of casting, you get runtime errors if you screw up your types, rather than C's tendancy to ignorantly blunder on.
Try profiling Java code sometime and see how much time is spent doing memory management. I've found on average Java programs spend less time managing memory than most C/C++ programs. Ironically, a lot of the performance problems I see in Java programs are caused by trying too hard to avoid allocating memory on the mistaken premise that the performance costs of doing so are as severe as they are in the C/C++ world. There are times when managed memory is a pain, and ever since JDK 1.4 there have been options available to avoid it. There are still cases where Java makes it hard to do what you really should be doing with memory, but they are well past the 90/10 rule.

In summary, I think you lack context when interpreting Java's design. This leads you to see nonsensical design decisions driven by proprietary head-knocking when in fact there are quite rational reasons behind their decisions. Java wasn't designed as a weapon for Sun to use against Microsoft (and looking at the design "faults" you've cited, I'm at a loss to see how they serve to make Java a weapon): that's how it was marketed. The original design was done well before the marketing strategy was even put in place (in fact the marketing strategy changed a few times as I recall), and originally was targetted at networked embedded devices (back before Microsoft had a presence there).

Sure, Java isn't perfect. No language is. Despite this programmers manage to find a lot of them useful, and Java is no exception in this regard.

A shame

giraffedata — Fri, 08 Apr 2005 03:03:18 +0000

Thanks for all that. One aspect you didn't really cover is why a language with all those problems is the de facto standard in some proprietary software arenas. Like web services. And these don't seem to be tied to Sun's aspirations.

A shame

ncm — Fri, 08 Apr 2005 02:30:25 +0000

Should I make a list? The language's purpose was not a way to express programs clearly and efficiently, but rather to be a weapon for Sun to use against Microsoft. It's rife with peculiar design decisions that make no sense except in support of proprietary head-knocking. Free Software doesn't need any of that; we already had "write once, run anywhere" that actually works. We don't need to give up anything to get it. The language has no public standard, and its originator has no interest in making one. That makes it unsafe as a development platform for careful people; the future of the language is not controlled by people who use it.

Besides peculiar choices that were more or less purposeful, the language and its libraries were designed in enormous haste by people who really didn't understand quite what they were doing. Therefore, many of the central choices were simply stupid. Examples of that include making member functions virtual by default; compulsory exception specifications; a character type 16 bits wide, not wide enough to represent a whole character, but too wide to avoid endianness problems; syntax that mimics the historical mistakes of C for no plausible reason; no way for user defined types to mimic built-in types. Because no significant program can avoid pervasive casting, it suffers all the inconveniences of a type-safe language without actually providing type-safety. Finally, it is saddled with the academic "garbage-collection" disease, which is one reason why real programs are so slow, despite that benchmarks suggest it should be otherwise. Sophisticated techniques to fix that have been promised to come out any day now for the last ten years. (C# doesn't fix many of its problems, even given years of hindsight.)

The language is a snapshot of how "object oriented" programming was understood (or misunderstood) toward the end of the overhyped '80s. That's hard to excuse considering it came out half a decade later, and it is entirely ridiculous fifteen years on. Object-orientedness has turned out to be useful for some things, and irrelevant for most; while it's handy for a language to support it directly, it's foolish to make every detail of a language depend on the notion.

Design concerns aside, it's notoriously hard to deploy Java programs, because of the JVM incompatibility problem. Each program typically either requires the default platform JVM, if there is one, or ships with its own. A system with six Java programs typically has six JVMs installed.

Fortunately we have a public-standard language that is more powerful and more thoughtfully designed than Java, and you have literally hundreds of end-user Free Software programs written in it on your disk right now. It's unencumbered with submarine patents, fast and efficient, and has lots of fantastically powerful libraries available. It works well enough that you never need to know -- and generally don't know -- that a program was written in it. Can that be said about any Java program?

Missed the obvious one

Xman — Fri, 08 Apr 2005 00:35:32 +0000

I can't believe I forgot to mention DSpace, which is actually mentioned in this week's LWN!

A shamei

Xman — Fri, 08 Apr 2005 00:31:58 +0000

Based on the stats you collected, it would seem Java is used about as much as Perl. ;-) Java might not be needed for a working Linux system, but the same could be said of C++. Despite that, there is a lot of good open source code out there written in both languages.

Without a decent open source Java, you aren't going to see distros bundling a lot of Java applications (C++ once suffered from a similar problem). You're also going to find applications using it are less popular than those which can easily be built on open source platforms. gcj4 could really change that.

That doesn't mean there isn't a lot of very good open source code out there written in Java. Despite the fact that there hasn't been a really usable open source Java implementation, a lot of open source Java code has been written, which should tell you something. Just to through out a few (and I'm sticking to end-user tools, ignoring some of the amazing development stuff out there with no equivalent elsewhere):

OpenOffice
Nutch an open source search engine, based on Lucene
Ganttproject an open source project planner
Art of Illusion a free 3D modeling and rendering studio

I could go on.... The point is there is a lot of great quality code out there and we'd be fools to ignore it.

OpenOffice.org 2

mjw — Thu, 07 Apr 2005 23:55:42 +0000

How about OpenOffice.org? If Java helps them develop more features for it faster, and if they can run with gcj (and apparently they can, given what Red Hat is saying about FC4), more power to them!

The use of the java programming language in OpenOffice.org 2 was a big worry to a lot of people because the free alternatives for java, like kaffe and gcj, were not up to date enough to support everything the OpenOffice.org hackers wanted to do. So a lot of energy has been put into making sure GCJ 4 does support what the OpenOffice.org 2 build process requires.

You can follow the work of Caolan McNamara to see the progress. And Anthony Green posted a screenshot of OpenOffice 2.0 database application running on hsqldb with a fully Free gcj-based runtime stack on FC4test1.

Lists of packages

Xman — Thu, 07 Apr 2005 23:54:52 +0000

Compared to the rest of the GNU system the support for the java programming language is just maturing.

Agreed. That's exactly why gcj4 is good news.

GCJ - past, present, and future

mjw — Thu, 07 Apr 2005 23:44:46 +0000

I hadn't been able to find any information about efforts in that area when I looked in the past.

The 1.5 language efforts are fairly new. Only the last couple of months have there been a couple of important breakthroughs. You can find more information on GCJX from The Cliffs of Inanity, the blog of Tom Tromey, the main GCJX developer. Some of the other development around GNU Classpath, including which people are hacking on the generics libraries, can be found on Planet Classpath.

A shame

giraffedata — Thu, 07 Apr 2005 23:27:08 +0000

Does anyone know why so much proprietary software is written in Java and free software not?

I don't worry so much about how much free software is written in Java already. Most of what I see today is C, and most people don't believe that's the ideal situation for the long term. Rather, we feel trapped in C.

I'm more interested in arguments as to why free software developers shouldn't pick up these wonderful new Java tools and start using Java. Are there strings to Sun that would be detrimental? A better alternative?

Good Article

tjc — Thu, 07 Apr 2005 23:26:55 +0000

Yes, good article.

GCJ has "blipped" on my radar a time or two over the past few years, but I've never tried it. I'm not a huge Java fan, but I get a few contracts that require Java, so I end up using it now and then. The ability to compile Java programs to native code using free tools and libraries makes the language much more interesting to me.

GCJ - past, present, and future

iabervon — Thu, 07 Apr 2005 19:09:15 +0000

Thanks for mentioning GCJX; it's work on providing what's been keeping my on Sun's JDK (JZSEl 5 language features, and I hadn't been able to find any information about efforts in that area when I looked in the past.

A shamei

oak — Thu, 07 Apr 2005 18:56:10 +0000

I don't have any Java applications, but I've been seriously looking at:
- Freemind mind mapper (freemind.sf.net)
- ArgoUML UML modeler (argouml.tigris.org)
It's funny how most of the UML modelers seem to be done with Java (I mean
most, not the ones I use. I use Dia...).

There are also a few nice Java games out there. Some small ones you can
find from here: http://www.javaonthebrain.com/brain.html

A shame

jonabbey — Thu, 07 Apr 2005 18:06:57 +0000

I've been working for nearly 10 years now on a GPL'ed program, in Java, for managing changes to directory services.. see http://www.arlut.utexas.edu/gash2/. It's up to around 250k lines of code at the moment.

That web page hasn't been updated in awhile, but we've been extremely busy here working on 2.0, and we'll be "relaunching" it in the next month or two.

Got to get back to my xemacs window now, in fact.

A shamei

AJWM — Thu, 07 Apr 2005 17:03:55 +0000

Very little of Free Software is written in Java, aside from what might be used by those already obliged to use Java

Well, you could probably say the same about C++, or Perl, or even C. People tend to write free software in whatever language they're comfortable with, which will tend to be whatever they're using on a day-to-day basis.

As to "obliged" -- I've written free software in Java when I was obliged to use Visual C++, and even when I was obliged to use Perl. I've also written free software in C and C++ and even Pascal. Even Fortran77, come to think of it.

I'm not a big fan of J2EE, nor for projects where you might want to take close advantage of the Unix (or Linux) view of a filesystem (although that sort of thing is often better done with a database these days anyway), but it's a nice easy, and even more, safe language for medium projects.

Why all this hostility?

ohanssen — Thu, 07 Apr 2005 17:03:53 +0000

Sigh. The Java platform is not proprietary, but ok, the specification process is led by Sun. The reference implementation can however, be said to be proprietary. In fact it is "almost" open source, since you are allowed to modify the source code and (under some restrictions) redistribute modified code. There are lots of open source projects using Java. Just look to Apache!!

Why all this hostility against Java?

Great article

b7j0c — Thu, 07 Apr 2005 16:25:49 +0000

This article is a great introduction to the nuts and bolts of gcj. Thanks to the author. While I am not a huge fan of Java, it is important that free software offer options to people who are stuck with it. It is also a decent litmus test for coders obsessed with portability - one more portability assurance tool.

A shamei

yodermk — Thu, 07 Apr 2005 15:20:39 +0000

How about OpenOffice.org? If Java helps them develop more features for it faster, and if they can run with gcj (and apparently they can, given what Red Hat is saying about FC4), more power to them!

Not to mention all the Apache projects that use Java. And a few games, like JRisk (no Linux native Risk game compares).

Seriously, I don't understand the aversion to Java. It really is a more productive language than C++. It likely has fewer potential patent problems than Mono. A solid native Linux Java compiler like GCJ can *only* be a good thing for Free Software.

A shame

ncm — Thu, 07 Apr 2005 14:42:46 +0000

There's pdftk, which my wife's cousin wrote, a PDF toolkit. Built with Gcj (as it is in Debian) it's relatively harmless.

A shamei

zooko — Thu, 07 Apr 2005 14:25:20 +0000

Hey thanks, for the list! I'm glad there are at least a few useful Java apps.

A shamei

kfiles — Thu, 07 Apr 2005 14:17:50 +0000

<quote>
I can think of exactly two pieces of software which I might
want to use that are written in Java:
[...]
I would be interested to hear about any more such projects.
</quote>

Well, ones that I use everyday include Eclipse (great IDE for just about anything, from SQL to Java to C and C#), Azureus (hands-down best bittorrent client in any language, using SWT), pdftk (great PDF manipulation, using GCJ-compiled iText), javassh (only decent way I know to do web-server-proxied SSH), Galleon (very cool Tivo HME server), and Netflix Addict (cool http-scraped GUI client for managing Netflix queues).

These are all applications I chose because they were the best, or only way to accomplish a task, not because or despite of the fact that they were written in Java. Of these, only Netflix Addict suffers from obvious Swing maladies.

URLs:
http://www.eclipse.org
http://azureus.sourceforge.net/
http://www.accesspdf.com/pdftk/
http://sourceforge.net/projects/jta/
http://galleon.sourceforge.net/phpwiki/index.php/HomePage
http://netflixaddict.sourceforge.net/

Thanks,
--kirby

Lists of packages

mjw — Thu, 07 Apr 2005 13:07:14 +0000

try counting packages in the distribution you're running right now, omitting compilers and libraries. You'll find thousands of C, hundreds of C++, and a bare handful of Perl, Python, Scheme, OCaml, and what-have-you. That is as it should be.

I think that is a fair comment. Compared to the rest of the GNU system the support for the java programming language is just maturing. For the free software distributions we will certainly rely on the more traditional languages for years to come.

To see what we get from adding support for the java programming language to the different distributions you can take a look at:

Mostly compilers and libraries at the moment.

For writing new free software desktop applications in the java programming language I would recommend looking into the java-gnome bindings. Then you can hook up with much more traditional free software libraries. Not just Gnome/GTK+, but also cairo, dbus, gstreamer, etc.

A shamei

zooko — Thu, 07 Apr 2005 12:44:28 +0000

Python is my current language of choice, too.

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

A shame

ncm — Thu, 07 Apr 2005 12:36:52 +0000

As the original article said, "Very little of Free Software is written in Java, aside from what might be used by those already obliged to use Java". Certainly Java coders are writing lots of code for their own use -- scratching their own itch, not that there's anything wrong with that -- but very little of it escapes to the wider world. Instead of counting defunct Sourceforge projects, try counting packages in the distribution you're running right now, omitting compilers and libraries. You'll find thousands of C, hundreds of C++, and a bare handful of Perl, Python, Scheme, OCaml, and what-have-you. That is as it should be.

Good Article

rmathew — Thu, 07 Apr 2005 11:32:54 +0000

Nice article Mark! Too bad I can't post a link to it right away
on the GCJ mailing list since most people can't access it
before another week has passed.

On the other hand, maybe I should - that should prompt
at least some people to subscribe to this excellent
online magazine. :-)

A shamei

faassen — Thu, 07 Apr 2005 10:40:39 +0000

There is *plenty* Java-based open source software out there. Many of the Apache projects are java-based, for example:

http://www.apache.org/

Here's another vast amount of Java-based open source software:

http://www.objectweb.org/

Anyway, I suspect that pointing you to any number of Java based free software projects won't help convince you, but I thought I'd give it another shot.

Note that I'm not even a Java programmer myself (Python is my language of choice). But some of these Java-based projects have plenty of visibility.

A shamei

zooko — Thu, 07 Apr 2005 10:23:27 +0000

I have looked on sourceforge, and I found that although there were many projects which said they were going to be written in Java, most of them were vaporware.

Here are the results of my investigations. Note the date stamps:

http://www.eros-os.org/pipermail/e-lang/2001-February/004...
http://www.eros-os.org/pipermail/e-lang/2001-October/0058...

I'd be interested in updated results. My anecdotal personal experience is that I have zero Java apps installed on my Linux boxes.

Honestly, I hate Java and I'm glad it is dying. I consider it a shame that RedHat and others have wasted so many years of the precious time of brilliant hackers.