Slashdot Mirror

B. Residual Rights. You may use any information in intangible form that you remember after accessing the Technology, except when such use violates Sun's copyrights or patent rights.

Just to interject on a small point. The only thing you mentioned there that is part of the OS is the kernel. This annoys the hell out of me. An operating system is the software system that operates the hardware. An operating system provides the foundation on which you build a system usable by programmers or users, but it is NOT that entire system.

Depends on who you ask. If you ask Stallman, Linux is "just a kernel" and the GNU userland is the most important part of the OS. Viva la GNU/Linux! (Whatever. :-))

However, the Free software community has developed solutions that are infinately more complex (like the Linux kernel).

The ability of the Free software community to help out is why Sun has Java development open to all developers. They even developed a license that doesn't threaten developer's ability to then work on an OSS version.

Actually even the first release of the kernel written by Linus alone was beyond the complexity of Java (although it hardly had the QA and stability of sun java).

If you're comparing Linux 1.0 to Java 1.0, then I'd say you're correct. But as far as complexity goes, Linux 1.0 was nowhere near as complex as Hotspot, the JVM libraries, and the various other components of the JVM. Trust me, the software running under the hood of Java is very much "next level" stuff. Most of the optimizations for the JVM had to be developed by Sun, because no one had developed an OOP system on this scale before.

only official Java APIs are allowed to be used

This was already being done. There was a plugin interface that hooked into the AWT layer of the JVM, but that was something that was easily replacable by other VMs. Previous versions of OOo (probably from back when it was StarDivision property) used hidden APIs, but this was cleaned up in the 2.0 edition.

Java JRE interested parties provide the support code and take care
of QA, bugs etc.

This sounds like they're moving the plugin code out of OpenOffice and into the JVM. Technically, this is where it belongs, but it's always nice to be able to support the largest number of VMs possible.

OOo Java implementations must be encapsulated with well specified APIs

This is just good engineering design. If you can't produce readable JavaDocs from it, it isn't a good API.

OOo Java implementations must not check against Java versions or
vendors, with the only exception of workarounding bugs

Again, this is just common sense. Checking version numbers is a good way to nail yourself in the foot on future releases.

OOo Java implementations must not use swing, either because no free
swing implemetation is available or because it makes the user interface
inconsistent, this rule might be relativated in respect to 4

This is just common sense anyway. Using Swing would be detrimental to the GUI unless it was decided that the entire GUI framework would move at once. Such a decision would involve the entire OOo community.

the Java baseline is 1.3.1

This is the only concession I see being made. (1.4 & 1.5 have some *really* nice features.)

The amusing part about this is that the whole tirade against Java in OOo is nothing but a farce. A quick check of the 2.0 code finds almost nothing that violates these "concessions", and they amount to nothing more than diplomacy anyway. (i.e. The art of saying "nice doggy" until you can find a big stick.)

The truth is that Sun has bent over backwards for the OSS community, and all they get for their troubles are painful stabs in the back. Yeah, Sun's got some loud mouths working for them. But their actions have ALWAYS been honorable. Despite all the nonsense about "contamination", has anyone EVER had Sun sue them? I've certainly never heard of a case! And when Sun realized that the language was confusing, they updated future source releases with new language that EXPLICITY gives developers rights to whatever they remember. So no more excuses! If you want an OS Java platform, code it. Sun sure as hell isn't standing in your way.

BTW, Mr. Stallman. How's Hurd coming along?

only official Java APIs are allowed to be used

This was already being done. There was a plugin interface that hooked into the AWT layer of the JVM, but that was something that was easily replacable by other VMs. Previous versions of OOo (probably from back when it was StarDivision property) used hidden APIs, but this was cleaned up in the 2.0 edition.

Java JRE interested parties provide the support code and take care
of QA, bugs etc.

This sounds like they're moving the plugin code out of OpenOffice and into the JVM. Technically, this is where it belongs, but it's always nice to be able to support the largest number of VMs possible.

OOo Java implementations must be encapsulated with well specified APIs

This is just good engineering design. If you can't produce readable JavaDocs from it, it isn't a good API.

