GCJ - past, present, and future [LWN.net]

April 6, 2005

This article was contributed by Mark Wielaard

GCJ (the GNU Compiler for the java programming language) is part of GCC (the GNU Compiler Collection) and provides a compiler, runtime environment, core libraries and tools for the Java language - it's an object oriented, strongly typed, garbage collected programming framework with a rich core library. GCJ is modeled after, and is a free replacement for, the proprietary Java platform. But like GNU is Not Unix, GCJ is not Java.

The traditional Java platform is clearly not an ideal system, especially when combined with the traditional GNU system, but it is not too bad. The essential features seem to be good ones. Lots of Free Software is already written in the Java programming language so a free system compatible with the Java platform would be convenient for many hackers. GCJ is an extension of GCC and facilitates integration with other languages supported by GCC. GCJ 4, part of GCC 4.0, adds more features to easily integrate programs written using the GCJ development environment with the rest of the GNU platform while being even more compatible with the traditional Java platforms then previous releases. GCC 4.0 is scheduled to be released around April 15.

GCJ design history

Originally GCJ was designed as a “radically traditional” compiler for the Java programming language. It is an AOT (Ahead Of Time) compiler which automatically uses every GCC optimization available during compile time for a given architecture and produces binaries or (shared) libraries for the given platform. These programs run at full native speed without needing any interpreter or JIT (Just In Time) compilation. GCC is available for a large number of architectures and platforms so compiling directly to native code using the GCC back-ends makes programs written with GCJ much more portable then the traditional (proprietary) Java platform. This radically traditional approach makes all normal GNU tools like GDB available to the programmer writing code in the Java programming language just like when programming in any other language supported by GCC.

Thereafter, support for generating and interpreting byte code .class and .jar files was added. This made GCJ more compatible with traditional applications written in the Java programming language that are compiled to byte code. GCJ can be used in various modes:

Compile and link .java source files to binaries, .o or .so files.
Compile and link .class or .jar byte code files to binary.
Compile .java source files to .class byte code files (gcj -C).
Interpret .class or .jar byte code files during runtime (gij).

The byte code interpreter is included as part of the standard runtime libgcj and can be used by programs to switch between interpreting byte code and executing natively compiled code on demand. So not all of the program has to be completely interpreted or completely compiled ahead of time at the same time.

To facilitate integration with code written in other languages, GCJ defines the CNI (Compiled Native Interface). CNI makes it easy to mix and match code and classes written in C, C++ and Java by allowing you to write some methods of a class in C++ and to catch and throw exceptions directly to and from parts of the program written in different languages. GCJ also support the more traditional JNI (Java Native Interface) for using code written in C from your programs.

Anthony Green posted the original design document for GCJ from 1998.

Drawbacks of the GCJ 3.x approach

GCJ 3.x provides a good “better than Java” development environment that allows tight integration with the rest of the GNU platform. But it has disappointed some traditional Java programmers. The possibility to mix and match native code with byte code in the compiler and libgcj runtime makes GCJ very flexible. But falling back to interpreting byte code doesn't really take full advantage of the whole “radically traditional” approach. Especially programs using advanced byte code based class loader tricks used to work slowly because they fell back to using the interpreter during runtime.

There are GCJ extensions to add support for using natively compiled code all the time. But programs had to be adapted to use these extensions. Instead of using .jar files containing byte code definitions of new classes programs would have to use a new URL scheme (gcjlib:) for their URLClassLoader uses. The first “Fast Free Eclipse” port to GCJ was done this way. The source code of the plugin loading mechanism was adapted to search for natively compiled plugins in shared library .so files besides ordinary .jar byte code files. There was even a moderately popular project, rhug, that maintained a lot of patched versions of traditional free Java programs that were adapted to gcj's view of the world. But these patches were almost never adopted upstream and the maintenance of these forks took a lot of time. So the benefits of the GCJ approach were only seen by programs written explicitly for it, but not by traditional Java programs.

