Twelve ballots came in today. They all revolved around the Tiger release, so it sounds like Tiger is getting close. The specs to be approved are:

• JSR-13 Decimal Arithmetic Enhancement
• JSR-14 Add Generic Types to the Java Programming Language
• JSR-133 Java Memory Model and Thread Specification Revision
• JSR-13 Decimal Arithmetic Enhancement
• JSR-163 Java Platform Profiling Architecture
• JSR-166 Concurrency Utilities
• JSR-174 Monitoring and Management Specification for the Java Virtual Machine
• JSR-175 A Metadata Facility for the Java Programming Language
• JSR-176 J2SE 5.0 (Tiger) Release Contents
• JSR-200 Network Transfer Format for Java Archives
• JSR-201 Extending the Java Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import
• JSR-204 Unicode Supplementary Character Support
• JSR-206 Java API for XML Processing 1.3

Also, a new JSR for JavaServer Faces 1.2 has been approved: JSR-252 JavaServer Faces 1.2

Congratulation

Notice the comment on the "JSR 176 J2SETM 5.0 (Tiger) Release Contents"

On 2004-08-31 Sun Microsystems, Inc. voted Yes with the following comment:
Joy and Happiness. Hurrah! - Graham

http://jcp.org/en/jsr/results?id=2772

Notice the comment on the "JSR 176 J2SETM 5.0 (Tiger) Release Contents" On 2004-08-31 Sun Microsystems, Inc. voted Yes with the following comment:Joy and Happiness. Hurrah! - Grahamhttp://jcp.org/en/jsr/results?id=2772

Ok, I couldn't resist, but that is classic. Happy, happy, joy, joy.

Is it too late for then to cancel the "autoboxing" and "static import" part of JSR-201? I still hate t hose.

Yeah,

I feel a language should be simple. Adding lots and lots of language features will make reading code difficult.

May be we should develop atleast one more language for the JVM and have features like auto boxing and static imports put into it ;-)

Dushyanth

Yeah,I feel a language should be simple. Adding lots and lots of language features will make reading code difficult.May be we should develop atleast one more language for the JVM and have features like auto boxing and static imports put into it ;-)Dushyanth

This is a great idea. Maybe they should also have the second language contain multiple inheritence so I can still write good clean code and also write hack code with the new second language. To bad Groovy or JPython did not fit that shoe.

I don't like "autoboxing" and "static import"... syntax sugar ...arghh...

I don't like "autoboxing" and "static import"... syntax sugar ...arghh...

Too much syntax sugar can get you semantic diabetes... :)

Too much syntax sugar can get you semantic diabetes... :)

I agree. Java will become much less readable and much more prone to bugs after version 5.0 is released. For the syntax of the language, they should have downgraded the version identifier from 1.5 to 0.95 : static imports are useless; autoboxing will create bugs that will be difficult to track and annotations should not have entered into the language before a clear standardisation on their use cases (all the frameworks will create their own annotations and our Java code will become messy).

I agree. Java will become much less readable and much more prone to bugs after version 5.0 is released. For the syntax of the language, they should have downgraded the version identifier from 1.5 to 0.95 : static imports are
useless;

I actually think that static imports begin to lend Java towards things like mixin functionality that you see in languages like Ruby, but it still has a long way to go.

autoboxing will create bugs that will be difficult to track

Possibly.

 (all the frameworks will create their own annotations and our Java code will become messy).

Oh yes, it will take lots of jumping from class to class, just to find out what the decl of a method is/means/does, and that's before getting into that code that's actually_part_ of the method.

But on the whole, I think it boils down to - If you don;t like them, just don't use them.

I actually think that static imports begin to lend Java towards things like mixin functionality that you see in languages like Ruby, but it still has a long way to go.

How sad that Java lacks mixins. Surely mixins can achieved using annotations and bytecode enhancement, but why so complicated in Java to do something so fundamental?!

I don't like "autoboxing" and "static import"... syntax sugar ...arghh...

Just curious, do you consider the normal import of packages undesirable as well? That is syntactic sugar too, right? How do you feel about concatenating of String's using the + sign?

best regards

/Jens

Have you seen IBM's comments in the voting ballot for these JSRs ?