OOo Java implementations must not check against Java versions or
vendors, with the only exception of workarounding bugs

Again, this is just common sense. Checking version numbers is a good way to nail yourself in the foot on future releases.

OOo Java implementations must not use swing, either because no free
swing implemetation is available or because it makes the user interface
inconsistent, this rule might be relativated in respect to 4

This is just common sense anyway. Using Swing would be detrimental to the GUI unless it was decided that the entire GUI framework would move at once. Such a decision would involve the entire OOo community.

the Java baseline is 1.3.1

This is the only concession I see being made. (1.4 & 1.5 have some *really* nice features.)

The amusing part about this is that the whole tirade against Java in OOo is nothing but a farce. A quick check of the 2.0 code finds almost nothing that violates these "concessions", and they amount to nothing more than diplomacy anyway. (i.e. The art of saying "nice doggy" until you can find a big stick.)

The truth is that Sun has bent over backwards for the OSS community, and all they get for their troubles are painful stabs in the back. Yeah, Sun's got some loud mouths working for them. But their actions have ALWAYS been honorable. Despite all the nonsense about "contamination", has anyone EVER had Sun sue them? I've certainly never heard of a case! And when Sun realized that the language was confusing, they updated future source releases with new language that EXPLICITY gives developers rights to whatever they remember. So no more excuses! If you want an OS Java platform, code it. Sun sure as hell isn't standing in your way.

BTW, Mr. Stallman. How's Hurd coming along?

The specs are open but the license file for the API specification specifically grants only the right to implement the entirety of it, and only if the implementation also passes the TCK. There is no other right to use the API specification other than for "internal use" to be able to write programs that are not re-implementations. The effort to achieve total compliance is simply beyond what anyone can achieve without the ability to reach intermediate steps. But those intermediate steps violate the license of the API specification by not being complete.

What should in my opinion be alarming is that Sun has specifically mentioned a Residual Knowledge right for its otherwise "read only" JCK that is not mentioned at all in the license file for the API specification. That means that Sun considers one to have no Residual Knowledge right after having read the API specification. Anyone who reads the API specification is tainted unless the implementation is 100% complete and passes the TCK, which isn't going to happen soon, or ever. This is the same clever strategy that Sun has used of spreading the source code to taint as many developers as possible. And while GNU Classpath and Apache Harmony can probably succeed in documenting that developers aren't tainted from having viewed the source code, there is no way they will be able to argue that all of the developers are also untainted with respect to the having read the API specification.

I think the ground is being laid for a straightforward copyright violation lawsuit to defend the API specification should a release ever be made of either GNU Classpath or Apache Harmony. There is no way either project will achieve complete compliance, and there's only so long they can claim they are "pre-released" products, especially if they are being widely installed and used as dependencies in open source distributions.

You might not think Sun can win such a lawsuit, but it doesn't really matter now does it from an individual developer's perspective if one doesn't have the legal resources to fight back.

Please! Just go to https://mustang.dev.java.net/ for the snapshots for the next version of java. You can even send your patchs back to the project. Go to java.sun.com for older versions. Java sources have been available for download for YEARS.

But what none of them can do is redistribute it.

BUT, you can redistribute the existing Linux binaries.

They can't examine it

Can too.

they can't learn from it,

Can too.

they can't change it.

Can too.

The only Linux distros who include it are commercial ones because a free distro is forbidden from it even if they aren't opposed to including un-free binaries.

Bullshit. The Linux distros have been free to include the JRE and JDK for a very long time. They usually give some BS about it "not being Free as in Libre" or somesuch. Are you one of those distro maintainers who's spouting this bullshit?

Once OOo depends on Java it can no longer be freely distributed.

1. It already does, always has.
2. Can too.

You sir, are either amazingly clueless or brainwashed by the OSS fanatics. Allow me to present Sun's open Java development model which allows people to download and develop Java under the Java Research License. Also allow me to introduce you to Sun's position on redistributing the JRE and the rules for JDK redistribution. The long and short of it is, "Feel free to redistribute it with your software. Here is a list of files you can leave out. Here is a list of JDK files that can be bundled with the JRE instead."

