Posted
by
Hemoson Wednesday February 16, 2000 @04:07PM
from the credit-where-it's-due dept.

burner writes, "After quite a wait, JDK1.2.2 is released for Linux. You can grab the final release from Sun's site. Sun has also put up bios for the Blackdown guys. Sun's been acting pretty flippy lately, but this is great news. I've been using Blackdown's latest release candidates lately, and they're excellent, but now there's a final release. Nice work guys! "

I'm very pleased to see this and to see Blackdown getting credit. I have been hoping to use Java on Linux for a distributed network-of-computers project and this release makes the whole thing look more "polished" then using an RC.

Upgrade away, this should be a very stable release seeing as Blackdown doesn't seem to relaese flaky code. The betas were very stable and I have been happily developing with them for quite a while. Now onto java 1.3, 3 or whatever it will be called:)

Yeah it looks as though Sun finally pulled their heads out of their asses on this one. Now if they would only do the same with StarOffice and the SCPL I might actually be convinced to no longer speak disparingly about them.

It's so disappointing to still see Java so fragmented across platforms. The 'Linux' release is only officially supported on one processor and increasing the officially supported OS's by 50% has been like pulling teeth. It's not the end-all-be-all of languages, but two years ago I had hopes that by now it would be faster and more pervasive than it has become--especially outside the browser cage. Such a shame... mh

Java development is growing daily. The speed with which Java applications and servlets can be developed is unprecedented. The speed issues with Java are decreasing with each release, and 1.2.2 is pretty quick. The 1.3 early-release 1.3 JRE is quite a bit faster, and Blackdown is already working on the port.

This is very good news for Linux, which, as you may have noticed, a few/. readers seem to care about. If you wanna bitch, try posting at http://dev.null.com [seanbaby.com].

Offtopic: If you don't have an X-server, JavaLobby posted a story about a very nice GPL'ed Xserver/Esound/Truetype server written in Java at called WeirdX [jcraft.com] Even runs as an applet. Very nice if all you have is a Windows/Mac box, or are at a public terminal/cybercafe and need to remote-X from your Linux box.:) Mostly impressive because a single guy wrote an X server from scratch in a short period of time.

You may be interested to find that the final release does not (currently) include a JIT JVM, because they were using Inprise's and that's not yet certified. You can download it seperately though.

There was a JavaLive chat [sun.com] yesterday about the Java on Linux stuff. They haven't put up the transcripts yet though.

For Java 1.3 from Sun, the Windows version will come out first, then Solaris then Linux. However, they do want to syncronise all releases together and should do this at or before Java 1.4 - might happen first for a maintenance release.

How does this compare with anyone else's Java 2 for Linux? I know there are some out there.

That's not to insinuate that there's anything bad about Sun's version of Java. Other than it has a history of being the slowest. (Jikes leaves Sun's v1.1 compilers trailing in the dust.)

Also, now that Blackdown have it ported to Linux, will it be ported to different Linux processors? Or just ix86?

I can't see why it should be anything beyond a simple recompile, to get binaries for all the Linux platforms, and compilation speed isn't an issue, as you're not looking to debug the logic. Emulators, such as the ARM emulator, and cross-compilers, should be fine in producing Java 2 for Linux for every platform it runs on.

I admire the Blackdown crew, and the work they've done to get the JVM working under Linux. Unfortunately however, its not something I can use to write a professional application if I expect it to work properly.

I've done a lot of Java development under Linux this year, and I've noticed several things that prevent me from doing serious work with Java (under Linux). For example, rmiregistry crashes without fail for any type of heavily loaded RMI project. Another example is that Thread objects break just as easily, or refuse to start altogether when you spawn multiple Threads (even if there is plenty of memory available). Luckily I have access to a cluster of Ultra5's to test my applications on, which execute almost flawlessly (I've noticed a few quirks with Threads under Solaris as well, but not nearly as bad as under Linux). I see the state of the JVM under Linux as being close to a toy. I know all the Blackdown people will probably find this insulting, but unfortunately, I can't do hard-core Java the way I can under Solaris. I do not blame Blackdown in any way for this however. I feel that this is solely Sun's fault. Thats my $0.02 on the issue. I love Blackdown, I love Java. Bugs suck.