IBM voted Yes with the following comment:
In voting for this JSR, IBM would like to reinforce the comments in the JSR that its purpose is to eliminate redundancy and ensure consistency. This implies that the role of this JSR is to review annotations created by other JSRs to ensure a consistent style and lack of duplication, and adopt those annotations where possible. It would not be appropriate for this JSR to define detailed annotation semantics, since these are properly the domain of subject matter experts in other JSRs.

Can I suggest to IBM to open source their software before asking the others to do it ? They tend to support open source when they have a possibility for a return (in cash or in developers working freely for them). I would understand such a comment if it was coming from many other companies, but on their systems IBM is still probably the most closed company. Please, if you want Sun to do it, show us the example first. And until you have done it on your side, please stop this behavior to the Java community : nobody except Microsoft can win from this.

Sorry, wrong quote in previous message. Read this one instead :

IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.

i guess IBM did open the door for the discussion of open source java once again.

_can_ ibm open source their jdk/jre? and call it a jdk/jre? my understanding is that the test suites (tdk?) one must pass to be called a "jdk/jre" vendor don't allow that. i wouldn't call on anyone specifically to open source their jdk/jre stuff, but to "open source" the process one must go through to become an official jdk/jre. look at what the geronimo folks are going through just to get certified as a j2ee provider. closed and buggy test suites that you've got to license? why does that make sense. make the testing/certification process open and available and _someone_ will donate a source base (blue would be caught with their foot in their mouth if they didn't pony up).

good day.

"Can I suggest to IBM to open source their software before asking the others to do it ?"

You mean other than, Jikes, WSDP, alphaworks, and many developerworks projects? So they're not going to open source DB2, big deal. They definitely contribute to Java, Linux and open source. Their contributions may not be entirely selfless, but as a company they are a very large supporter of Java.

Read the alphaWorks comercial license, its far from opensource. But I agree to all your other items.

You mean other than, Jikes, WSDP, alphaworks, and many developerworks projects?

Yes. Of course they contribute and they are a supporter of Java (against Microsoft), but they're still very shy in the open source market. Java is a major advantage for Sun when selling their hardware. They've created it and now IBM wants to get an hand on it by trying to create a discord between Sun and the others supporters of Java. That's definitely not fair.

Yes. Of course they contribute and they are a supporter of Java (against Microsoft), but they're still very shy in the open source market. Java is a major advantage for Sun when selling their hardware. They've created it and now IBM wants to get an hand on it by trying to create a discord between Sun and the others supporters of Java. That's definitely not fair.

There's also Eclipse. That's about as open as Netbeans and has a huge developer following. As far as hardware goes, Java does good things for IBM's mainframe sales. Now any Java developer can write code for an AS400. There is also Websphere. Without J2EE providers like IBM, and BEA, Sun would wouldn't have anything to run on their enterprise hardware (nobody uses the Sun RI in production).

IBM is a very large supporter of Java, in fact I'd say that in the beginning Java gained a lot of acceptance because such a large company endorsed it (rather than just being something that Sun thought everyone should use). IBM depends on the success of Java and has no desire to hurt it. IBM might have their own ideas about IDEs, developer communities and UI Toolkits. However in each of these cases they've contributed to the Java brand (which I'm sure in their eyes is helpful to Sun). I don't see how this is unfair to Sun.

There's also Eclipse. That's about as open as Netbeans and has a huge developer following.

Yes. They've thrown money to the open-source community to develop for them something to replace their VisualAge for Java. Then they've used eclipse as basis for WSAD. It was a really clever investment.

Without J2EE providers like IBM, and BEA, Sun would wouldn't have anything to run on their enterprise hardware (nobody uses the Sun RI in production).

It's true that most companies using BEA are running it on Solaris. But I'm not convinced it's the same about Websphere.

IBM depends on the success of Java and has no desire to hurt it.

I haven't said they do it intentionally. I can understand their position, but I disagree with the way they try to brand it to the other companies.

http://www.thauvin.net/blog/index.jsp

See the web start error?
.V

(ps: and the other list of issue no addressed
http://www.dynamicobjects.com/d2r/archives/002859.html
)