OOo is clearly intended to be a Trojan Horse designed to force JAVA dependence.

The only trojan horse around here are the assholes of the Open Source community (apparently like yourself) who would rather spread diseased lies than try to work through the issues to find what's really true.

And in case you're wondering, YES. I'm hopping mad at you people!

But what none of them can do is redistribute it.

BUT, you can redistribute the existing Linux binaries.

They can't examine it

Can too.

they can't learn from it,

Can too.

they can't change it.

Can too.

The only Linux distros who include it are commercial ones because a free distro is forbidden from it even if they aren't opposed to including un-free binaries.

Bullshit. The Linux distros have been free to include the JRE and JDK for a very long time. They usually give some BS about it "not being Free as in Libre" or somesuch. Are you one of those distro maintainers who's spouting this bullshit?

Once OOo depends on Java it can no longer be freely distributed.

1. It already does, always has.
2. Can too.

You sir, are either amazingly clueless or brainwashed by the OSS fanatics. Allow me to present Sun's open Java development model which allows people to download and develop Java under the Java Research License. Also allow me to introduce you to Sun's position on redistributing the JRE and the rules for JDK redistribution. The long and short of it is, "Feel free to redistribute it with your software. Here is a list of files you can leave out. Here is a list of JDK files that can be bundled with the JRE instead."

OOo is clearly intended to be a Trojan Horse designed to force JAVA dependence.

The only trojan horse around here are the assholes of the Open Source community (apparently like yourself) who would rather spread diseased lies than try to work through the issues to find what's really true.

And in case you're wondering, YES. I'm hopping mad at you people!

as AKAImBatman seems to have suggested

Speak of the Devil...

I propose that Java n'est pas libre. Please explain how your argument that Java est gratuit contradicts that.

1. I have the liberty to download Java at no cost.
2. I have the liberty to redistribute Java with any program I make.
3. I have the liberty to download and view the source code.
4. I have the liberty to retain the ideas I learn from the source code.
5. I have the liberty to reimplement the Java Virtual Machine as I see fit.
6. I have the liberty to share anything I learn from the Java Virtual Machine with others.
7. I have the liberty to use the Java Virtual Machine for any purpose I see fit.
8. I have the liberty to compile my own, custom, JVM based on Sun's source code.
9. I have the liberty to redistribute my custom JVM to research associates.
10. I have the liberty to redistribute the custom JVM inside my company.

So on and so forth. What I DON'T have the liberty of doing is:

1. I don't have the liberty of forking Sun's codebase.
2. I don't have the liberty of redistributing custom binaries to the world.
3. I don't have the liberty of giving the source code to someone who has not entered in a license agreement with Sun.
4. I don't have the liberty of calling my Virtual Machine "Java" without Sun's permission.

Doesn't sound so bad to me. Go get some freedom, man.

From here:

18. Does the JRL prevent you from being able to create an independent implementation of J2SE?

The JRL is not a tainting license, and includes an express "residual knowledge" clause. Under the JRL, merely looking at Sun's code does not prevent you from being able to create your own independent implementation of J2SE, and in any event, you can terminate the JRL at any time for any reason. So, yes, you can look at Sun source code and then later on go and work on an open-source J2SE implementation.

Source code is under that license here. So much for that lame argument.

From here:

18. Does the JRL prevent you from being able to create an independent implementation of J2SE?

The JRL is not a tainting license, and includes an express "residual knowledge" clause. Under the JRL, merely looking at Sun's code does not prevent you from being able to create your own independent implementation of J2SE, and in any event, you can terminate the JRL at any time for any reason. So, yes, you can look at Sun source code and then later on go and work on an open-source J2SE implementation.

Source code is under that license here. So much for that lame argument.

Hey ASSHOLES, the current Java source code can be downloaded here, and the latest development version can be downloaded here. And if that's not enough for you, your precious Kaffe, gcj, GNU Classpath, and other "Open Source" projects are working on reimplementing the JVM. I don't particularly care if you like Java or not, but I've had enough of this bullshit about Java being open or not. It's a God damn language/platform with thousands of successful Open Source projects under it, and has been opened up six ways to sunday. Comparing the issue to Linus's predicament is disingenuous at best, is not outright dishonest!