I'm writing servlets for my current project. The "Powers That Be" had concerns about Java support on Linux (no official release, etc., etc., etc.), so they went with HP-UX. (Don't ask.)

If they would've known the amount of time I had to struggle with getting GCC loaded and config'd for the HP, just so I could then compile Apache, just so after that I could compile JServ, just so I could *then* use an "Officially Sanctioned" JDK....

Has anyone gotten Jini and Javaspaces to run? I'm taking a class that has an assignment to write a "distributed" program using javaspaces, and I've been trying to get the examples to run using a release candidate... needless to say, it bombs out, and I don't want to attempt this project in Win98... Thanks!

As people who have been following the development of JDK 1.2 for Linux will know, the Sun/Inprise and Blackdown porting efforts have been taking place in parallel for the past while, and each group has produced a different port.

My experience has been that Blackdown's port was faster and more stable than Sun's. Now that Sun's port has been officially blessed, I imagine it will have the stability edge for a little while, but I will continue to use the Blackdown port for its superior performance.

I think the implication of your post is much more interesting than just 'java doesn't run well on linux.'

What this (teir-1 support for solaris, goat-blowing support for linux) mostly accomplishes is continued degradation of a core-value of java: write once, run anywhere. Not only does it not work, it hasn't ever worked, and even if it does work, it doesn't work well enough to be useable in the Real World.

So, as usual, instead of disparaging linux and the blackdown crew, I think it's important to keep the blame right where it belongs: on Sun. If they REALLY wanted Java to be a ubiquitous standard, they'd release it all and let the people who do the work have at it.

All in all, NOTHING works perfectly across all platforms, not/bin/sh scripts, not perl, hell, not even terminal emulation. But the projects which are most open seem to have the most luck with being truly portable.

Optimization is irrelevent. It works under Solaris and NT, therefore it should work under Linux. Optimizing specificly for Linux goes against everything Java stands for. The fact is that RMI under Linux is severely crippled.

I hate to have to break this to you, seeing the amount of work you've already had to do, but JServ isn't it any more. The new reference implementation for servlets is Tomcat from the Jakarta Project [apache.org].

...the real problem isn't the warm-and-fuzzies, (although there's no underestimating the importance of people's feelings). The real problem is that Java is not open-source, and the stewardship of Java standards/apis is not open. The earlier slight to the Blackdown team was just a symptom, the real disease is Sun's unwillingness to let go of their baby and let it grow up into an adult. The result is that Java is still running largely with training wheels. Who wants to see how well the sandbox works when there are precious few applications worth running? Who wants to run an app that is theoretically pleasing but is, in practice, slow and kinda ugly? And not 100% stable? We can fix all that, but not under the current conditions. If things continue as they are, yes, progress will happen, but it will be sloooooooooow... maybe *too* slow.

I don't want to sound ungrateful, but... when are you going to drop the other shoe, Scott???

I've been using 1.2rc3 for some time on an intranet site using a bunch of servlets/JSPs. Works like a charm. 1.2 JVMs are SOO much easier to use and configure than 1.1.x JVMs. They're much more intelligent about using.jar's, etc. The performance is also quite good, especially with Resin (www.caucho.com). No, I don't work for them, but I'm incredibly impressed by their servlet engine. It also has a cool feature that compiles JavaScript (in JSPs) to real Java bytecode. Plus a lot of great utility classes (like automatic database connection pooling, and XML support). I highly recommend checking it out. We're running an app on a $400 Linux machine and the response is basically instantaneous, even with multiple database queries. --JRZ

The last Blackdown release had a wobbly JIT and native-threads that were just plain broken. To run Netbeans, I had to disable the JIT and switch to green-threads - in other words, to turn off anything that makes Java run faster than molasses. Is this fixed in this release? Is there infact any real reason to upgrade from Blackdown 1.2.2 RC4?

As far as I'm aware, Sun's "official Linux JDK" is *not* the same as the Blackdown release - this is still the Sun/Inprise release. Sun *have* given Blackdown some credit for the port since the Sun/Inprise version is based on an earlier version of the Blackdown codebase, I assume they have miraculously managed to learn from their earlier mistake.