One of the main goals of the GCJ 4 effort was to bring all the advantages of the “radically traditional” approach to any program written in the Java programming language without needing any application-level changes.

GCJ 4 enhancements

Probably the most visible enhancement of GCJ 4 comes from merging the libgcj runtime with the GNU Classpath core class library project. By collaborating with other free runtimes like the traditional kaffe environment and around 20 other projects, GCJ 4 is able to offer a core class library comparable to JDK 1.3 or 1.4. The collaboration of all these projects on a common core library implementation means that a lot of the libraries needed by applications, except for advanced Swing, Corba and sound usage, are available out of the box. Kaffe, for example, is being used by the Apache project to track the build of most of the jakarta projects using their Gump auto-builder.

The other big change is the addition of the -findirect-dispatch switch to the compiler. Using that option causes GCJ to generate native code for classes and methods that follow the precise same binary compatibility rules as described in the Java Language Specification. This means that native compiled code can now be used everywhere, even in the most tricky class loader situations, where previously the program would fall back to interpreted byte code. At the 2004 GCC Summit Tom Tromey and Andrew Haley described this new binary compatibility ABI for GCJ in more detail.

The new binary compatibility (BC) ABI makes it possible to transparently compile programs to native code using gcj -findirect-dispatch without having to change the application source code or even the build process. To map byte code to GCJ compiled native code, GCJ 4 introduces gcj-dbtool. This tool is used by the packager during deployment of the application or library to create a database mapping the bytecode of a class to the native code during runtime. Programs can use different databases using the gnu.gcj.precompiled.db.path system property. The databases make it possible to create a cache of all native compiled code that can be shared by different programs installed on the system. The How to BC compile with GCJ GCC wiki page has examples.

This approach is used by the native Eclipse packages in Fedora Core 4. No changes to the eclipse code base are necessary anymore and, after the project is bootstrapped, all resulting .jar files are BC compiled. To almost completely automate this process, Thomas Fitzsimmons created java-gcj-compat. A collection of wrapper scripts, symlinks and jar files that provide a Java-SDK-like interface to this new GCJ 4 tool set.

Future plans

The -findirect-dispatch switch can currently only be used for byte code and not in combination with CNI (JNI is already supported). This limitation currently prevents parts of the core class libraries from being BC compiled. Lifting this restricting will facilitate more integration with GNU Classpath.

With GCJ and GDB a programmer can step through native C, C++ and Java source code using the same tool. Traditional Java developers are more used to JDWP (Java Debugging Wire Protocol) for debugging their applications. Eclipse comes with built-in support for JDWP. Work is in progress to provide JDWP debugging support for the different execution mechanisms. This code will also be shared with the GNU Classpath project.

Benchmarks show that GCJ is comparable (sometimes faster, sometimes slower) to traditional execution mechanisms for Java programs. But GCJ currently doesn't really take advantage of the new GCC 4.0 Tree SSA optimizer framework. For 4.1 the GCJ developers hope to add a couple of GCJ specific optimizations.

Tom Tromey is currently working on GCJX, a new GCC frontend that will include support for the new 1.5 language additions, such as generics. And the GNU Classpath project has a separate branch for the core class libraries that depend on the new 1.5 language additions.

Escaping the Java Trap

GCJ 4 is the result of seven years of work by a large and active community of Free Software hackers. This new version is complete enough to replace most interesting uses of the proprietary Java platform. It adds a whole new set of core libraries and adds some new features to help integration with the rest of the GNU platform. Upcoming versions of some GNU/Linux distributions will use GCJ 4 to provide much more Java-based Free Software, including Eclipse, Jonas, OpenOffice.org 2, Tomcat and the Jakarta libraries. There is also a great deal of free software to integrate with traditional GNU/Linux distributions provided by the JPackage project. Both Debian and Fedora are working with the jpackage hackers to support more of these packages “out of the box”.