Not to mention that OpenOffice is Sun's baby. They PAID MONEY FOR IT. (I know that's a foreign concept here, since the entire fraking world is supposed to be FREE for the fraking taking.) If you don't like the direction OpenOffice has taken, then go play with KOffice. Oh wait, you alreay pissed them off too. Is there anyone you people won't make an enemy of in your Quixotic quests of stupidity?

Apologies for the abrasiveness of this post, but crap like this deserves it. You've been given a gift and all you can do is look it in the mouth.

http://community.java.net/mac/

I've been on the java.net site.>/a>

Its a good mix of Sun developers and java users. I'm thinking of jumping back into java and been poking around that site to see what is new.

Its not all netbean either, Eclipse is giving good billing to.

The .net suffix is either coincidence or very ironic.

Linky

Trails has been mentioned earlier as the Java copy of RoR. You will probably find the following video pretty interesting -- it demonstrates how quickly one can develop an application with Trails. It is a part of Chris Nelson's weblog.

Java Trails is a Java version of RoR. A domain driven collection of tools that allows you to quickly get a CrUD web app up and running. Since it uses Spring, Hibernate, and Tapestry you have complete flexibility to customize code if trails doesn't do what you need.

https://trails.dev.java.net/

Perhaps another comparison worth making is Rails versus Trails for Java? From the trails site: "Trails is a domain driven development framework in the spirit of Ruby on Rails or Naked Objects."

Channing

(Slightly premature announcement coming up.. but hey - it's Open Source so that's okay, right?)

I've just started a (Java) project to interface to a number of search engines. It might be a good place to start if you feel like doing some coding. See https://argos.dev.java.net/ - there is no release yet but the code is in CVS.

It currently supports Blogdigger, Feedster, Del.icio.us, Google, MSN and Yahoo (and Google Desktop search). I'd like to include Ask.com, too, but they don't provide a programatic interface and I refuse to screen-scrape.

In my opinion none of the other search engines are close to Google in quality of results. I've found (to my surprise) that Ask.com gives me the second best results (they bought the old Teoma search engine, which was always okay. It had an index almost the size of Google's, which neither MSN or Yahoo can match yet.)

"That's because traditionally, with a few notable exceptions, client-side Java apps suck. They're clunky, slow, and they look like arse."

Talk about looking a gift horse in the mouth.

Guess I better stop downloading F/OSS software like these.

http://argouml.tigris.org/files/documents/4/0/argo uml-0.16.1/jws/argouml-en.jnlp

http://www.johnmunsch.com/projects/HotSheet/HotShe et.jnlp

http://my.unidata.ucar.edu/content/software/idv/we bstart/IDV/idv.jnlp

http://www.crosswire.org/bibledesktop/stable/bible desktop.jnlp

http://www.geovistastudio.psu.edu/autobuild/gvstud io-full.jnlp

http://molo.concord.org/software/