An important distinction between the two is that the "official Sun JDK" does NOT support native threads and in fact recommends NOT running it on SMP machines, while the Blackdown release does native threads and SMP just fine.

Its completely true. We all know that Sun has a grudge against Linux and OSS in general, and this is just a good example of how they don't want to participate. It really is a shame though, because the potential for Java is huge, so long as things are done correctly; unfortunately they're not.

OSes are not the end-all-be-all of Java, either. example: a modular reconfigurable robot from Xerox-PARC called Polybot [xerox.com]. (if you were at comdex and caught John Seeley Brown's keynote speech, you saw it. there have also been lots of print, online, and TV pieces on it) it runs on PowerPC chips running compiled Java.

there are lots of embedded Java things coming out now that run embedded Java. remember that the original demo for the language (if I remember correctly) back when it was called Oak, was a bulky TV remote control.

Lea

Warning: the Polybot link will take you to a page that my Mozilla M13 will render and then turn blank grey. I have no idea why, but you might want to try Netscape instead. (or IE, if you're that sort of person)

I wrote a Java program for my son to use. Supposedly, it puts pictures of animal pictures on the screen, plays a sound clip, and a person is supposed to click on the picture of the right animal. Programming it was a dream. Easy! Not much code.

The problem: It doesn't run the same on any 2 platforms that I've tried. It doesn't run the same twice on any single platform. You never know which thread will run first. Sometimes the sound comes before the pictures appear (which is not the order it's programmed). Often, it doesn't load the images when I tell it to, and sometimes it doesn't load one of the images at all. The only way I could keep it from playing 2 sound clips at the same time was to specify a sleep the duration of the 1st sound clip. This happens with 4 different JVMs and operating systems (no Sun platforms) that I've tried. And, of course, it often crashes.

I have given up on Java. The point was to make a cross-platform program that non-Linux users could use, but if it only runs well on Sun products, forget it.

Not being a Debian user, I guess I can't say for sure (maybe there's some weird issue that I'm not seeing). However, if you're worried about being able to unistall easily, you shouldn't be (worried that is). Beyond using tar to create your/usr/local/jdk1.2.2/ directory, and modifying your environment variables, there's nothing more to do. To get rid of the jdk, just remove jdk1.2.2 directory.

I have three different jdk's installed under/usr/local/ and it makes it very convenient to switch between them by simply changing my environment variables.

Java is an appopriate choice for many kinds of games, but not all. First-Person shooters would not be a good class of game to do in Java; they are so resource-intensive and speed-critical that the performance hit of running on a JVM would probably be unacceptable. However, many other types of games would be great on Java - multi-player turn-based strategy games (Like Civilization II [civ2.com])would benefit from Java's strengths. I think that pretty much any game that isn't dependant having a high framerate to be enjoyable could be done in Java with no noticeable degradation to playability."The axiom 'An honest man has nothing to fear from the police'

I was once very excited about java. Did a fair amount of development under Java 1.0, Java 1.1, and Java 1.2, before we as a company decided to dump the product because of Sun's mismanagement of the standard and their lackluster support of the Blackdown group and Linux in general. This may have changed for the moment, but for us (and I suspect many others) it came far too late to be of much use (c.f. "sun sucks").

Performance may now be acceptable, but at the time we dumped the product even a small, simple data entry application was too demanding of the JVM at the time (even on Sparc 10's running Solaris, much less Linux). The choice Sun gave us was stark: run the Java VM under Windows or Solaris on a high end sparc, or suffer. We chose Linux, adopted a more open development environment, and now having dumped the product we will not, in the future, ever consider going back (c.f "sun sucks" and "slow"). Using GNU configure and its associated utilities, we are able to get all the cross-platform support we require, even if it involves a quick rebuild of the sources (typing "./configure" and "make install" isn't terribly difficult) with the performance our users demand and languages we can hire developers for (c.f. "use Perl" and "Java sucks").

I enjoyed using Java (despite the, even now, still horrificly screwed up date and time classes) as a language, but the drawbacks were too severe and too critical for too long of a time, and Sun's current and future motives with respect to the openness of the standard and support for Linux, FreeBSD, and whatever other platform we may, in the future, chose to deploy, has eroded our confidence in the product too much for us to seriously consider any future use of Java. Put simply, the stumbling blocks Sun until recently put in the way of development on anything other than their "blessed" platforms far outweighed any advantage the language itself offered (and those were not inconsiderable for those of us coming from C++, with Java's simpler memory management and garbage collection and other features).

