Sun started posting weekly snapshots of Mustang (Java SE 6) source and binaries to java.net in November 2004 for developers to evaluate and help report bugs, contribute fixes, and make suggestions. Since then, roughly 70,000 binary snapshots have been downloaded, close to 400 bugs have been reported, and over 200 fixes have been submitted.

Here are a few of the things just added to build 76 (bug IDs in parentheses):

• Windows JMF, the all-Java Language version, works (6372428)
• JTable users will be pleased that their tables sort when you double-click on the header (6358882). If using GTK L&F, grid lines will be repainted correctly (6388055)
• 5074573 adds support for Ctrl+Backspace and Ctrl+Delete on all text components except JPasswordField.

Two developer contributed fixes are also included in this build:

• 4741757 LTP: XMLEncoder ignores persistence delegates when used with java
• 6379178 BasicComboBoxUI.ListDataHandler.contentsChanged doesn't mark display

You can see the b76 status page for all changes made in build 76.

About a year ago Sun enveloped the Mustang project into the JDK Community to promote additional research, collaboration and discussion about Java SE. I've listed some stats and info about its progress in a blog ("Where we are with the JDK Community") for those of you who are interested.

We at Sun want to learn what we're doing right and where we can improve. We want to know what you need as developers to be more aware of what's going on inside Java SE engineering and whether Sun is providing you with enough opportunity to be a part of Java SE development. Even if you've never visited the community, take a look at it and tell us how Sun can best meet the needs of Java developers.

To help facilitate collecting this information, we've posted a survey to make it easy. It should take you less than 15 minutes to complete.

Oh yeah... there's just 2 weeks left in the Mustang Regressions Challenge. Make sure you test your code and report any binary compatibility problems you find in the Mustang snapshots for a chance to win a sweet Ultra 20 workstation. Check the contest rules for details and eligibility.

Ray Gans
Sun Microsystems, Inc.

What is status on including GroupLayout decission?
(aka Matise)
To keep showing it; at JavaOne and not include it in the Q3 '06 release is a problem.

