Slashdot Mirror

Agreed that the list is skewed towards game programming, and java isn't the place to be for bleeding edge games, however there is a java games community, and more specifically an eclipse games community.

Note - I am not a games programmer, however given some of the solutions listed ( I mean, I used to love chipmunk basic but I'm not going to use it these days ) I thought eclipse should have been pointed to. Eclipse on mac doesn't seem to be as big as eclipse on linux / windows ... I was guessing this was the cause of the overlook (or maybe they hate java (-; )

I probably went too far in directly equating the two, but this critique of Sun's JRL mentions some of the ways IP protection can effectively freeze research.

12. Am I required to keep my research "java compatible?"

No. The license encourages you to innovate and experiment using the java technology core. It is expected that research implementations will not be compatible with the Reference Implementation from Sun. This is ok.

13. Can I publish my source code at a conference, and in white papers?

Yes, you may publish your work in the usually accepted academic manner as long as you reference the Java Research License and include the correct copyright information.

14. Can I share my modifications with other researchers?

Yes, provided that the other researchers have accepted the JRL.

I might not be your regular open source hippy, but I feel that anyone that has taken the time to create software or whatever has the right to define the terms upon how it is used. Sure, the community has given a lot back. Some (can't find the link, but it was mentioned on slashdot some time ago) even argue that if it weren't for this Sun would be out of business by now. So it's a bit of giving and a bit of taking. This seems like a great gesture from Sun.

No, people say things more like, "companies, like Microsoft, Hashcash, and Goodwill Systems, are more interested in making money off of the volume than in solving the problem." Microsoft has earned distrust again and again. It's not what they say, it's what they do that counts. People can see and remember how Microsoft performs. That they rarely do what they say is more of the same as well.

Microsoft's junk is patent encumbered and is not suitable as a standard. That would apply regardless of the company.

In Microsoft's case, it's more outrageous because their software has already failed to compete in the marketplace. Sendmail, Exim and others are what moves email and M$ has nothing to do with it. Indeed, their greatest success produces generates 80% of the world's spam. This bout of standards manipulation is an attempt to foist inferior software onto people with better judgement and charge them for the mistake.

I'd be happier if they concentrated on fixing whats broken rather than breaking what other people do that works. They are the problem, not the solution. Can you imagine what a field day the spammers would have if every mailserver was running some kind of M$ OS?

This is fairly easy to implement. Sun has libraries and classes for accepting all syndication formats called Rome https://rome.dev.java.net/. We just dropped it in at our site http://www.arctechnologygroup.com/dojo/arctg/v.jsp ?p=/solutions/rss.

Would you mind being a bit more specific about why, as you claim, The X Window System is one of the "those big reasons" people don't use Linux on the desktop?

Not my topic - but I'll jump in here anyway.

I use to be under the impression that the X Window System was superior. But in the last couple of years I have done a 180 on that.

According to this guy, the very aspect that made X so cool 20 years ago (network transparency) is now it's biggest detriment. I'm not saying his word is gospel, because I have no idea who he is. But the article makes a lot of sense.

Also, for the life of me I can't figure out why my X Window System is so freaking slow compared to Windows.

Huh? One of the reasons I got started on Linux was that I could remotely display apps to my box!!! X-windows rules for that reason alone!

It's also the reason that The X Window System is as "slow" as it is.

My bug was marked as a duplicate of your bug and closed. I can't even find my bug in there anymore.

Their FAQ says: Some bugs are not included in the Bug Database for security reasons.

Umm, what security reasons? I posted about this on one of the blogs on java.net yesterday. Chances are it'll be ignored also. :(

I thought of two apps off the top of my head that are very responsive: jEdit and jDiskReport. Try one or both of them out, I'm sure you'll be surprised.

On a tangentially related note, check out these pictures of a whiteboarded Java timeline at the 2004 JavaOne conference, there's some neat memories and comments in there. One of the attendees called it "a real life wiki".

Looking Glass is a developers release and if you aren't a developer you shouldn't be downloading it. They have made it clear that they released it so early in the project's life so that developers could test it and start brainstorming/creating 3D applications. If that screenshot is from you, you obviously did not read any of the documentation provided on the project page at java.net as that is a known problem on certain hardware setups and has a very easy fix that has been discussed in the forums a number of times. Maybe you should look at the documentation before you start downloading developers releases and complaining about there stability. Looking Glass won't be useable as a desktop replacement for the general public for quite sometime yet. Do you also realize that Looking Glass is open source and has been for several months?

So the simple way to understand OpenGL code is to think of a really big state machine. Each call just modifies the currently existing state. The state persists until the state is changed - even to the point of maintaining it between rendered frames.

If you want Java bindings for OpenGL, there's two major projects.

JOGL, which is the basis for the formal bindings in JSR 231.

LWJGL which is a community driven project and somewhat akin to DirectX in that it also merges audio and input device APIs as well.

If you need some tutorials to get started, check out http://opengl.j3d.org in a couple of weeks when it gets officially opened and has lots of beginner tutorials to play with.

After that, the OpenGL Red Book is your friend.

Not fair to blame Gosling for Swing. He mostly participated in actual Java development back when Java was still called Oak, and was still viewed mainly as an embedded systems language. Swing didn't appear until after Sun began its big push to sell Java as a general-purpose platform. By then, Gosling had been promoted to "Chief Scientist", a job that seems to consist mostly of giving speeches and writing papers.

I feel like I'm responding to a troll here, but I think you haven't used Swing in a while. The latest releases in 1.4 are significantly better looking and faster. They also make better use of the underlying graphics hardware in Java 2D. I've written apps in Swing that have been very responsive; you just have to take the time to learn the framework.

I will grant you that Swing can get complex and it can take serious effort to eliminate bottlenecks. It's intended to be a general framework for MVC based applications, so it has to cover a lot of cases that may not be applicable for all applications. You sometimes have to subclass and override default painting behavior to tailor it to your usage. But at least you have the ability to do that if you wish.

It also has a tendency to be lower-level then some other approaches. I've seen people throw together VB apps with a lot of functionality pretty quickly. It can take longer to get there in Swing, but the results generally are more maintainable and scalable.

There are efforts in the works to generate standard higher-level constructs, such as database-backed tables with sorting, that other GUI frameworks provide. Check out JDesktop Network Components to see what's in the works. There are also efforts underway to allow Swing apps to fit more neatly into the native shell (such as tray icons).

Swing was pretty deadly in the past, but it has improved significantly recently. Ironically, I'm seeing a lot more MacOS X apps written in Java or Java apps developed on MacOS since Apple has put a lot of effort into their Swing look and feel for Aqua. If you are looking to Apple for direction, I think that is a significant data point.

I would appreciate if you would give me a direct link for this. Using the search in that page i found http://wiki.java.net/bin/view/Main/NativeHooks. Is that it? It heavily uses JNI, which is not the same code at all

I think the whole of Jade should be living in commons.apache.org somewhere

You mean: http://jakarta.apache.org/commons/

The Jakarta project is Apache's Java efforts. commons.apache.org used to hold common libraries such as APR for Apache HTTPD. These were mostly C libraries, I believe.

Apache Jakarta Commons (ok, so Apache needs to clean up and simplify there project namespace), rocks.

Here's there summary for commons-collections
* Bag interface for collections that have a number of copies of each object
* Buffer interface for collections that have a well defined removal order, like FIFOs
* BidiMap interface for maps that can be looked up from value to key as well and key to value
* MapIterator interface to provide simple and quick iteration over maps
* Type checking decorators to ensure that only instances of a certain type can be added
* Transforming decorators that alter each object as it is added to the collection
* Composite collections that make multiple collections look like one
* Ordered maps and sets that retain the order elements are added in, including an LRU based map
* Identity map that compares objects based on their identity (==) instead of the equals method
* Reference map that allows keys and/or values to be garbage collected under close control
* Many comparator implementations
* Many iterator implementations
* Adapter classes from array and enumerations to collections
* Utilities to test or create typical set-theory properties of collections such as union, intersection, and closure

For those doing Swing programming, also check out Java Desktop Network Components (JDNC) project (this isn't from Apache, unfortunately). The documentation isn't that great yet, but the API is all you need.

If you really need to eek out the last nanosecond of performance, do not use java. Java will never be able to match the speed of writing to the metal.

Yah, just like one wouldn't want to use a platform-independent lib like OpenGL to write high-performance graphics, you'd want to go straight to the metal...oh wait... (You should take a look at JOGL by the way.)

In the same vein, one would never want to use C++ for high-performance code, one would rather write straight C, or better yet assembler...ooops...

Your argument has two fallacies - one is that Java can never be as fast as C or FORTRAN (not true).

The second is that it is worth any amount of effort to pry the last few percent of performance out of a system (not true either, unless said lack of performance is a fatal error, i.e. hard realtime).

Hope that helped...

I wouldn't worry about it screwing up your games... it doesn't appear to run on Windows. From the Platform Requirements: "Operating System
- Project Looking Glass has been tested on Sun Java Desktop System Release 1 and Release 2, RedHat 9, SuSE Linux 8.1."

I am not a Java Programmer (yet) and its just second time I was abt to use a Java Program on Linux.
Just followed their instructions for getting the Looking Glass up and Running and Yo!. That was a Fantastic Experience. Check out my Snapshots captured using KSnapShot tool when the looking Glass was running over the TWM Window Manager. This was on a Dell Optiplex Gx260 having onboard Intel845 Video Card running Fedora Core2. When it really gets full fledged, believe me, all the desktops is going to be like playing a 3D game. Whole new features and a good extension to the present desktops. So Sun, I forgot what the business-men are saying, Kudos for your Technology!!!

Not that anyone would expect them to, but they fail to mention that this system tested earlier this year at JavaOne.

on April 15 2004, Sun's James Gosling, in response to this article and some "slashdot flamage" from the same author, blogged in More on Sun & Microsoft

My last blog entry stirred up a lot of commentary and flamage (and some of the flamage was entertainingly wild: I love the Internet!). Reading through it, it's clear that there's still confusion about the meaning of our "collaboration" agreement with Microsoft.

While it is true that as a part of it we did sign up for Microsoft's Communications Protocol Program that is a part of the US v. Microsoft case, our full agreement both modifies and expands on it to give us a much more broad and useful agreement. It is important to understand that in no way does this lock Sun or Sun customers into interoperating with any Microsoft system on Microsoft's strict terms. Right now, most of our interoperability is achieved through reverse-engineering. We have the option, entirely at our discretion, to access Microsoft's specifications through the collaboration agreement. But before we do so, on a case-by-case basis, we will do an analysis of the business case for the entanglements that such access implies (principally confidentiality and royalties). Right now, the vast majority of the software that we (Sun) produce has free and open specifications and we provide the implementations of a large and growing fraction of it as open source. We are not going to slow down our involvement in the open source community. Right now we have launched no projects that will access any Microsoft specifications under the agreement - we simply have the option to, if we decide that the benefits outweigh the costs.

Do your research. Gosling is a crreator of Oak. It's true that Sun bought out the company that built Oak but Gosling was the visionary behind the entire concept.

Java becomes more like a usable programming language every day!

The functionality of mailcap, later cloned in win32, GNOME and KDE, is now available to Java as JDIC!

And JDNC provides powerful GUI functionality, including an XML format for describing GUIs, a la Glade, wxWidgets XML resource files, XUL , XAML. Of course, they are all completely incompatible. Also worth mentioning here is GNU Enterprise, which has seemingly similar aims to JDNC.

I don't know what all this has to do with ActiveX. For all I know, ActiveX was MicroSoft's intended replacement (or umrella) for Java and JavaScript. It has met with mixed success, having met with popelarity mostly as a malware target. JDIC and JDNC look like decent proposals to me. It's good to see Java maturing both in speed and functionality. The more choices, the merrier, after all.

Java becomes more like a usable programming language every day!

The functionality of mailcap, later cloned in win32, GNOME and KDE, is now available to Java as JDIC!

And JDNC provides powerful GUI functionality, including an XML format for describing GUIs, a la Glade, wxWidgets XML resource files, XUL , XAML. Of course, they are all completely incompatible. Also worth mentioning here is GNU Enterprise, which has seemingly similar aims to JDNC.

I don't know what all this has to do with ActiveX. For all I know, ActiveX was MicroSoft's intended replacement (or umrella) for Java and JavaScript. It has met with mixed success, having met with popelarity mostly as a malware target. JDIC and JDNC look like decent proposals to me. It's good to see Java maturing both in speed and functionality. The more choices, the merrier, after all.

Keep in mind that there are two aspects of Project Looking Glass at the moment. The first is the "proof of concept" demo (you can see a video of this demo here) and the second is the "developer's release" on java.net. Not all the features in the proof of concept are currently implemented in the developer's release.

Also, remember that this is an early access, open development project. Questions about to usefulness of these concepts can and should be openly debated. I discuss some of Sun's thinking in my blog.

This quote is misleading:

The two projects, JDNC (JDesktop Network Components) and JDIC (JDesktop Integration Components), are essentially to Java application developers what Microsoft's ActiveX and COM were to Windows developers--an architecture for creating easily configured application components and for integrating with the functionality of the local operating system and other applications."

From the JDNC project page:

The goal of the JDesktop Network Components (JDNC) project is to significantly reduce the effort and expertise required to build rich, data-centric, Java desktop clients for J2EE-based network services. These clients are representative of what enterprise developers typically build, such as SQL database frontends, forms-based workflow, data visualization applications, and the like.

And then from the JDIC project page:

The JDesktop Integration Components (JDIC) project aims to make Java(TM) technology-based applications ("Java applications") first-class citizens of current desktop platforms without sacrificing platform independence.

The quote is misleading because it doesn't explain how ActiveX is similar to JDNC/JDIC. The similarity is platform lock-in: ActiveX and COM means you're stuck on Windows (albeit with a choice of programming languages). JDNC/JDIC means you're stuck on Java (but without real, viable choice on the language).

The fundamental problem (IMHO) is that desktop component integration is limited to a single desktop. Yes, I can have code reuse on Windows, and I can have code reuse on Gnome|KDE|Sun(tm)Java(r)Desktop(tm), but will I ever have (or need?) component integration across the three? It seems to me that developers have enough to handle getting the core functionality right.

This kind of thing seems like just so much... distraction.

This quote is misleading:

The two projects, JDNC (JDesktop Network Components) and JDIC (JDesktop Integration Components), are essentially to Java application developers what Microsoft's ActiveX and COM were to Windows developers--an architecture for creating easily configured application components and for integrating with the functionality of the local operating system and other applications."

From the JDNC project page:

The goal of the JDesktop Network Components (JDNC) project is to significantly reduce the effort and expertise required to build rich, data-centric, Java desktop clients for J2EE-based network services. These clients are representative of what enterprise developers typically build, such as SQL database frontends, forms-based workflow, data visualization applications, and the like.

And then from the JDIC project page:

The JDesktop Integration Components (JDIC) project aims to make Java(TM) technology-based applications ("Java applications") first-class citizens of current desktop platforms without sacrificing platform independence.

The quote is misleading because it doesn't explain how ActiveX is similar to JDNC/JDIC. The similarity is platform lock-in: ActiveX and COM means you're stuck on Windows (albeit with a choice of programming languages). JDNC/JDIC means you're stuck on Java (but without real, viable choice on the language).

The fundamental problem (IMHO) is that desktop component integration is limited to a single desktop. Yes, I can have code reuse on Windows, and I can have code reuse on Gnome|KDE|Sun(tm)Java(r)Desktop(tm), but will I ever have (or need?) component integration across the three? It seems to me that developers have enough to handle getting the core functionality right.

This kind of thing seems like just so much... distraction.

See Fast Web services and Fast Infoset. You get the benefits of XML for interoperability, but without the verbosity..

this, http://lg3d.dev.java.net/ seems to be the project page at java.net.

I can't access the project pages, it tells me i don't have the right permissions. Anyone?

including one that does the low-level desktop integration like Icons, system trays etc. Can't remember the name of that offhand, but it's something like JDNC.

It's JDIC

Newer work seems to be based on calling OpenGL from Java. With widespread OpenGL support in hardware, that makes sense. There are at least five incompatible OpenGL bindings for Java, though. Sun has an "official" one, but they couldn't resist crudding it up with all their "technologies", so you have to download Ant, Antlr, and Java Web Start. This last tangles you up in some Sun licensing restrictions. This is a bit much for what's no more than a shim.

Sun and SGI announced at last year's SIGGRAPH that they were planning native OpenGL 1.5 bindings. I don't know what has come of that project.

It's called JOGL. There's a JSR associated with it (JSR-231) that is doing the work of the formalised bindings. My company (Yumetech) is on the JSR committee for that one and things are progressing reasonably well, though not at the scheduled timetable. There is also a related JSR that is getting off the ground right now for the OpenGL-ES bindings, JSR 239, but is a little further behind.

Although, having a large higher-level 3D open-source library ready to use in Java might swing momentum in Java's favor.

There's at least two that have been underway for the last year - Xith3D and Aviatrix3D. Both are already far faster than Java3D in their respective application spaces (gaming and sci-viz respectively). Come try them out and you'll be surprised at just what sort of speed can really be obtained from 3D Java apps and toolkits.

Since many cell phones are using Java for the applications and games, I would not be surprised if the next step would be to include support for OpenGL, especially given that Nvidia and ATI are playing part. There are already OpenGL bindings for Java, though the one that is likely to show most evolution, given the backing, is JOGL.

*Sigh*, yes, it's true. At least Sun finally seems to be warming up to client-side Java with the partial startup optimizations coming in 1.5 and the recent JDIC project opening.

There is a much more agressive plan, though, that could lead to a Java shell to allow a much faster starting of client-side apps.

What's important to note is that the differences introduced by the VM and the rest of Java's overhead are small enough now that, for headless applications, poor coding can easily bridge the difference. There's no huge, glaring, a priori reason to use C++ over Java for headless apps, and when you want your server code to be portable crossplatform you'll find a huge, glaring reason to use Java.

Now what this study obviously doesn't deal at all with GUI'd applications, and Sun's Swing in particular does nothing to help Java's reputation as a slow technology. There's a relatively interesting discussion at java.net called Swing Usability that points out some of these shortcomings. What the Swing team doesn't seem to understand is that slower than native means slow to most users.

And just like the comments in this thread point out, as long as you put a compatibility layer between code and execution, you're going to be slower by definition. With Swing, simple to overlook unoptimized coding practices do not easily spell the difference between implementations. Here, Java's speed and performance is visibly slower no matter how quickly the GUI-less logic behind is racing along. (Yes, SWT is a big help, but it's not part of the JDK and likely still won't be seen in, say, Limewire any time soon.)

...nicely. What's nice is that some of them are open source and written by savvy folks, i.e.:

RubLog - Dave Thomas
bloged - James Gosling

I doubt that Linford himself would say something as stupid as "Russia and China 'behind current spam deluge' when Americans advertisers are paying for it and 80% of it originates on computers running a broken US OS. I also doubt that Linford would blame the Russian or Chinese governments for the actions of organized crime in their country.

Graeme Wearden should do some more research and think. There's a real story here and the pieces are being put together. Where is the spam really coming from? Follow them money. Does anyone really buy penis enlargers, diplomas and drugs from spam? What companies have recently announced profitable new email schemes that depend on the death of normal email? Could large ISPs run by unethical companies, that have a proven record of breaking competitor's service, be trying to break competing ISP's email service by deluging their customers with spam and then advertising spam blocking email of their own? Russian and Chinese criminals seem sensational, but the truth is always much more interesting.

I agree with other posters that one conference failure does not a funeral make. Slashdot gets enough traffic without having to sensationalize everything.

However, the current state of WiFi is pretty sorry. Perhaps I am just flustered because of the problems I've had setting up a WiFi network for the first time, but everyone I know who has setup WiFi has had to deal with a whole array of perplexing problems. Without fail, they end up consulting with tech support to get the connection to work. Many router reviews I read on-line detailed mysterious problems and uneven user experiences. On the other hand, connecting Ethernet is practically like plugging power in an outlet nowadays.

I'm not tech-illiterate. I've built every computer I've owned since high school and have run Linux variants on each of them at one point or another. I don't mind some technical complexity, but setup should be easier than it is, and the connection more reliable.

At this point, I could launch into a rant about cell phones as well. CNN had an article today about growing customer complaints with cell providers in the US. In related news, java.net's front page is leading with a blog and associated discussion about how the current speed of software development is going to get the industry in serious trouble.

I think someone should write an article about the death of the IT industry as a whole. Computer-based consumer electronics and software have an amazingly poor degree of reliability, and there appears to be little liability on the part of companies and few channels of recourse for consumers. Well, </bitter>. I'm going off to enjoy my newly configured WiFi.

Hey, it's nice to see Canuck contributions being noticed.

Maybe all of us up here in Canader are actually the source of the, er, open-source problem.

Between training our students to (gasp!) write operating sytems and computer languages from scratch (in one Canadian-style semester) and coming up with dangerous ideas like Java, it looks like Canada is turning into a dangerous, anti-Microsoft^h^h^h^h^h^h^h^h^hinnovation entity. A well-known Canadian company even helped define the POSIX standard (not surprisingly, this company is linked to one of the creators of Coherent). Sounds like terrorist training camps for software zealots to me. Where do I sign up!

Perhaps Finland and Canada are the ringleaders of the real Axis of Evil. You know, up here near the earth's axis. We even have agents working on the inside.

If Brown doesn't do his job, he might be writing his idiotic screeds with a CNC editor compiled under Watcom C in a POSIX shell. We'll "allow" him to use an editor that supports en-CA localization. If he can hold his liquor and learns to follow a hockey game without asking stupid questions.

Hey, maybe in the future the phrase "a vacation in Canada" might be a euphemism for "open-source re-education camp."

Don't forget about the free Java Desktop T-Shirt giveaway for the first 20 screensavers submitted before JavaOne!

It's sound business for Sun to (A) Open source licensing the Java J2SE,J2EE and J2ME framework libraries ; and (B) Release a fork of the Solaris Kernel under the GPL license.

It would benefit the entire Java based industry, including the free software, open source and proprietary based vendors, to open license the core J2ME,J2SE,J2EE libraries and Java to bytecode compilers.

Java's primary strength, the ability to write code which is constantly portable across many vendors platforms, would be greatly enhanced if all of the vendors were using the same core libraries.

To insure that the standard base core would not become polluted with incompatible forks, the source could be licensed with a clause requiring any incompatible changes or any additional classes or methods to be moved to and occupy only the vendors namespace. Another clause would require that the vendor version of the Java to bytecode compiler and any GUI IDE defaults to generating portable bytecode, without embedding any vendor specific references.

The OSF definition of an open source license clause five explicitly states: "The license may require derived works to carry a different name or version number from the original software."

Developers and vendors would only be required to shift changes to the vendors/developers namespace if the changes were incompatible with the JCP JSR open standards. This would not prevent the development/distribution of additional optimizations, ports or bug fixes. Since adoption of standards has for a long time been an open source tradition, it would not be much of an imposition on the open source community.

Vendors don't have to use *all* the same "core" libraries - just provide the same standard interface. The open source Java core can been seen as a starting common base. Each vendor would be free to "short circut" their implementation as long as the standard API behaviour remain the same. Vendors would still be free to compete on their JVM performance along with how well it performs interfacing data bases, integrated development tools, etc.

Sun could require contributers to the Java Open Core to let Sun or the JCP dual license the result as Sun does with OpenOffice.org and StarOffice. If a vendor does not wish to disclose their modifcations then the vendor could pay for a closed source license scheme. The payment could then be split up amongst Sun, the JCP and the contributers.

Ask IBM and HP what their customers are demanding and you will find out more often than not that it's vendor neutral/independent solutions. Customers don't want lock-in slavery anymore. That is why Linux is such a success and why there is more demand for Java skills than any other programming language.

It should not be necessary to open source license Sun's JVMs. In the long run it could greatly benefit Sun to develop the JVM under a dual license as it doing with OpenOffice.org and selling StarOffice.

Releasing a fork of the Solaris Unix Kernel makes even more sense when you consider Suns move towards commodity based hardware, like AMD's opteron, and enterprise desktop systems. Sun is going to need drivers to interoperate with x86 hardware and common peripherals. In comparison to Linux, the range and quality of hardware drivers available to Solaris is pitiful.

If Sun can manage to get out from under the SCO Groups claims over the old AT&T code base, by dealing direct with Novell who still appear to hold the rights and copyrights, then Sun would be free to release a fork of the Solaris kernel under the GPL license.

Sun would be then free to take any source code from the Linux kernel and incorporate it into the GPL'ed Solaris kernel fork. Sun would then free to deploy that kernel in desktop and clustered systems markets, where Linux currently does have a lead over Sun.

And on the Java side there is also BlogEd James Gosling's Client Side Blog Editor, which just ftps the html to the server. A very useful tool for thin servers.

All the listed Weblogs are server side. That is missing out on a very useful category of Weblog editors: client side only editors. This is really useful for those of you who have a web server that does not have enough space to put up php or other server side magic: check out James Gosling's BlogEd. The nice thing about BlogEd is you can write and manage your blog whithout being connected to the web. It produces simple html which is the ftp-ed to the server at minimal cost. There is still a lot of ways it can be improved. But the idea is certainly very original. And it is free: available under a BSD licence.

All the listed Weblogs are server side. That is missing out on a very useful category of Weblog editors: client side only editors. This is really useful for those of you who have a web server that does not have enough space to put up php or other server side magic: check out James Gosling's BlogEd. The nice thing about BlogEd is you can write and manage your blog whithout being connected to the web. It produces simple html which is the ftp-ed to the server at minimal cost. There is still a lot of ways it can be improved. But the idea is certainly very original. And it is free: available under a BSD licence.

PlaneShift is a pretty nice open source MMORPG, it's still in development and I don't really know about the current userbase though. Check http://www.planeshift.it

Eternal-Lands is also looking good and should be farily playable http://www.eternal-lands.com
I don't really know about the current userbase but I'm about to try it again :)

Also there is Arkanae https://arkanae.dev.java.net/- I don't really know anything about that one though.
Then you have WorldForge which I really haven't had any luck with, and I don't really think it is in a playable state anyway (http://www.worldforge.org).
In addition to those you have http://www.genecys.org/ - don't really know much about that one either.
So theres a few going on :)

McBride is at a Loss for Words

Maybe he shouldn't have used them all up before.

This is probably a good thing. In fact, as it presently stands Darl could teach a thing or two about not running your mouth off unnecessarily to a certain other proprietary Unix company.

Sun's COs claim that they need to maintain tight control over the Java library source code and standards to insure Java cross vendor "write-once" portability. This was the main point for Sun's lawsuit against Microsoft. In fact, in the DOJ case the federal appeal court did find that Microsoft had deceived Java developers, which the court decided was in breach of the Sherman Antitust act.

For Sun to call their settlement anything but a sellout, Sun could at least persuaded Microsoft to create or adopt a modern release of Java to replace the 1997 eon MSJava JVM. Instead Microsoft gained the right to extends life of its Java Virtual Machine to December 31, 2007. Microsoft have stated that it will not be improving ( or updating ) the old JVM and Microsoft's J# "upgrade path" still uses non-standard interfaces for GUI's and .NET libraries. This leaves Microsoft free to play the old "standard" embrace, extend and enclose anti-competitive tactics.

Sun' s James Gosling claims, in response to this article and some "slashdot flamage" from the same author that though the new settlement, Sun has gained the right to selectively access Microsoft's Communications Protocol Program. This ablity to selectively pick and choose and other "flexabilities" was a detail left out of Sun's press release, and more interestingly, the recent joint status report on Microsoft's complicance with the US DOJ final antitrust judgement.

Avalon is the new Windows API, and it apparently represents a major jump in UI capabilities. Part of its value proposition is in the ease of use to developers and part in the experience for end users.

In order to increase developer productivity, Avalon will rationalize and reduce the number of APIs in the Win32 stack from over 70,000 down to 8,000.

On the user experience side, Avalon will feature advanced support for 2D and 3D vector graphics as well as standard GUI widgets.Some descriptions of Avalon suggest that it is more comprehensive than just the graphics layer, and will incorporate support for paradigm-shifting "task-oriented" UIs.
http://weblogs.java.net/pub/wlg/525

There are alternatives to rebooting if you want to play.Javagaming
LWJGL

Well, you may look at this article for a little info. What little I know of it atm (I'm not a java zealot; just someone who's written a few apps and think its reputation for slowness and inconsistency is highly archaic and overrated (like the BSoD and Windows, no?))

It's of course no panacea; you trade off between consistency across platforms (the strength of java) and looklike like you "belong" on the platform, for whatever that may be worth.

The app I mentioned was quite responsive on my K6-2 450 I developed it on; I was surprised, since it had to calculate the eigenstates and eigenenergies of a quantum well (educational app).

To be fair, I've also tried to use the NetBeans and Eclipse IDEs and found them to be pretty slow on the same hardware, so I'm not sure where the problem lies exactly. That said, they seem pretty responsive on my new hardware (even when the pentium-m is scaled down to 600MHz); maybe owing to having much more RAM.

My last blog entry stirred up a lot of commentary and flamage (and some of the flamage was entertainingly wild: I love the Internet!). Reading through it, it's clear that there's still confusion about the meaning of our "collaboration" agreement with Microsoft.

While it is true that as a part of it we did sign up for Microsoft's Communications Protocol Program that is a part of the US v. Microsoft case, our full agreement both modifies and expands on it to give us a much more broad and useful agreement. It is important to understand that in no way does this lock Sun or Sun customers into interoperating with any Microsoft system on Microsoft's strict terms. Right now, most of our interoperability is achieved through reverse-engineering. We have the option, entirely at our discretion, to access Microsoft's specifications through the collaboration agreement. But before we do so, on a case-by-case basis, we will do an analysis of the business case for the entanglements that such access implies (principally confidentiality and royalties). Right now, the vast majority of the software that we (Sun) produce has free and open specifications and we provide the implementations of a large and growing fraction of it as open source. We are not going to slow down our involvement in the open source community. Right now we have launched no projects that will access any Microsoft specifications under the agreement - we simply have the option to, if we decide that the benefits outweigh the costs.