[There's a LOT of java software out there]
http://community.java.net/projects/alpha.csp?only= hosted

And the fun thing is that on SuSE, Java Web Start is already set up. Click on the JNLP links and it'll automatically download, and set up (Warning some are large downloads).

Heh, additionally...

Or is there some other OpenGL bindings I'm not aware of?

These two aren't bundled with the JDK for obvious reasons but they're actively developed by Sun:

JOGL seems to be the de facto standard.

Or, as previously mentioned, the OpenGL bindings for Java2D in Java 1.5

You require enlightenment about distributed computing...
Go here

/*
* descifra_jdk6.c [100% solido]
*
* Descripcion: descifra el comprimido cifrado X_X almacenado en los 4 ficheros
* .jar de todas las versiones semanales de http://java.net/download/jdk6/
*
* Autor: JeikerTuX Copyrighted 2005 (anonymous spanish juanker)
*
* $ gcc -Wall -pipe -Os -fomit-frame-pointer -march=i386 -Xlinker -s \
* descifra_jdk6.c -o descifra_jdk6
* $ strip -s descifra_jdk6
*/

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>

enum bool_t { FALSE=0, TRUE=1 };

#define byte unsigned char

byte clave[] = "YES I ACCEPT THE CLICK THROUGH LICENSE. ";
int cursor_byte_clave = 0; /* ojo: sizeof(clave)==42, 41 caracteres + 1 nulo */

byte siguiente_byte_de_clave() {
byte b = clave[cursor_byte_clave++];
if (cursor_byte_clave == (sizeof(clave) - 1)) { cursor_byte_clave = 0; }
return b;
}

FILE *fin, *fout;

int main() {
assert(sizeof(clave) == (41+1)); /* ojo, "\0" tambien esta incluido */
if ((fin = fopen("X_X","rb")) == NULL) {
fprintf(stderr,"No puedo abrir el fichero X_X\n");
exit(1);
}
if ((fout = fopen("X_X.zip","wb")) == NULL) {
fprintf(stderr,"No puedo crear el fichero X_X.zip\n");
exit(1);
}
while (TRUE) {
byte b = fgetc(fin);
if (feof(fin)) break;
b = b ^ siguiente_byte_de_clave();
fputc(b,fout);
}
fclose(fout);
fclose(fin);
return 0;
}

Project Peabody" adds two licenses that make it easier for outsiders to see the code.

If it would happen that everybody used some other implementation (even though that is quite unlikely for a very long time) then all that would mean is that Sun could save a lot of money.

Sun are quite pragmatic. If they could make someone else develop a product for them, they would.

You can use OpenGL with Java, even integrate it with AWT/Swing... See jogl for example. (There are other bindings, of course, in addition.)

http://www.ws-standards.com/

http://community.java.net/java-ws-xml/

http://msdn.microsoft.com/Longhorn/understanding/p illars/Indigo/default.aspx

WinFX Indigo Docs

http://pluralsight.com/blogs/tewald/default.aspx I'm sure there is a lot more.

Uh huh...

http://today.java.net/jag/Fallacies.html

Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.

1. The network is reliable

2. Latency is zero

3. Bandwidth is infinite

4. The network is secure

5. Topology doesn't change

6. There is one administrator

7. Transport cost is zero

8. The network is homogeneous

If you're gonna go with BASIC, might I suggest VBScript or JavaScript or ActionScript (Flash). Of course, others might suggest Java or SVG. Or, Lisp, SmallTalk, ML, or Ruby. JavaScript and VBScript at least you can develop without having to download any compilers. If you were leaning towards Java, Python is another good choice in that direction.

There is a version of rails in java.
It's called Trails and it uses spring, hibernate and tapestry.

Site - http://trails.dev.java.net
Tutorial - https://trails.dev.java.net/tutorial/"
Trails in action - https://trails.dev.java.net/media/trails_withnarra tion.mov

It's still beta but you can try it.

There is a version of rails in java.
It's called Trails and it uses spring, hibernate and tapestry.

Site - http://trails.dev.java.net
Tutorial - https://trails.dev.java.net/tutorial/"
Trails in action - https://trails.dev.java.net/media/trails_withnarra tion.mov

It's still beta but you can try it.

There is a version of rails in java.
It's called Trails and it uses spring, hibernate and tapestry.

Site - http://trails.dev.java.net
Tutorial - https://trails.dev.java.net/tutorial/"
Trails in action - https://trails.dev.java.net/media/trails_withnarra tion.mov

It's still beta but you can try it.

Take a look at the actual project. You'll find it's all Java code, and that it uses Java 3D as an generalisation layer to control the video card. So actually a vindication of the virtualisation concept, yes.

It seems that Netcraft cannot find the site! How can a curions Slashdotter know with certainity, what a particular site is running?

the "strap-on" logo kinda creeps me out.

Jonathan Simon has the Mouse Maze, which is also a rodent-controlled MIDI instrument, although its mice, not hamsters. Kind of cool.

You can download the source code for the JVM under SCSL or JRL licence in the same download page as the jsdk or runtime. The source for the libraries comes with the jsdk.
You can even download the development snapshots for the next version of Java 6.0 codenamed Mustang. It's still at a very early development stage.

It looks like the software uses screenshots to take snapsots of windows and then changes the background picture of your desktop to "Animate" the movment.

This is a true 3D desktop currently being worked on by SUN. I can not wait to play with it (NOTE: runs onlu on linux)...

Project home w/ pics and vids
Developer site w/ some doenloads

You've obviously not familar with ANT. Now the horrendous practice they started is moving into usage with a number of XML based GUI builders.

Thankfully there is a counter movement to replace such poor usage of XML with scripts.
http://today.java.net/pub/a/today/2003/06/10/jytho n.html
http://www.javaworld.com/javaworld/jw-10-2004/jw-1 004-groovy.html

I'd pull some more links for ya, but I've gotta bolt.

I have a friend who works for Sun Microsystems, and he tells me they're working on a 3D version of JDS (don't get me wrong, a desktop system is the LAST thing I'd want to see Java used for, but that's not the point). Among other things, you can rotate a window, say, 80 degrees and stick it in a corner. It's then still recognizable, but it doesn't take up much space. You can also turn things around and write notes on the back. This is a REAL use of 3D in a graphical shell. Now, if only somebody would take their idea and implement it in C++ (or some other language with a goal other than portability).