(compare it to C# layouts shiped in '05. Java 5 fixed L&F w/ Synth, and Webstart is fixed. Good thing about SwingWorker in 6)
 
We need a good layout included to baseline. We could have everything, it's such a small thing, 3 classes. You can allways improve them in Java 7. By the time Java 6 is widely deployed to desktops it will be 2008-9.
(Check out WinFX relative in that time frame, it will be included in 98% of desktops.
http://www.erain.com/products/zam3d/screenshots )

.V

ps: Also, you can remove JavaScript outside of the JRE. (aka Rhino built into 6??) In general, there should be a thin down JRE subproject to remove rarley used classes out of rt.jar, etc. (maybe omg package should move to jee.jar, rarley used in desktop )

GroupLayout is included in b76 :)

Wow, I see it.

THANK YOU SUN!
Sorry to be pita.
.V

really, what's the need to inlude these 3 classes in the jre? can you just distribute them as part of your application?

will you require your end user to have this jre installed? in the java world, java guis are subject to what jre is on the client machine. i'd guess that's going to be whatever is shipped with Windows XP and to a lesser extent, 2000.

IMO, in order for java desktop to really come back into the playing field, there must be a modern sun jre installed on every workstation. vista could be a vehicle for doing this, but somehow i don't see that happening.

regardless, when something is put into the jre it's there for life and it's hard to get around it. when you distribute this tiny, tiny jar with your application, you get to upgrade to use a new version when ever you choose.

Why not split the runtime (jre) and libraries?

I remember when I started to learn java (1.0.2), I was very happy to have Hashmap,... in the standard distribution. But I also remember the frustration when I want to use swing or collection,... first distributed as external lib and then included in the jre (always the case see jdbc extenstion...). Include lot of package in the jre generate a release dependency beetween packages.

Why not split runtime from libs and provide lib (group of package) as severals jar. Jar distributed with the jdk but overrideable/distributable by application.

Like this an application could choose/distribute whatever version of swing, jdbc,... And Sun could release lib bug fix earlier (no more need to wait for the Java version)

i think Rhino is not included in JRE but JDK. So it does not matter. However, i think the rt.jar (uncompressed) is about %20 larger then the Java5. But this is not the final numbers, may change (especially with the addition of the group layout you always wanted). i do not know how will be the final download size of the JRE tough (compressed).

... In general, there should be a thin down JRE subproject to remove rarley used classes out of rt.jar, etc. (maybe omg package should move to jee.jar, rarley used in desktop )

+ 1.0 * 10^23

Its very very painful to handle date and time in java.
Calendar etc hasnt really done a good job.
A simple string to date , date to string, simple format recognitions, date validation like leap year etc should be built in.

Please please look into it.
thanks

Hi

Maybe Joda-Time http://joda-time.sourceforge.net/ can do this for you.

Cheers,
Thomas

HiMaybe Joda-Time http://joda-time.sourceforge.net/ can do this for you.Cheers,Thomas

i have used Joda and apache commons for this so far. But i want SUN JDK to have that too. Date handling is so important to any language, but somehow java language has always lacked the ease of use for handling dates.
I hope they take a note of it.

We need access to parameterized type information at runtime. That is for:

List<Employee> getEmployees();

I want to be able to reflectively access the fact that Employee is the intended type.

I KNOW ABOUT ERASURE. So let's not talk about that.

See here's the deal, right now I have to do this:

// don't mind that it's actually a collection, bear with me
@ReturnCollectionType(Employee.class)
List<Employee> getEmployees();

That allows me to reflectively access the return type, but it's ugly, verbose, and still error prone, as I can mismatch the type parameter for the metadata and the generic class.

So, why not make use of the metadata facilities that already exist and do this for me? The reflection API can easily include methods to access such information at runtime, and you can protect yourself from name collisions by simply using a name for the annotation that is illegal to the Java compiler.

If I'm being at all unclear, please let me know.

Best regards,

Clinton

The annotation is not necessary, you can use the following:

    Method method = getClass().getMethod("getEmployees", new Class[0]);
    Type type = method.getGenericReturnType();
    if (type instanceof ParameterizedType) {
      ParameterizedType tv = (ParameterizedType) type;
      Type[] arguments = tv.getActualTypeArguments();
      assertEquals(1, arguments.length());
      assertEquals(Employee.class, arguments[0]);
    }

The annotation is not necessary, you can use the following

Thank you very much for this. I wonder why I had such a hard time finding that? Everywhere I looked just said: "nope, it's erased and inaccessible."

Thank you again, this is helpful.

Clinton

Clinton,

Only the parmeterization information of actual *instances* is erased. So if you create an instance of List<Employee> you can only see List.

Rob

This will teach me to automatically trust luminaries. Even if it is Bruce Eckel and Anders Hejlsberg (and for spending a year submerged in C#). ;-)

"...Java's generics implementation relies on erasure of the type parameter, when you get to runtime, you don't actually have a faithful representation of what you had at compile time. When you apply reflection to a generic List in Java, you can't tell what the List is a List of."

http://www.artima.com/intv/generics2.html

Obviously wrong, as the unit test Wolfgang posted passes.

Thanks again for clearing this up.

Clinton

Clinton, the statement you quoted is not talking about reflection on methods that use generic types--it is talking about reflection on instances of generic types. In Wolfgang's example, he is extracting the return type of a method. That is possible. But, given an instance of java.util.List, it is not possible to find out at runtime if it is, e.g. a List<Integer> or a List<String>.

That is possible. But, given an instance of java.util.List, it is not possible to find out at runtime if it is....

Yep, got it. Although that's still weak, in my case I only need the type information for method return types, and possibly for fields...but I'll read the docs to figure that out, rather than read someone's blog. ;-)

Clinton

We at Sun want to learn what we're doing right and where we can improve.

How about making it available under an open source license so the community can share the burden of developing the classlibrary in a way that allows us to equally benefit from the collective result? :)

geir

well. download the code and colaborate. both are possible. what stops you? Although, i admit Sun immediately has to make the code available through subversion or CVS

well. download the code and colaborate. both are possible. what stops you? Although, i admit Sun immediately has to make the code available through subversion or CVS

THe license is the problem. I can't take the source, make a modification (say a performance improvement, or port to a new operating system), certify it with the TCK to ensure compatibility, and redistribute it without having to negotiate a contract with Sun to do so.

I don't mind doing work and contributing it for others to use, but I do mind having to buy my own contributions back so I can use them. :)

geir

THe license is the problem. I can't take the source, make a modification

I think we all know what GlueCode was accused of doing when it took the source from jBoss OS license, it removed attribution, via ASF and check it into GlueCode, refacotring GPL liense (becuase there was no patents this was legal).

And.... I just don't see any CVS/SVC comitts you Geir do on apache lists at least, maybe you are one of them marketing types.

I have no problem w/ Sun license *as long as they are invoating*. When they lay down and play dead, then I am happy for Harmony, JRockit, IBM JVM (for runing on Yellow Dog, etc.).

.V

Good to see you, Vic! It's always amazing to see how you just can't get off this hobby horse - or get your facts right.

THe license is the problem. I can't take the source, make a modification

I think we all know what GlueCode was accused of doing when it took the source from jBoss OS license, it removed attribution, via ASF and check it into GlueCode, refacotring GPL liense (becuase there was no patents this was legal).

If you remember Vic, that wasn't "GlueCode", it was "Geronoimo", and if you also remember, there wasn't any issue. JBoss alerted us to some concerns they had, and it was put to rest to the satisfaction of all parties. I certainly wish you'd find something factual to talk about.
 

And.... I just don't see any CVS/SVC comitts you Geir do on apache lists at least, maybe you are one of them marketing types.

Maybe. ;) But given your consistent failure to get the details right regarding Geronimo, it's not surprising you got this wrong as well.