Alas, the promise of "write once, run everywhere" quickly became (and IMHO remains) "write once, run where Sun would like you to." At present Sun has chosen to become mildly friendly towards Linux. This is great! However, I would not expect this to remain a long term strategy on their part, unless there are some serious changes in the mentaility of Sun's upper management. (c.f. "blah blah blah").

I just tried it (weirdx). I downloaded the 1.2.2 JRE from sunsoft, and uploaded the weirdx-*.html files to an http server, as well as the jar file... got nothing but starting java applet and a white screen.

Java never seems to work right for me.

At work we are using a java program (running through X in this case), and it crashes about 50% of the time when you try to start it. This is running on HP/UX.

In other words, I'm not impressed with Java so far. But that weirdx LOOKS really awesome. What am I doing wrong?

Now, how about an alpha (AXP linux) port? Due to childish feuding between the Blackdown team and "Uncle George," the guy originally doing the alpha ports, there is still not a decent JDK for my lab's Linux/alpha systems. (I don't even know which side started it, just that the result is very disappointing to those of us who want the port). I'm sure Sun could clear up that problem pretty fast with some strategically applied cash. Of course, if they released their JDK as free software, somebody might do the port for them, but their license is another issue.

It doesn't surprise me that Java on Solaris would be more stable than Java on Linux. I run my (large!) RMI server app on Solaris under Java 1.2 and under Linux under 1.1.7/8, and it works fine in both places.

Perhaps you are doing very fine-grained RMI object exporting? One thing I learned fairly early on is that it is important not to have all of your RMI objects inherit from UnicastRemoteObject.. if you do that, then your objects are automatically registered for export on creation. Much better to use the static UnicastRemoteObject.exportObject() method to export your Remote-implementing object only when needed.

Actually, now that I think of it, I only actually register a single object in the RMI registry.. my top-level server object. All further RMI activity is done using returned references to RMI-exported objects.

What sort of architecture are you using in your program? Which versions of the JDK have you been seeing problems on Linux with? What version of glibc do you have installed?

You may want to brush up on multi-threaded programming- what you describe is exactly the way it is supposed to work (i.e. the order of thread execution is not guaranteed).

It sounds like you've seriously overdeveloped your app- if you're doing things sequentially, why put the actions in seperate threads? If you actually need threads for something, can the UI functions you describe be in one thread? Perhaps you should sychronize things using events.

YMMV, but I daily do development between 98, NT, Linux, and Solaris (on an UltraSparc) with Java and my code works the same on all platforms. Of course, I'm only doing Server Side applications and am not using AWT or Swing.

I'm not saying Java is all the hype made it out to be. In fact, all of the hype probably did more damage to Java over the long term than helped in the short term, but overall as a language it's not too shabby. As always, you should use the right tool for the job- maybe it's Java, maybe it's C, maybe it's Perl, maybe it's VB or Delphi. Depends on what needs to be done.

For the record, I've never been able to get a client side application using AWT or Swing to work the same between implementations.

Optimization cannot be irrelevant. Yes, it would be nice if the Linux OS and JVM scaled in all the same ways as a certain JVM on Solaris or NT does, but that's not realistic. The Java Language Specification makes no guarantees about threading semantics, let alone scaling and performance issues.

Write Once, Run Everywhere works surprisingly well, all things considered, and it's getting better. It's not a panacea, though. You do have to test your software across several JVM's and in various memory, threading, and loading conditions.

All of which you know already, of course. Just don't curse Sun (too much)for not attaining perfection when they've got a better portability story than anyone else does today.

I wasn't very explict I guess. What I'm really lamenting is a pervasive, cross-platform, in-sync environment to RUN java apps in. I do understand where it has been really successful as a language/platform. As another example, it will be exciting to see if Mac OS X really succeeds in fully integrating it as a first-class development language in a popular OS.

However, many spiffy add-on APIs (not only from Sun) are only really supported on those platforms that Sun supports. Admittedly some are inherently difficult to support well cross-platform (Java3D for example), but without even core Java in sync across platforms even simpler packages quickly fall away from non-Sun platforms.