You're talking about Project Looking Glass, which is still in alpha, but will eventually bring a true 3d interface to the Linux desktop. It truly looks like a revolutionary interface, and you can see a video demo of Satan himself (Jonathan Schwartz) ;-P demoing it here.

Some developers are already beginning to contribute to the project, which is open sourced. You can find more details and even download a developer preview of the release at this website.

I downloaded the developer preview and briefly got it up and running on my system. I'm running Suse 9.2, and it requires an ATI or Nvidia 3d card with DRI support enabled in your X config.

They also aren't fantastically hard to recreate. There are plenty of third-party cross platform sound, input and networking libraries.

Regardless, in this case we're discussing a graphical application.

When a DirectX game gets ported to OS X or any other platform you'll often find that the multiplayer is limited to the platform you're using.

Or not. World of Warcraft comes to mind, for instance.

Perhaps someone can suggest some other libraries/frameworks for input/sound/networking. There's GLUT for input, but it's pretty simple so it might not work for everyone.

OpenML and OpenAL are two possibilities. Another thought might be to use a modern programming environment like Java, and use its abstracted sound, input and networking along with OpenGL. You could always write your own wrapper library in your language of choice as well. You could also use a third-party cross platform game engine like the Torque engine that supports OpenGL.

Here's a good link for those that'd like to learn more about OpenGL in general.

They also aren't fantastically hard to recreate. There are plenty of third-party cross platform sound, input and networking libraries.

Regardless, in this case we're discussing a graphical application.

When a DirectX game gets ported to OS X or any other platform you'll often find that the multiplayer is limited to the platform you're using.

Or not. World of Warcraft comes to mind, for instance.

Perhaps someone can suggest some other libraries/frameworks for input/sound/networking. There's GLUT for input, but it's pretty simple so it might not work for everyone.

OpenML and OpenAL are two possibilities. Another thought might be to use a modern programming environment like Java, and use its abstracted sound, input and networking along with OpenGL. You could always write your own wrapper library in your language of choice as well. You could also use a third-party cross platform game engine like the Torque engine that supports OpenGL.

Here's a good link for those that'd like to learn more about OpenGL in general.

As an Open Source developer myself, who likewise has their project hosted on SourceForge, maybe I can help somewhat.

This can be a really hard question to answer. Ideally you'd like to find yourself a maintainer to work with you on this sort of thing, but finding one is a different matter. Such a maintainer will either worm their own way out of the woodwork, or they won't. Recruiting one yourself will probably be a lengthy and fruitless prospect.

In the more than two years my project has been Open Source (it was closed source freeware for 5 years), recruiting more people to work on the project has been nearly useless. In that time, after lots of recruitment campaigns, I've found only 4 or 5 people who have actually made any significant contributions to the project and all of its sub-projects (the last time I tried to run a recruitment campaign a few weeks ago I got about 50 responses, virtually all from India, who somehow interpreted "looking for a volunteer developer" to mean I was looking to hire someone for a job :P).