I have no problem w/ Sun license *as long as they are invoating*. When they lay down and play dead, then I am happy for Harmony, JRockit, IBM JVM (for runing on Yellow Dog, etc.). .V

The cool thing is having choices, isn't it? (Note that all three use the same class library from Sun, so when that innovation stops - say when Google buys Sun <joke>http://www.theinquirer.net/?article=30382> - where does that leave you? )

geir

that wasn't "GlueCode", it was "Geronoimo", and if you also remember, there wasn't any issue.

I said in my post "via ASF".
"No issue" ... meaning you got away w/ it so far.

I would have no problem if you left attribution in the code, "originaly by jBoss " or similar.
The justice is... now you have an EJB. Enjoy it.

.V

ps: I linked the facts to back it up in the past from documents, etc, you can verbaly spin it all you want, Geir. I did not see a link to "jBoss says they are ok w/ it now". They may not have the $ to sue, so maybe they are waiting for more $ damages to occur.

that wasn't "GlueCode", it was "Geronoimo", and if you also remember, there wasn't any issue.

I said in my post "via ASF". "No issue" ... meaning you got away w/ it so far.I would have no problem if you left attribution in the code, "originaly by jBoss " or similar.The justice is... now you have an EJB. Enjoy it. .Vps: I linked the facts to back it up in the past from documents, etc, you can verbaly spin it all you want, Geir. I did not see a link to "jBoss says they are ok w/ it now". They may not have the $ to sue, so maybe they are waiting for more $ damages to occur.

Oh, c'mon Vic, give it up... it's been years now and you still haven't grokked what happened. Let it be.

geir

it's been years now and you still haven't grokked what happened.

We all have a good idea what happened, and what evidence got altered.

It’s just shameless for you to think that you, Geir, should be one brining up any Open Source license, after the jBoss complaint that their code was “re-licensed”.
Certainly Java source code is available from Sun freely, under their license, attribution and source improvements go back to them. Just like (jBoss) GPL was supposed to work.

It does not take a big mental jump, you’d like us to think you covered your tracks; and for us to forget. It be a shame if people just started hiring marketing types that might take original designs and ideas away from engineers and re-market under another license. It lowers the value of engineers. It worked out in this case for GlueCode.com.

ASF Harmony must be a clean room implementation. (just like old Compaq re-implemented the IBM bios). Having Geir/GlueCode involved does not help credibility. A few apples like that and no one would risk exposing their source, that is normaly used for good.

.V

I'm starting to suspect that you just troll for fun here, so I'm going to take it as such :)

it's been years now and you still haven't grokked what happened.

We all have a good idea what happened, and what evidence got altered.

"evidence" wasn't altered. You know the whole story, so stop pretending. We've been through this before. It's all available in public records for anyone to see. The trick, Vic, is to read all of it, not just select the bits you want to support this strange conspiracy theory you have.

It's just shameless for you to think that you, Geir, should be one brining up any Open Source license, after the jBoss complaint that their code was re-licensed.

Out of respect for everyone involved, on both the JBoss and Apache sides, I really don't see any upside in rehashing the details. Both communities have moved on.

Everyone can read the details and come to their own conclusions.

Certainly Java source code is available from Sun freely, under their license, attribution and source improvements go back to them.

I guess you need to define "free" then. There are restrictions placed upon you that prevent you from using it. That's not "free", unless you mean "no charge".

Just like (jBoss) GPL was supposed to work.It does not take a big mental jump,

Facts, Vic. Facts. While your accusations aren't believeable because they are just plain wrong, you might be able to fool someone if you got *any* of your facts right. JBoss code is available under the LGPL, which is quite different than the GPL.