As a mostly high-level language programmer, I really enjoy programming in Java. It also had (has?) the potential to close the cross-platform app gap. Aside from some gee-wiz items and small utilities, that vision (delusion?) seems to be mostly dead for now. It certainly has been a success, but just not where I was looking:)

Non native java code, compiling to native code does not offer much performance advantage (contrary to what people seem to believe) since it does not eliminate the real bottlenecks (garbage collection, memory allocation, synchornization, etc.)

In real simple terms, HotSpot is a run-time optimizer for bytecode. It sees what pieces of code are getting used over and over (hot spots) and optimizes them - in a way that I believe is similar to storing data in registers instead of memory; whatever that means in JVM parlance.

Let me correct myself. The JLS obviously does say a lot about threading semantics, just not enough to specify whether threads are even pre-emptive under Java, let alone map to native threads or across processors on an SMP box.

If you are extraordinarily careful and use synchronization primitives with care, you can write code that will function (however slowly/poorly) even in a very limited threading environment.

I am currently employed in the telecommunications industry working on a SNMP administration tool written in Java. We started with JDK1.2.1, moved to JDK1.2.2, and are now developing with JDK1.3. With JDK1.3 our application blazes onto the screen in under a second, whereas with the earlier versions it took substantially longer. Good work Sun! Blackdown, I can't wait for the port.

