Interesting list of features planned for Eclipse 3.0

Are jsr 201, 175 and 199 really targeted for 1.5? A quick look at jsr 176 (the jsr for 1.5) doesn't mention that they will be... They do look like interesting proposals though!

They're (currently) targeted for 1.5.

See
http://www.jcp.org/en/jsr/detail?id=201
http://www.jcp.org/en/jsr/detail?id=175
http://www.jcp.org/en/jsr/detail?id=199

Are jsr 201, 175 and 199 really targeted for 1.5? A
quick look at jsr 176 (the jsr for 1.5) doesn't
mention that they will be... They do look like
interesting proposals though!

Well actually 175 has been updated and the 1.5 mention has been removed. As for 201 and 199, while 1.5 is mentioned why doesn't 176 mention them?
Confusing if you ask me. I wanted to see what was coming up in 1.5 and look at 176. It doesn't seem really intuitive nor easy to have to look at other jsr to see what might be included.
Oh well.

Best,
Chris

Regarding 175. It was "TBD", now it's "It is intended that this JSR will be delivered as part of the J2SETM "Tiger" release." ( http://www.jcp.org/en/jsr/detail?id=175#updates ).

I agree that it will be better if they list all JSRs they want to include in JSR-176, though they warn that "The final specification for Tiger may not include all of these JSRs, and may include some JSRs not present on this list."

I see, I got confused: didn't read the update well enough, I got it reversed. ^_;

An article about J2SE 1.5, JSRs-14, 201, 175 (the 1.5 beta is scheduled for late 2003).
"New Language Features for Ease of Development in the Java 2 Platform, Standard Edition 1.5: A Conversation with Joshua Bloch"
http://java.sun.com/features/2003/05/bloch_qa.html

that's a great article, and i'm really looking forward to those features.

Ian Zabel wrote:

that's a great article, and i'm really looking forward to those features.

a great article ?
To me some of the features look like they will encourage bad sw
engineering practices, as if Sun wants java to appeal more and more to
less-experiences, non--strong-OO developers.


Instead of merely saying: List words = new ArrayList(); You'll have to say: List words = new ArrayList(); The upside is that if you try to insert something that's not a string, you find out at compile time and fix the problem. Without generics, you discover such a bug when your most important customer calls your VP to tell him that the program on which his business depends just crashed with a ClassCastException. I sometimes would like to use generics, too, but this generics propaganda seem to suggest that type safety makes your code better. To me that it's bull****. TDD makes my code better, not static typing (although I like it overall). See http://www.artima.com/forums/flat.jsp?forum=106&thread=4639 enum declaration: enum Season { winter, spring, summer, fall } But it doesn't act like a C/C++ enum! You get all of the cool features that I just mentioned. And it even fixes the major shortcoming of the Typesafe Enum pattern: you can use the new language feature in conjunction with switch statements. This may appeal to people who thrive in the sins of PrimitiveObsession and InappropriateIntimacy (hint: Refactoring book), they love switches on basic types rather than growing those types into smart ones. Of course, I too use enum sometimes - but I've never being happy of switching. What will the new static import facility offer developers? It lets the programmer avoid prefixing static members with class names. People really want this, ]]>

To me, it doesn't buy anything. I don't dislike constants to be prefixed
- they may end up grouped more nicely.


just my 2c.
Edo