you'd like us to think you covered your tracks; and for us to forget. It be a shame if people just started hiring marketing types that might take original designs and ideas away from engineers and re-market under another license. It lowers the value of engineers.

Vic, it's all available in publicly accessible archives. Take off the tin-foil hat and join us in the reality-based community. With the exception of this issue, you seem to be a level-headed and smart guy.

It worked out in this case for GlueCode.com.

Heh. We've been through this before. It had nothing to do with Gluecode (not a ".com", btw). Any involvement of Geronimo project members with Gluecode came at least 6 months after the discussion with JBoss. A simple calendar will help you arrive at the same conclusion. I've explained this countless times. Please try to remember it.

 ASF Harmony must be a clean room implementation. (just like old Compaq re-implemented the IBM bios).

Vic, there are *specs* for Java SE. That is the *point* behind the JCP, Vic - that specs are created, and people create independent implementations.

Having Geir/GlueCode involved does not help credibility. A few apples like that and no one would risk exposing their source, that is normaly used for good..V

1) Gluecode nevre had anything to do with Harmony.
2) Intel, IBM and others have made major contributions.
3) We already have enough classlibrary to run Eclipse.

Please stop slandering me, Vic. It's unprofessional and getting tiresome.

geir

Geir,
No one here has ambition of teching you ethics or giving you a moral compass.

As far as facts re:code, here is an etichal example from contirubtors to Java clone:
http://www.gnu.org/software/classpathx
It says that you can't look at Sun's code.
And here is what people think is unethical, bypasing CVS so that the orginal code and their changes are not seen:
http://mail-archives.apache.org/mod_mbox/incubator-general/200311.mbox/%3C43008338-1C37-11D8-A4C7-000A95A01192 at 4quarters dot com%3E
One would expect to submit a change in CVS, so there is a track record.
This is a good reason to use an obtusifier in your ant scrtip, parasites.

re:attribution:
http://www.hessiancsharp.org - see how they attribute to orignal design ideas! Of course it was re-impleneted in a diferent langage. And:
http://geronimo.apache.org/20041028_jbossresponse.pdf - Again, your words that only ideas were copied on page 8.
The only way to assure ideas are not copied is to patent, to protect against parasites. No one linkes patents, but GlueCode and Geir are a good argment for patents.

So there are some ethical issues, a bit of a gray area for sure, use your moral compass to see what is best for the profesion. jBoss did accuse GlueCode employees of takeing code and ideas of work for hire code and removing atttribution, and that is a fact. You said jBoss is OK w/ it, url?

You stated that your work for GlueCode, and you are involved in Harmony as per posts. Do I need to link them?
Therefore, GlueCode is somewhat assoicated w/ Harmony - so why play stupid.
It may be wise of Sun to patent parts of Java.

You bring a colud of doubt as to Harmony for sure. Had you and GlueCode stayed out, it would be a warm and fuzzy.


You made claims that you code in this thread, can you give us a url of your oringal source code comitt (in ASF where each committ is normaly tracked or elsewhere. ot: my comits are on sf.net infonoia project)?
Again, a facutal url of code you wrote should be easy, no?

In general, you started this sub-thread by calling on Sun to open source their code (which it is open source, do you want an url).
My response is that due to your recent track record, you should be the last to make that claim.

Now you can spin w/ words but nor urls, or find a marketing forum to "contribute".

.V

Geir, No one here has ambition of teching you ethics or giving you a moral compass. As far as facts re:code, here is an etichal example from contirubtors to Java clone:http://www.gnu.org/software/classpathxIt says that you can't look at Sun's code.

You can't look at Sun's code not because of ethical reasons, but because it historically hasn't been licensed in a way that was clear about retention by unaided memory.

Notice how they have no restrictions about looking at open source code - the premise behind open source (free software, really) is to "to preserve, protect and promote the freedom to use, study, copy, modify, and redistribute computer software".

Now, the issue of copyright infringement is entirely different than independently implementing an idea you have seen somewhere,but that's not what we're talking about.

And here is what people think is unethical, bypasing CVS so that the orginal code and their changes are not seen:http://mail-archives.apache.org/mod_mbox/incubator-general/200311.mbox/%3C43008338-1C37-11D8-A4C7-000A95A01192 at 4quarters dot com%3EOne would expect to submit a change in CVS, so there is a track record.