Actually, I want them to get on the ball with all the supplimental stuff -- Media Framework, Advanced Imaging, 3D, and the plug-in (and make sure the plug in and mozilla milestones work together.

Basically, there are still a number of "Java" pieces that have native code that needs to be ported. If Blackdown doesn't have the resources to do the work, then someone else needs to step forward to get it done.

What makes it even greater is that there is still no JDK 1.2.2 production release for Solaris, only a 'reference implementation'. Production release for windows has been there for a year, now we have it for Linux but where's the Solaris version?

And now, submitted for your disapproval, the dark path I have trodden since 1993:

I don't like to admit it in public (especially here!), but I've used VB since v1.0 When I started using VB, I was working in a shop where the tool of preference was Clipper '87; an xBase compiler. VB 1, as broken as it was, was an improvement over that. Unfortunately, I have so much VB experience now that I keep getting shanghaied into VB projects when I'd rather be coding in Java. VB is the Dark Side of programming -- once you start down the dark VB path, forever will it dominate your destiny.

The most common complaint I hear about Java is "It's too slow. Use C/C++ instead." I don't think it's appropriate to compare Java to C/C++, even though Java is (in many regards) the decendent of C++. It is far more appropriate to compare Java to 4GL's like VB and PowerBuilder, as Java has much more in common with those languages than it does to C and C++. Java is pretty mature for it's age. Yes, it has problems, but so did every other language early in it's life.

Java would benefit a lot from being Open Source. IMHO, Sun should spin off a non-profit subsidiary to manage Java, patterned after the Apache Software Foundation. Apache is probably the most successful Open Source project to date - even moreso than Linux; no other open-source project I know of has over 50% market share in it's category. If Sun were to allow Java to develop the way Apache and GCC have evolved, it's problems would rapidly disappear.

Preemption is allowed, yes, and there are guaranteed atomic operations (reference and integer assignment, at the very least). That's why I backpedalled and said that the JLS did indeed have guarantees on thread semantics.

It just doesn't have any guarantee as to when a particular thread will be run, nor whether a thread will ever be switched unless the active thread comes to the end of its execution or to a wait() call. In practice, every JVM that I care about will do those things, and I don't bother seeking out a Palm Pilot or Win 3.1 JVM to test my code on, but in theory it's something to be aware of.

It just so happens that this is being done: http://come.to/JavaNetHack [come.to]. work seems to be dreadfully slow, but maybe someone can lend him a hand or something... BTW, more roguelike java projects can be found on Roguelike News' Links Page [demon.co.uk]. Enjoy!-Ravagin "Ladies and gentlemen, this is NPR! And that means....it's time for a drum solo!"

Do not you do memory management when coding in C++? Only by hand and error-prone. Your code spends 80% of its time withing like 10% of the program. If you do not create and dispose of too many objects in there - GC overhead is negligible and well worth it. REal bottleneck in Java for me was its floating point performance. I can not use GCC now, for lack of features, but I would expect it will alleviate this..

The thread problems aren't a Java issue. Thread execution order is nondeterministic and often seemingly random. To blame this behavior on Java is to not understand multithreaded programming. Remove the threads and you won't have that problem.

I've been programming in Java ( using CORBA and RMI ) on Linux for ~2 years now and it's been great. It's had its problems to be sure but it's not as bad as some here are making it out to be. We've had significant loads and high numbers of objects going back and forth from our servers and Java has worked like a champ.

I didn't know this before I read these news, but now I do: I needed a good JVM for Linux in order to competely switch my focus from C to Java. I will certainly continue working in C, but less and less. My company does a lot of Java developement (on HP UX and NT), but I wasn't very motivated to join R&D with Java. Now I am!

That's funny! Seriously, though, Java 2 v1.3 combined with Sun's Java3D implementation is suitable for writing games with high quality 3D graphics and sound. Java 2 v1.3 code often runs nearly as fast as C++ compiled code. The catch is that the 1.3 version (actually 1.3 release candidate 1) implementation with hardware 3D acceleration is only supported on Windows platforms, not even on Sun's own Solaris OS! Sun claims that the JDK 1.3 for Linux will be out sometime late in 2000.

Really, the README says that only green threads are supported and running under SMP kernels is discouraged. Given the resources Sun has to do things right, this can mean only one thing: it's their way of saying "Linux is OK for single-user toy usage but for high-end SMP stuff just get Solaris, OK?". This is more a PR release "We do Linux, we want our stock to go up" than the REAL thing.

I hope IBM will bring out a SMP-supporting JDK2 SOON! Their 1.1.8 is wonderful and fast. Are you listening, IBM?

Normally, I'm pretty happy when something new comes to Linux, however in this case I'm not sure if I should be.

It is about time Sun got decent Java support to Linux. I know that they'd rather spend effort on working on their own OS, but if they truly want a language that is portable to all systems, they need to make sure it actually works on all systems.

Now for the negative side. My experience with Java screams that the language is in need of much work. It runs slowly. It requires you to look up the APIs constantly anytime you want to do something useful, and it just doesn't get the job done as well as C/C++. It has a place, but I'm not sure that it is really the greatest tool for Linux programmers when compared to C/C++/Perl/Whatever. Still, the idea of "crossplatform" is nice.

If you're not satisfied with the proprietary nature of Java on Linux, you should contribute to GNU Classpath [classpath.org], a set of clean room classfiles that attempts to support Java 1.1, and possibly 1.2.

It's in a early stage right now (version 0.0), but should more people hack on it, we can say bye-bye to Sun.

Umm? It did work. Once that blank screen goes up, go to a Unix box somewhere and run "xterm -display yourmachine:2.0" and the xterm will appear in that applet window. You shouldn't run it as an applet anyway, read the README and launch it from the command line as a Java Application. I had KDE with Enlightment to run through it back to my NT box.

work seems to be dreadfully slow or the game seems to be dreadfully slow:-) they probably got tangled in the no-multiple inheritance mess that is java OO and had to flip their code inside out to get what they wanted (can you tell I'm bitter), but seriously, I would like to see more java games so I could crank them up on the Sun and the Alpha and the p3's and have a real in-house fragfest.

Wes, I'm glad to see you say this (as someone who has been supportive of Java in general) -- I've personally been burned by this to the point of using Mozilla for portable deployment: even with changing API's and alpha-level code Mozilla is more "write once run anywhere" than Java for desktop apps. Of course, few people take me seriously when I say this, but then again, we are able to deploy now thanks to Mozilla, where we *still* wouldn't be able to if we had stayed with Java.

I followed your link and you are right, towerj is on top. But what does that say really? IBM is a very close second and they don't compile to native code. Above all, this version of IBM's VM runs on NT and towerj runs on linux.

A closer examination of this benchmarks reveals that it tests socket IO and threads. The performance of both is very much dependend on the OS.

Furthermore, I think a benchmark that stresses the OO usage of Java a little more (i.e. creating destroying objects) would show a different picture.

This benchmark does not proof much to me. A benchmark that doesn't take typical OO behavior of a program into account is not realistic, even for server side programs.

... since languages aren't software. Implementations of the languages can be open-source, though, and some are.

Thankyou for pointing that out, I'm always appreciative of a good niggle in place of an intelligent comment (*sarcasm off*)

the stewardship of Java standards/apis is not open

... just like C++ et al.

Huh. That's not so. ISO is a public body, the standards are open to real public review, and you can join the working groups if you want (if you've time and money to travel, that is). Try to join one of Sun's api committees. Try to even identify an api committee for Java, let alone a public one. Do you get the picture?

