NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Sun recently announced a new "JDK Collaboration" project on java.net. Andy Tripp decided to test out this new mechanism by submitting a few bug fixes. Here is a writeup of his experience.
Very good article, Andy. Thank you very much for writing it.
Some raw minor comments:
- Never send something -- to an open(source) project -- you didn't do yourself. You would just put yourself and the project in trouble.
- diff is the most common way to create patch, junit is the most widely used testing fw. Good choice.
- The third bug is in fact an API change. Shouldn't it go throught the JCP?
Regards, Guillaume
JDistro (shared runtime and swing desktop) -- J NLP (application catalog) -- Alma (source code tool) -- Slaf (swing look and feel) -- PixelsLoupanthère
> - The third bug is in fact an API change. Shouldn't
> it go throught the JCP?
Hmm...yea, I hadn't thought about that.
Now that I think about it, does Sun actually say
officially somewhere that all API changes must go
through the JCP?
Andy
Andy Tripp, CTO and Founder Jazillian
- Legacy to 'natural' Java.
I am quite happy to see your experience is generally positive (not perfect). I think this bodes quite well for Java bugs to be eradicated, especially some of those that have been on bug parade for a very long time.
I am now looking forward to Mustang with high hopes.
> > - The third bug is in fact an API change.
> Shouldn't
> > it go throught the JCP?
>
> Hmm...yea, I hadn't thought about that.
> Now that I think about it, does Sun actually say
> officially somewhere that all API changes must go
> through the JCP?
Yes every change has to go through the JCP, though for less intense changes they can go through a lightweight process.
Richard
Message was edited by:
This message was edited because I was previously incorrect in my understanding. I previously thought that lightweight changes were not made through the JCP at all, but have since been corrected. The message is correct in its current form.
An additional Bad News item you should add for those who are interested in Java JDK/VM hacking and OSS is that as soon as you look at Sun's JDK source code (and certainly once you've signed a Collaboration Agreement) you CAN NOT contribute to GPL cleanroom Java implementations such as classpath.org, GCJ, or Kaffe.
Your article should be viewed as what's wrong with Sun's decision to not make their JDK implementation freely Open Source. I have always maintained that the value of bug fixing (which Sun has never been able to get a handle on because they focus on adding features and break things faster than they fix them) outweighs the nonsense about forking (and in case you haven't heard the horse is out of the barn on that, MS already has this thing called .NET).
This is going to sound like I am trolling but I really want to know the answer. You said
"And so the final good news is that I actually "fixed the JDK" and I'll get a T-shirt for my efforts.
The bad news is that I had to ask for an extra large. "
So you spend some hours (I don't know how many) downloading, compiling, searching, isolating, coding and submitting the fixes to sun. Let's presume it took you four hours (which seems too short) and all you got in return was a ten dollar T-shirt.
If this was an open source project you would have also maybe gotten the good feeling that you have volunteered your time to give something to the world. somthing like contributing to a gift. But it's not an open source project. You have just given X number hours of free labor to a corporation who will then profit off of your labors.
So my I-am-not-trolling-and-I-really-want-to-know-the-answer question is. Why would you work for a corporation for free? Why would you donate your time to a corporation rather then an open source project or even the local soup kitchen or boys and girls club.
> So my
> I-am-not-trolling-and-I-really-want-to-know-the-answer
> question is. Why would you work for a corporation for
> free? Why would you donate your time to a corporation
> rather then an open source project or even the local
> soup kitchen or boys and girls club.
To make life better for Java users.
All things being equal, I'd get just as
much pleasure donating time to fix
Java as I'd get from doing the same for a one
of the open-source competitors.
But in fact things are not equal: Java users outnumber
the open-source alternatives by thousands to one.
I get more pleasure from affecting 5 million users
than I would for, say 1000 users (or 100, or 10,000 -
I have no idea).
Also, I believe that Java forks
are inherently bad, and do worry that if
CLASSPATH is ever finished, we'll be back to
the porting world that everyone hates. I can appreciate
that not everyone feels that way, but I do.
As for programming vs. working in a soup kitchen,
programming is what I do. It's a better use of
my time.
Andy Tripp, CTO and Founder Jazillian
- Legacy to 'natural' Java.
> You might
want
it to be that way, but it's
> not.
>
> Look at Item #18 at
>
> http://java.net/jrl.html
The FAQ entry is cute but it contradicts what the license says:
"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."
The FAQ entry would be correct if the actual license text didn't contain the explicit exception after the grant to use information. As it stands, the FAQ entry is an over-simplification that contradicts what the license says.
Given that Sun in the JRL defines Modifications to be
"any (a) change or addition to the
Technology or (b) new source or object code implementing any portion of the Technology.", they certainly assert copyrights over modifications not just changing their own code, abut also independently implementing any portion of the technology, as long as the developer is a JRL licensee.
If Sun wanted to fix that trap, they would have to remove part (b) of the modification definition, which remains in force afaict, even for residual use. There is no problem with Sun telling people they can't copy their code verbatim, or modify it as they wish: the problem is Sun telling people that their independent works fall under Sun's copyright.
The 'residual rights grant' does not protect you from violating Sun's copyrights, and as long as Sun asserts them over *your* code, *you* may have a problem there, in particular if you intend to use your code commercially or publish it under an open source license (as the JRL explicitely prohibits weaker licenses for JRL covered code and commercial use).
The other problem is in the second exception to the residual rights grant: Sun's patents. Unless Sun's source code is carefully documented to enumerate on which Sun patent some particular implementation of a class/method is based on, you have to do that research yourself for any code that you write after you terminate the license to avoid copying the patent-protected *algorithms* of Sun's implementation.
The third problem is how V.C (Termination) and III.B (Residual rights) interact: it seems to be necessary to terminate the JRL to avoid the 'All Your Code Are Belong To Us' problem of the definition of Modifications, i.e. to be able to work on an independent implemntation. On the other hand, the residual rights are not preserved after the license is terminated, just the provisions of section V, afaict.
Graham will also happily tell you that the SCSL is a superb license, see [1]
"[SCSL] was intended to be the wonderfully perfect license, designed to cover all cases," Sun VP of Java Graham Hamilton said. "The problem was, everything was all wrapped up in one enormous license, and if you would hire battalions of lawyers, you would find that the license was great. The trouble is, most people don't want to hire battalions of lawyers and find SCSL is too complicated, so there hasn't been much adoption."
So I wouldn't take things Graham says about Sun's software licenses for granted without double checking them. He unfortunately does not seem to read Sun's licenses with enough critical distance to spot the problems in them. SCSL has been identified as very problematic from the start on by free software developers in Debian, and it took Graham 5+ years to figure out that something indeed was rotten. It is simply not his area of expertise, afaict.
I Fixed the JDK!
At 4:02 PM on Apr 18, 2005, Matthew Schmidt wrote:
Fresh Jobs for Developers Post a job opportunity
Read about his bug-fixing experience here.
108 replies so far (
Post your own)
Re: I Fixed the JDK!
Very good and interesting article Andy!Cheers,
MiG Java Calendar Component, MiG Layout for Swing/SWT (Vote -> JDK)
Re: I Fixed the JDK!
Excellent article, Andy! Very well written. I hope this inspires more people to get involved in the project.P.S. Great punch-line at the end!
Excellent feedback
Very good article, Andy. Thank you very much for writing it.Some raw minor comments:
- Never send something -- to an open(source) project -- you didn't do yourself. You would just put yourself and the project in trouble.
- diff is the most common way to create patch, junit is the most widely used testing fw. Good choice.
- The third bug is in fact an API change. Shouldn't it go throught the JCP?
Regards, Guillaume
Re: Excellent feedback
> - The third bug is in fact an API change. Shouldn't> it go throught the JCP?
Hmm...yea, I hadn't thought about that.
Now that I think about it, does Sun actually say
officially somewhere that all API changes must go
through the JCP?
Andy
I am very pleased to see this...
Andy,I am quite happy to see your experience is generally positive (not perfect). I think this bodes quite well for Java bugs to be eradicated, especially some of those that have been on bug parade for a very long time.
I am now looking forward to Mustang with high hopes.
Jim
Re: Excellent feedback
> > - The third bug is in fact an API change.> Shouldn't
> > it go throught the JCP?
>
> Hmm...yea, I hadn't thought about that.
> Now that I think about it, does Sun actually say
> officially somewhere that all API changes must go
> through the JCP?
Yes every change has to go through the JCP, though for less intense changes they can go through a lightweight process.
Richard
Message was edited by:
This message was edited because I was previously incorrect in my understanding. I previously thought that lightweight changes were not made through the JCP at all, but have since been corrected. The message is correct in its current form.
Beware Open Source Java hackers
An additional Bad News item you should add for those who are interested in Java JDK/VM hacking and OSS is that as soon as you look at Sun's JDK source code (and certainly once you've signed a Collaboration Agreement) you CAN NOT contribute to GPL cleanroom Java implementations such as classpath.org, GCJ, or Kaffe.Your article should be viewed as what's wrong with Sun's decision to not make their JDK implementation freely Open Source. I have always maintained that the value of bug fixing (which Sun has never been able to get a handle on because they focus on adding features and break things faster than they fix them) outweighs the nonsense about forking (and in case you haven't heard the horse is out of the barn on that, MS already has this thing called .NET).
Jim
Wrong!
You might want it to be that way, but it's not.Look at Item #18 at
http://java.net/jrl.html
Also look at the end of the second paragraph here
http://java.sun.com/developer/technicalArticles/J2SE/peabody/
Mr Graham Hamilton himself sais that it won't taint you.
Cheers,
MiG Java Calendar Component, MiG Layout for Swing/SWT (Vote -> JDK)
Re: I Fixed the JDK!
This is going to sound like I am trolling but I really want to know the answer. You said"And so the final good news is that I actually "fixed the JDK" and I'll get a T-shirt for my efforts.
The bad news is that I had to ask for an extra large. "
So you spend some hours (I don't know how many) downloading, compiling, searching, isolating, coding and submitting the fixes to sun. Let's presume it took you four hours (which seems too short) and all you got in return was a ten dollar T-shirt.
If this was an open source project you would have also maybe gotten the good feeling that you have volunteered your time to give something to the world. somthing like contributing to a gift. But it's not an open source project. You have just given X number hours of free labor to a corporation who will then profit off of your labors.
So my I-am-not-trolling-and-I-really-want-to-know-the-answer question is. Why would you work for a corporation for free? Why would you donate your time to a corporation rather then an open source project or even the local soup kitchen or boys and girls club.
Re: I Fixed the JDK!
So that lille Jimmy, 7, can download a higher quality programming language development kit for free when he starts programming?Cheers,
MiG Java Calendar Component, MiG Layout for Swing/SWT (Vote -> JDK)
Re: Wrong!
Thanks for the heads up. This is definitely good news. That's one less reason for disliking Sun.Re: I Fixed the JDK!
> So my> I-am-not-trolling-and-I-really-want-to-know-the-answer
> question is. Why would you work for a corporation for
> free? Why would you donate your time to a corporation
> rather then an open source project or even the local
> soup kitchen or boys and girls club.
To make life better for Java users.
All things being equal, I'd get just as
much pleasure donating time to fix
Java as I'd get from doing the same for a one
of the open-source competitors.
But in fact things are not equal: Java users outnumber
the open-source alternatives by thousands to one.
I get more pleasure from affecting 5 million users
than I would for, say 1000 users (or 100, or 10,000 -
I have no idea).
Also, I believe that Java forks
are inherently bad, and do worry that if
CLASSPATH is ever finished, we'll be back to
the porting world that everyone hates. I can appreciate
that not everyone feels that way, but I do.
As for programming vs. working in a soup kitchen,
programming is what I do. It's a better use of
my time.
Read the fine license, Mikael, it *is* tainting
> You might want it to be that way, but it's> not.
>
> Look at Item #18 at
>
> http://java.net/jrl.html
The FAQ entry is cute but it contradicts what the license says:
"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."
The FAQ entry would be correct if the actual license text didn't contain the explicit exception after the grant to use information. As it stands, the FAQ entry is an over-simplification that contradicts what the license says.
Given that Sun in the JRL defines Modifications to be
"any (a) change or addition to the
Technology or (b) new source or object code implementing any portion of the Technology.", they certainly assert copyrights over modifications not just changing their own code, abut also independently implementing any portion of the technology, as long as the developer is a JRL licensee.
If Sun wanted to fix that trap, they would have to remove part (b) of the modification definition, which remains in force afaict, even for residual use. There is no problem with Sun telling people they can't copy their code verbatim, or modify it as they wish: the problem is Sun telling people that their independent works fall under Sun's copyright.
The 'residual rights grant' does not protect you from violating Sun's copyrights, and as long as Sun asserts them over *your* code, *you* may have a problem there, in particular if you intend to use your code commercially or publish it under an open source license (as the JRL explicitely prohibits weaker licenses for JRL covered code and commercial use).
The other problem is in the second exception to the residual rights grant: Sun's patents. Unless Sun's source code is carefully documented to enumerate on which Sun patent some particular implementation of a class/method is based on, you have to do that research yourself for any code that you write after you terminate the license to avoid copying the patent-protected *algorithms* of Sun's implementation.
The third problem is how V.C (Termination) and III.B (Residual rights) interact: it seems to be necessary to terminate the JRL to avoid the 'All Your Code Are Belong To Us' problem of the definition of Modifications, i.e. to be able to work on an independent implemntation. On the other hand, the residual rights are not preserved after the license is terminated, just the provisions of section V, afaict.
> Also look at the end of the second paragraph here
>
> http://java.sun.com/developer/technicalArticles/J2SE/p
> eabody/
>
> Mr Graham Hamilton himself sais that it won't taint
> you.
Graham will also happily tell you that the SCSL is a superb license, see [1]
"[SCSL] was intended to be the wonderfully perfect license, designed to cover all cases," Sun VP of Java Graham Hamilton said. "The problem was, everything was all wrapped up in one enormous license, and if you would hire battalions of lawyers, you would find that the license was great. The trouble is, most people don't want to hire battalions of lawyers and find SCSL is too complicated, so there hasn't been much adoption."
So I wouldn't take things Graham says about Sun's software licenses for granted without double checking them. He unfortunately does not seem to read Sun's licenses with enough critical distance to spot the problems in them. SCSL has been identified as very problematic from the start on by free software developers in Debian, and it took Graham 5+ years to figure out that something indeed was rotten. It is simply not his area of expertise, afaict.
cheers,
dalibor topic
[1] http://programming.itmanagersjournal.com/programming/05/03/17/0131245.shtml?tid=56
GNU Classpath - Core Libraries
IRC: irc://irc.freenode.org/#classpath | irc://irc.freenode.org/#kaffe
Give me a break!
"You read it like the devil reads the bible" - Swedish expression.You can never turn a true OSS believer i guess... NO matter what.
If you really want something to be a problem you can always find something that isn't 100% clear.
Cheers,
MiG Java Calendar Component, MiG Layout for Swing/SWT (Vote -> JDK)