Are you referring to taking the CVS offline? LOL That's done for one reason only - so that the ASF doesn't engage in contributory infringement of someone elses copyright. By removing public access to all forms of the code in question, the ASF was giving JBoss the benefit of the doubt and stopping all redistribution while it investigated the claim. We do it anytime there is a question about code provenance. The ASF has done it before and since, and I expect it will happen again. This kind of oversight is one of the reasons the ASF exists.

This is a good reason to use an obtusifier in your ant scrtip, parasites.

I'm going to assume this some cut and paste mistake, as it's much more incoherent than usual.

re:attribution:http://www.hessiancsharp.org - see how they attribute to orignal design ideas! Of course it was re-impleneted in a diferent langage. And:http://geronimo.apache.org/20041028_jbossresponse.pdf - Again, your words that only ideas were copied on page 8. The only way to assure ideas are not copied is to patent, to protect against parasites. No one linkes patents, but GlueCode and Geir are a good argment for patents.So there are some ethical issues, a bit of a gray area for sure, use your moral compass to see what is best for the profesion. jBoss did accuse GlueCode employees of takeing code and ideas of work for hire code and removing atttribution, and that is a fact.

Not exactly. Go read the letter. There were no Gluecode employees working on Geronimo at that time. That happened months later after all was resolved.

And the code that was assumed to have had attribution removed was originally code from Apache Log4J, which is apache licensed. Go review the facts again.

You said jBoss is OK w/ it, url?You stated that your work for GlueCode, and you are involved in Harmony as per posts. Do I need to link them?

Yes, you'll have to.

I stopped working for Gluecode before Harmony was announced, if my memory serves me. (And either way, Gluecode had no business interest in Harmony....)

Therefore, GlueCode is somewhat assoicated w/ Harmony - so why play stupid.

I guess my cat is somewhat associated with Harmony because I had it while I was working on Harmony, as is the hamburger I ate that week?

It may be wise of Sun to patent parts of Java.You bring a colud of doubt as to Harmony for sure. Had you and GlueCode stayed out, it would be a warm and fuzzy.You made claims that you code in this thread, can you give us a url of your oringal source code comitt (in ASF where each committ is normaly tracked or elsewhere. ot: my comits are on sf.net infonoia project)?

We're going to play "my commit is bigger than your commit"? You'r commits are bigger. You win. Clearly, I'm doing more management than heads down coding these days, but I still code. It ebbs and flows. Maybe for fun I'll correct your code on my blog. ;)

As for patenting parts of Java, Sun can and has certainly done that, as have lots of other companies. IBM has patents in that area, I'd bet (I don't know for sure). And any independent implementation of Java that passes the TCK gets the rights to any patents Sun (and any other member of the expert group) has if they are necessary for implementing Java. This applies to any JSR. I have no clue why you'd bring this up unless you didn't understand that.

Again, a facutal url of code you wrote should be easy, no?In general, you started this sub-thread by calling on Sun to open source their code (which it is open source, do you want an url).

Yes please. Give me a URL for Java SE code that is available under an open source license. Please. Please. Please. Please.

My response is that due to your recent track record, you should be the last to make that claim.Now you can spin w/ words but nor urls, or find a marketing forum to "contribute"..V

I'm not sure what to say here, Vic. The simple fact is that your understanding of the JBoss/Geronimo issue is completely and utterly wrong. We've gone over this countless times, it seems, and my only explanation is that you have some pathological dislike for me, and thus refuse to acknowledge the facts.

The code that was mentioned either was code that was dual licensed by an original author (so they had the right to contribute to anyone under any license of their choosing) or code that originally came from Apache itself. JBoss Inc, as steward of their codebase was right in calling it to the attention of the ASF. The ASF did the right thing - they stopped redistributing the code (by shutting down access to CVS) and examined the claims in detail. I was the personal face on it (someone had to write email), but it was overseen by the Incubator PMC, the ASF membership, and the board.

My father once said something very wise - "Never argue with a fool - people might not know the difference". I'm thinking of heeding his advice... :)

geir

It's like a color blind person can't tell red/green.
You said on this same page that you code... and now you say you don't. Which time did you lie, Geir? It does not neve bother you to notice it.
So another reason you might not contribute to OS code, is that ... you can't.

CVS down as issue? no, no.
Let me go over it again at a PHB level.
In http://mail-archives.apache.org/mod_mbox/incubator-general/200311.mbox/%3C43008338-1C37-11D8-A4C7-000A95A01192 at 4quarters dot com%3E