All this doesn't mean that we have escaped the Java trap yet. As pointed out by Richard Stallman in “Free But Shackled - The Java Trap” we have to actively work together to keep code safe and free. It looks like the main target projects for GCJ 4 (Apache Jakarta, Eclipse and OpenOffice.org 2), have all reacted positively to the feedback and patches provided to support free alternatives to the Java platform. The fact that the changes requested were for making the projects more portable ("don't use undocumented com.sun internal classes") rather than requests to dramatically change the code, (core) libraries used or build infrastructure has helped a lot. But the above projects were already free software projects at heart. It remains to be seen if other more traditional java projects will adapt so easily to support GCJ 4 out of the box.

Index entries for this article
GuestArticles	Wielaard, Mark

to post comments

A shamei

Posted Apr 7, 2005 4:48 UTC (Thu) by ncm (guest, #165) [Link] (35 responses)

It's sad to see so much sterling Free Software engineering effort going into support for a doomed, proprietary platform. (One might say the same of Samba.) Very little of Free Software is written in Java, aside from what might be used by those already obliged to use Java, but that's OK. The proprietary world is positively mired in Java, and will need a lot of help to get Free. They will need a migration path. GCJ will offer them a way to engage with the mainstream of software development, enabling link-compatibility with public-standard languages.

Whenever Sun decides that Java is no longer strategic, the Java world will wash up on shore. It's good to have the refugee camps already under construction, and the rations stockpiled against that day.

A shamei

Posted Apr 7, 2005 7:39 UTC (Thu) by Xman (guest, #10620) [Link] (21 responses)

Sigh. It seems like every time there is an LWN story on Java there is a post saying that hardly any free software is written in Java. Take a look at sourceforge. There is a *lot* of Java code out there, and that's despite the fact that a number of open source developers choose not develop in Java simply because there isn't an open source version to work with.

A shamei

Posted Apr 7, 2005 10:23 UTC (Thu) by zooko (guest, #2589) [Link] (20 responses)

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.

A shamei

Posted Apr 7, 2005 10:40 UTC (Thu) by faassen (guest, #1676) [Link] (12 responses)

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 shame

Posted Apr 7, 2005 12:36 UTC (Thu) by ncm (guest, #165) [Link] (3 responses)

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.

Lists of packages

Posted Apr 7, 2005 13:07 UTC (Thu) by mjw (subscriber, #16740) [Link] (1 responses)

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.

Lists of packages

Posted Apr 7, 2005 23:54 UTC (Thu) by Xman (guest, #10620) [Link]

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.

A shame

Posted Apr 7, 2005 18:06 UTC (Thu) by jonabbey (guest, #2736) [Link]

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

Posted Apr 7, 2005 12:44 UTC (Thu) by zooko (guest, #2589) [Link] (7 responses)

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 shamei

Posted Apr 7, 2005 14:17 UTC (Thu) by kfiles (subscriber, #11628) [Link] (2 responses)

<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

A shamei

Posted Apr 7, 2005 14:25 UTC (Thu) by zooko (guest, #2589) [Link]

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

A shame

Posted Apr 17, 2005 3:13 UTC (Sun) by jae (guest, #2369) [Link]

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

Posted Apr 7, 2005 14:42 UTC (Thu) by ncm (guest, #165) [Link]

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

Posted Apr 7, 2005 15:20 UTC (Thu) by yodermk (subscriber, #3803) [Link] (1 responses)

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.

OpenOffice.org 2

Posted Apr 7, 2005 23:55 UTC (Thu) by mjw (subscriber, #16740) [Link]

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.

A shamei

Posted Apr 7, 2005 18:56 UTC (Thu) by oak (guest, #2786) [Link]

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 shamei

Posted Apr 8, 2005 0:31 UTC (Fri) by Xman (guest, #10620) [Link] (2 responses)

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.

Missed the obvious one

Posted Apr 8, 2005 0:35 UTC (Fri) by Xman (guest, #10620) [Link]

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

A shamei

Posted Apr 18, 2005 17:54 UTC (Mon) by Jyhem (guest, #29388) [Link]

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

Look again...

Posted Apr 20, 2005 3:26 UTC (Wed) by bert.kenward (subscriber, #28573) [Link] (3 responses)

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

Look again...

Posted Apr 20, 2005 8:26 UTC (Wed) by zooko (guest, #2589) [Link] (2 responses)

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...

Posted Apr 20, 2005 8:29 UTC (Wed) by zooko (guest, #2589) [Link] (1 responses)

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...

Posted Apr 20, 2005 9:34 UTC (Wed) by zooko (guest, #2589) [Link]

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.

Why all this hostility?

Posted Apr 7, 2005 17:03 UTC (Thu) by ohanssen (subscriber, #2761) [Link]

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?

A shamei

Posted Apr 7, 2005 17:03 UTC (Thu) by AJWM (guest, #15888) [Link]

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.

A shame

Posted Apr 7, 2005 23:27 UTC (Thu) by giraffedata (guest, #1954) [Link] (10 responses)

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?

A shame

Posted Apr 8, 2005 2:30 UTC (Fri) by ncm (guest, #165) [Link] (9 responses)

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?

A shame

Posted Apr 8, 2005 3:03 UTC (Fri) by giraffedata (guest, #1954) [Link] (2 responses)

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

Posted Apr 8, 2005 9:42 UTC (Fri) by hmh (subscriber, #3838) [Link]

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

Posted Apr 8, 2005 16:12 UTC (Fri) by ncm (guest, #165) [Link]

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

Posted Apr 8, 2005 9:28 UTC (Fri) by Xman (guest, #10620) [Link] (5 responses)

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

Posted Apr 8, 2005 15:10 UTC (Fri) by jonabbey (guest, #2736) [Link]

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

Posted Apr 8, 2005 16:03 UTC (Fri) by ncm (guest, #165) [Link] (3 responses)

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

Posted Apr 8, 2005 23:05 UTC (Fri) by Xman (guest, #10620) [Link] (1 responses)

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

Posted Apr 11, 2005 4:02 UTC (Mon) by ncm (guest, #165) [Link]

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

Posted Apr 15, 2005 20:31 UTC (Fri) by renox (guest, #23785) [Link]

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.

GCJ - past, present, and future

Posted Apr 7, 2005 7:17 UTC (Thu) by Per_Bothner (subscriber, #7375) [Link] (1 responses)

GCJ 4 is the result of seven years of work ...

Actually, more like eight and a half years. The earliest ChangeLog entries are from October 1996. It's almost as old as Java itself - the first editions of the Java Language and VM Specification are from about the same time.

GCJ - past, present, and future

Posted Apr 7, 2005 9:07 UTC (Thu) by mjw (subscriber, #16740) [Link]

My appologies. I will learn to count better.
And thanks for that very first entry on 24 October 1996.

Good Article

Posted Apr 7, 2005 11:32 UTC (Thu) by rmathew (subscriber, #20961) [Link] (1 responses)

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. :-)

Good Article

Posted Apr 7, 2005 23:26 UTC (Thu) by tjc (guest, #137) [Link]

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.

Great article

Posted Apr 7, 2005 16:25 UTC (Thu) by b7j0c (guest, #27559) [Link]

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.

GCJ - past, present, and future

Posted Apr 7, 2005 19:09 UTC (Thu) by iabervon (subscriber, #722) [Link] (1 responses)

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.

GCJ - past, present, and future

Posted Apr 7, 2005 23:44 UTC (Thu) by mjw (subscriber, #16740) [Link]

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.

GCJ - past, present, and future

Posted Apr 21, 2005 8:16 UTC (Thu) by toren03 (guest, #29443) [Link]

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