Depends completely on your project. SourceForge is a good general place to host your project if nothing else fits -- they provide a good service IMO -- but they also host any project which is Open Source. If you can find one, you might be better off using something which is a more targeted community for your type of project, whether it be by language/develpment environment used, target OS, application type, etc. That is, if you're developing a Java-based project, java.net is a good choice, as everyone there is working in Java. If you're developing on OS/2, netlabs.org is where you'll find other OS/2 developers (what few there still are). If you're coding for Linux on the PlayStation 2, playstation2-linux.com is the place for you.

Don't forget -- nothing really prevents you from registering your project on every project site that suits your project, although maintaining all of those active communities might prove very time consuming!

Create your own. Typically what I do is credit the user by name and e-mail address during the CVS check-in. As I use the CVS log as the basis of the changelog for each release, this information also becomes part of the changelog. I also try to add an entry for them to my "Special Thanks" section of my Release Notes, and sometimes a comment crediting their fix/addition right in the source code. If the contribution is really significant, they usually also get a credit in the copyright statement.

One thing you should do, however, (something that I try to do at least), is to ask them if they want credit. Some people won't (and I've had a few contributions like this) for various reasons. Maybe they don't want to be bothered with questions, or maybe their employer has a draconian policy against this sort of thing (although in the latter case, you probably don't want to accept anything new from them so as to CYA. A minor fix that won't be subject to any copyright problems should be fine, however (ie: someone pointing out that an "i--" should be "i++", etc.).

Well, there used to be a standard, but far too many projects have v

Always google before posting.

Xalan for XSLT and XPath processing. Here's a tip: Never, ever use SAX for XML parsing of application-specific data structures. SAX is a nice low-level interface for building upon, but unless you're programmatically emitting a document from scratch, it's painful to use -- you always end up writing a stack-based content handler to keep nesting state. XPath makes parsing a breeze.

JGroups (formerly JavaGroups) is a protocol stack for building reliable, fairly efficient network communications based on, among other things, multicast IP. The entire stack is user-defineable, so you can pick and choose the level of reliability and which features you want (TCP support, pinging, group membership management etc.).

Lucene is a text-indexing engine. It's actually pretty crap, and does not scale very far (we're talking a few seconds for result sets of only a few thousand documents), and the code is pure spaghetti (abstract base classes! Inheritance!), but if you need a little indexing engine or some decent text tokenization classes, and your performance requirements are modest, it works well enough.

SableCC is a good BNF-based parser generator that generates type-safe parse trees that can navigated at runtime. Unlike the more well-known JavaCC, it's easy to get started, not least because the BNF-like grammar is so simple.

Project Looking Glass builds its windows, etc. within the framework of the Java3D Scenegraph API, therefore it actually does have real 3D coordinates. The navigation interactions that they have built into the desktop don't allow you to move it, but there's nothing stopping you from displaying the desktop in stereo and programming in new behaviours that move the windows any way you want. Especially since the source code is available

It's an embedded chip which has a CLR on top of it. Nice idea, sorry that Sun thought of it earlier ( The Green Project) - Sun seems to be consistently missing the BUS here. They came up with "Network is the computer" and now MS is selling ".NET " :)

Project Looking Glass
This was demo'ed at JavaOne this year, and really had some catchy visual features. Window contents can be saved to a backing pixmap and then applied to (wrapped around) objects of any shape.

Windows could be rotated (for example, post-its or config info was stuck to the back of a flat window in several cases)

This is still in the prototype stage, but the developer's release is open-sourced and available at java.net.

Actually, now you can download the source to Java 6 and soon you will be able to submit patches. It's opening up bit by bit:
Patches

Ken Arnold's blog on java.net has a great (IMHO) idea for reforming the patent system that make it self-correcting and gives incentives for the patent lawyerst to enforce it.
http://weblogs.java.net/blog/arnold/archive/2004/1 1/selfenforcing_p_1.html