You stated that " org.jboss.util.platform.Constants.LINE_SEPARATOR; " was comited to ASF cvs in 1st few paragraphs.
So code check out from jBoss, put into ASF as per that sentence. (what would be an alternative explenation other then re-factoring in progress, that else on web pages was stated as a plan - the sf.net "laticework" plan)
One reason engineers use CVS is to see original code and changes.
Normaly, one would do a comitt to CVS to change any code.

What you argue in the rest of the email is that there should be no track record in CVS of the original code, and only the later version w/o jBoss reference should be in ASF (so that we can't tell the original code). So, no, it's not that CVS was taken down, it's that it was manualy edited so we can't tell original code.
All I am saying, one should not manualy by pass cvs revisions. (and ... that if you took "ideas" from jBoss, you should state so someplace prominent, like majority of the communitiy does)

You don't work for GlueCode... becuase it's acquired by IBM so now you work for IBM? that be Spin. I guess it worked out for you.


It's pathological, your dad should have showed you ethics instead of whatever he did. You just can't see lie from truth as that diferent.

.V

You stated that your work for GlueCode, and you are involved in Harmony as per posts. Do I need to link them?
-- Yes, you'll have to.
And either way, Gluecode had no business interest in Harmony

Here is a link: http://www.sdtimes.com/article/story-20060315-01.html
Makes it clear that again - lies and half truths. But he has "no problem" w/ it.

My problem is not w/ you Geir as personal (but I can see why would'd like people to think it was personal, for FUD) but any GludeCode employees that are accused of taking code from jBoss w/o attribution to jBoss! and refactoried it into GlueCode, via ASF, and packged the dervied code (derived LGPL is GPL) to IBM.... (yes the snake changes skins a few times, but it's the same group of people, under ever changing org names). You asked for facts, and I gave you facts:
1: jBoss code in ASF
2: Admition that jBoss ideas where used (a shade diferent from refactored)

And any "engineer" that does not attribute the source when they take orignial ideas is a problem. Else, it's cheaper for mangers to hire somone to refactor thensomone to design, and where are we then.

Most people that contribute to TSS are coders, so you won't get sympathy here.

And back to the orignial thread, I think Sun Java 6 is great improbment, exeding my expectations. Synt, swingworker, GroupLayout and JNLP are cleaned up. One area of improvement is a sub project to make the jre and rt.jar simpler/smaler.

.V

I clearly didn't listen to dad...

You stated that your work for GlueCode, and you are involved in Harmony as per posts. Do I need to link them? -- Yes, you'll have to.And either way, Gluecode had no business interest in Harmony

Here is a link: http://www.sdtimes.com/article/story-20060315-01.htmlMakes it clear that again - lies and half truths. But he has "no problem" w/ it.

Is there a point here, Vic? I work for Intel, and participate in the Harmony project. What "lies and half truths" are there in that article?

Gluecode doesn't exist anymore. It was bought by IBM. Gluecode, a company that was focused on offering services for enterprise open source projects, had no interest in an open source Java SE implementation.

My problem is not w/ you Geir as personal (but I can see why would'd like people to think it was personal, for FUD) but any GludeCode employees that are accused of taking code from jBoss w/o attribution to jBoss! and refactoried it into GlueCode, via ASF, and packged the dervied code (derived LGPL is GPL) to IBM.... (yes the snake changes skins a few times, but it's the same group of people, under ever changing org names).

I give up.

You asked for facts, and I gave you facts:1: jBoss code in ASF2: Admition that jBoss ideas where used (a shade diferent from refactored)And any "engineer" that does not attribute the source when they take orignial ideas is a problem.

Those aren't facts. Those are your interpretations.

1) Someone who contributed code to JBoss contributed the same code to the ASF. Dual licensing is perfectly legal. We all know the mistake that person made, and there is a public open record of it. Not sure what you are seeing here.

2) Let me ask you a question. Do you attribute every design pattern you use, every code idiom? How do you avoid the double-checked locking pattern :