Except that you can go to Sun's site and download their official specs free of charge, while getting ISOs specs for "their" languages will cost you an arm, leg and your daughter's hand in marriage.

So? The specs haven't been kept up to date (check for yourself). And have always been incomplete. The specs somewhat lame in a lot of places, too. For example, hardware api's sucked from the beginning, they still suck, and from the look of things, they are going to continue to suck forever unless something drastic changes in the API development process. About the only hardware Sun has created an api for is the mouse. Show me how you support a joystick in Java, for example. It's a big world out there and Java as it stands just can't deal with a lot of it. Don't talk to me about native code interface either: hardware support is pretty much useless in Java unless it exists on every platform, and it's now so late in the game that even if the api's were fixed it would be immensely difficult to deploy the new support widely enough so that application writers could write to it with confidence.

Sun's unwillingness to let go of their baby and let it grow up into an adult.

How long did it take for AT&T to let go of C++ and leave it to "grow" in the vats of ISO's JTCs?

We haven't got that much time to wait. At the current rate, Java is going to be a dead issue by the time Sun wakes up. It's going to be killed by something more useful, and more open, without one, self-interested company trying to dominate it. All I can say is, thanks Sun for giving Bill a few sleepless nights, but really, another proprietary solution is not what the world wants and it's not going to accept it. Many programmers are now using Perl and Python for applications where they would have looked seriously at Java. Python and Perl both work better than Java on Linux, they're faster to develop with, they start faster, easier to debug, more useful libraries, more code developed by other people that you can leverage, etc. etc.

Do you really feel ISO's process has been to the advantage of the language? A single, steering body is always better, whether that body is called Sun or Guido von Rossum.:-)

Then lets have a single steering body, but let that body be chosen democratically, and by merit. As far as I'm concerned Sun has dropped the ball.

We can fix all that, but not under the current conditions.

It seems you want Sun's source instead of working on the OSS projects already running, like Kaffe. Why?

Kaffe is nice. Kaffe is fine. I admire everybody that works on Kaffe, and Blackdown too for that matter. But Sun is passively resisting Kaffe and other Java-clones (by withholding important specifications and compliance tests) to the point where it is very difficult to be sure whether Kaffe is Java-compatible or not. That's evil.

This annoys me, because I'd use Java for a number of things if it weren't such a sluggish, unreliable memory hog. (Which is exactly what it is when you try to run, for example, any Swing program.) Personally, I'm not contemplating using Java for any serious development at this point whereas two years ago I was full of enthusiasm for the idea. Perhaps there are others like me?

It seems to me that you just want to keep things the way they are. Well, it isn't working, that's plain for all to see. Look at the way Linux is leaving Java in the dust as a cross-platform vehicle for delivery of net-enabled applications. That's what Java was supposed to be. Linux has already stolen a lot of Java's thunder, and it will steal the rest unless Sun smartens up fast.

No, dillwad AC loser, we are using XUL and writing our own XPCOM components using NSPR, and delivering our "content" along with integration to our network services (almost hard to explain without showing the product). We are tracking the changes in Mozilla and the product works better now than it could work with any extant Java system (particularly when WORA practicality is a factor). The product won't be available for another couple of months, but we are already in testing.

Yeah, wiseass, I've heard of implements, and delegation, abstract base classes and factories, and design patterns, and UML, and all the other supposed means to get around Java's problems. Fact is, Java has them, and for any large scale project overall implementation time is increased over other common procedural and/or OO languages due to the fact that the design phase of a large project is longer than for other languages (due to the narrow ways that you are allowed to express designs in code). All that for a not-quite-portable slow language?