if (resource == null) {
      synchronized {
        if (resource == null)
          resource = new Resource();
      }

Did you yourself realize that it had problems on multiprocessor machines, or did you read about it? I'm betting you read about it. When you read about it, did you see other broken ways of coding around it? Did someone then show you the right thing to do?

Do you give attribution to those people every time you do something similar, or do you consider it part of your experience and knowledge now?

Else, it's cheaper for mangers to hire somone to refactor thensomone to design, and where are we then.Most people that contribute to TSS are coders, so you won't get sympathy here.And back to the orignial thread, I think Sun Java 6 is great improbment, exeding my expectations. Synt, swingworker, GroupLayout and JNLP are cleaned up. One area of improvement is a sub project to make the jre and rt.jar simpler/smaler..V

You'll get no argument that Java 6 is a great improvement. You really don't understand what Harmony is about, do you?

geir

You asked for facts, and I gave you facts:1: jBoss code in ASF2: Admition that jBoss ideas where used (a shade diferent from refactored)And any "engineer" that does not attribute the source when they take orignial ideas is a problem.

Those aren't facts. Those are your interpretations.1) Someone who contributed code to JBoss contributed the same code to the ASF. Dual licensing is perfectly legal. We all know the mistake that person made, and there is a public open record of it. Not sure what you are seeing here.

I'd say that guy had some serious split personality disorder: he's stealing ideas from himself! :)

he's stealing ideas from himself! :)

Ah, so now we moved on to the next step.
Step 1 is that:
- GlueCode (aka CDN, etc.) planed (on sf.net) to take the code
- It did take the code (as per asf post on jboss package and notes to delete it)
- It did so becuase there were no patents (as per "ideas were copied resonse")

The next step which I will leave it up to others is that was it ethical (to take "work for hire"? designs) to remove atribution.


.V

look at Sun's code not because of ethical reasons, but because it historically hasn't been licensed in a way that was clear about retention by unaided memory.

I like Geir, especialy if Harmony gets developed faster then Classpath. Nothing illegal w/ retention as he explains, and there are more people benefiting then just the author.

Jon

i dont think it should be that way. the better approach for Sun is to make the access and incorporating the fixes faster and easier. Also a faster update cycle maybe. Maybe a bundled-redistirbution of re-compiled java should be allowed, and i think it is already possible to a degree ( http://java.net/jiul.csp ) but should be more relaxed.

We at Sun want to learn what we're doing right and where we can improve.

How about making it available under an open source license so the community can share the burden of developing the classlibrary in a way that allows us to equally benefit from the collective result? :)geir

Instead of complaining, do something productive. Download the source use it and collaborate. There is nothing stopping from doing that right now. Just because it is not GPL it does not means it is not open source.

Perhaps you need to beef up on your English skills. Look at the word "Open Source". Java 1.6 is "Open Source", the fact that the source is open to all and that is what really matters IMO.

Good luck building it though...

We at Sun want to learn what we're doing right and where we can improve.

How about making it available under an open source license so the community can share the burden of developing the classlibrary in a way that allows us to equally benefit from the collective result? :)geir

Instead of complaining, do something productive.

This is a troll, right? Take a look at http://incubator.apache.org/harmony/

That's something productive, IMO - we're making an Open Source version of Java SE.

Download the source use it and collaborate. There is nothing stopping from doing that right now. Just because it is not GPL it does not means it is not open source.

No, but because it's not under an open source license means it's not open source.

Perhaps you need to beef up on your English skills. Look at the word "Open Source". Java 1.6 is "Open Source", the fact that the source is open to all and that is what really matters IMO.Good luck building it though...

As a native speaker of English, I *think* my English reading, writing and speaking skills are ok :) I do seem to be misunderstood at time though...

I suspect, though, that the problem is you have little to no understanding what "open source" is generally understood to mean. It doesn't mean only that you can see the source - it also means that you can modify and distribute the resulting derivative work under generally liberal and unrestrictive terms. See http://opensource.org/docs/definition.php for the generally accepted definition of what makes an open source license.

geir

Not yet another one of those Sun pseudo-open source PR things. Let them sit on their proprietary code until its useless. For all I've heard about it, it is pretty unmaintainable, anyway.

cheers,
dalibor topic

Not yet another one of those Sun pseudo-open source PR things. Let them sit on their proprietary code until its useless. For all I've heard about it, it is pretty unmaintainable, anyway.cheers,dalibor topic

Please dont open up java source code. Currently managing 10000000 of the open source projects has been a problem already. Managing their versions, build numbers and the errors is a nightmare. [ I m talking about real big clients here developing and investing in technology for years to come and not a small dot com environment where you can make any decision any day. ]
Let sun be the owner. they have done a great job so far. Ofcourse there is always some issues here n there. but overall its been a great language. So please dont open it up and create a million versions of java source code and confuse the community. Some control is always good. Let them take some suggestions and be the one place to go for
standard version.

Having seen a great talk & demo on Spec# today, I've seen the future of Java, or better: what Java could have been if things were different.

If we had an actual JDK community. If Java had a rosy, bright future ahead. If the bright people in the field could work with Sun, rather than end up working at Microsoft.

Given that the things are the way they are, and both Sun and Sun's fanbase likes it that way ... it's a pointless discussion. So pardon me for getting out of it early.

cheers,
dalibor topic

Given that the things are the way they are, and both Sun and Sun's fanbase likes it that way ... it's a pointless discussion. So pardon me for getting out of it early.cheers,dalibor topic

Some of us appreciate the work Sun and the JCP have done as we still have scars from the "standardization" of C++...

Given that the things are the way they are, and both Sun and Sun's fanbase likes it that way ... it's a pointless discussion. So pardon me for getting out of it early.cheers,dalibor topic

Some of us appreciate the work Sun and the JCP have done as we still have scars from the "standardization" of C++...

No one is advocating creating anything but the standard Java SE that is defined by the JCP.

Any implementation, open source or not, must be compatible with the TCK, which Sun (as the spec lead for Java SE) produces for the express purpose of testing independent implementations.

That's the beauty of Java, in theory - that it's a spec-driven ecosystem in which the technology is defined by the spec, indpendent implementations are created, and they are tested for compliance with the spec by the TCK.

Compare to what happened with J2EE - the ecosystem created many different competing implementations both proprietary (WebLogic, WebSphere, Sun in the past) and open-source (Geronomo, JBoss, Jonas, Sun now) and the sky hasn't fallen. Users have choices, and some really good ones.

Java SE has the opportunity for choices to, in managablity and serviceability, portability to platform, bundling to ensure a well tested solution, etc, while at the same time being 100% compatible, as defined by Sun itself.

It's hard to see a big downside.

geir

That's the beauty of Java, in theory - that it's a spec-driven ecosystem in which the technology is defined by the spec, indpendent implementations are created, and they are tested for compliance with the spec by the TCK.

It would be nice if that was the case, and Sun's PR department certainly loves projecting that message.

The truth is that the specs are locked behind NDAs, and the TCK is released under a useless "Read only" license.

That's why no independent implementation is tested for compliance with the spec by the TCK. None. Not a single one in the past 10 years.

TCK Scholariship access is now possible (wohoo!), but plastered by NDAs, prohibiting people from working together: if I get a TCK license for Kaffe, and can't share my knowledge with Harmony, then it's not useful. If Harmony gets a TCK license, and can't run Kaffe with the TCK, it's pretty pointless, as well. Being involved with both projects, I can't split myself into a Kaffe and a Harmony half.

As it stands, the TCK Scholarship program is just a political tool for Sun to divide communities, rather than actually fostering verifiable compatibility. That would be had if the TCK was available for anyone, for anything, under non-discriminatory licensing conditions. Yeah, as if Sun would ever do that ...

What I find most frustrating about Java, is that the actual J2SE implementor community (Kaffe, gcj, Harmony ...) is stuck so badly on having to waste years working around Java's biggest obstacle: Sun.

When I see stuff like Spec#, made by people who tried working with Sun in the Java community, and then moved on to create the next generation of C# language technology at Microsoft, I wonder how much goodwill & energy Sun has so incompetently wasted in the past 10 years, and how much of it they will continue to waste.

Microsoft's language technology in Spec# is years ahead of anything in the Java world. How long will it take until my Java IDE can tell me which pre or postcondition on some core class library method I violated as I write my code? Without actually running any tests, or executing any of my code, just by quickly feeding an abstract model of my program to a fast automated theorem prover in the background. And I am not talking about rather trivial things, like checking if a type can be null.

Meanwhile, in the Java world, we're supposed to get excited about the potential addition of a new bytecode in a few years down the road, to maybe support dynamic languages better, if Sun gives its blessing to it. Wow. Oh, and there is an upcoming Java AST api in Netbeans. Double wow. It only works with Sun's Javac. Triple wow with chocolate topping.

Sigh. Java is so depressingly backwards. We're solving problems over and over again that would not be problems in the first place if Java was managed competently, by people who have a clue about involving communities, and placed the platform before their business interests.

Yes, yes, I heard the "participation age" PR nonsense, I have closely followed Sun long enough to not believe it, though. Not as long as the same people who ran Java during its "anti-participation age" are running the show.

cheers,
dalibor topic

Having a single JVM load for multiple apps. .NET already has this feature which makes it work perfect for desktop apps. Until this happens, java on the desktop is a joke. The single app per JVM may work great on servers, but having multiple instances of the JVM hogging up memory to run multiple java apps at the same time is redundant.

If I were Sun, I wouldn't release 1.6 until this was done.