Matt Raible went to the Denver JUG meeting with Neal Gafter, and Joshua Bloch. They discussed the new features of Java 5, and Matt details the features, and when to use them.

Read JDK 1.5 from Joshua and Neal

???????
because "in" is already a keyword (for example, System.in) and they didn't want to introduce a new keyword. Only new keyword in JDK 5 is enum.
???????

in is a KEYWORD ??? :( :-/

Don't shoot the messenger. ;-)

Thanks for the article ! It is very helpful ! Great job on capturing so many stuff in a half-hour meeting..

reverse it. if "in" is a keyword, "System.in" will be in trouble.

reverse it. if "in" is a keyword, "System.in" will be in trouble.

I don't have a computer science background, so pardon my ignorance, but I have often wondered about this restriction. Is it really hard/impossible to design the compiler to distinguish between an "in" used in a for loop construct and one used as a variable? Doesn't the context tell enough for the compiler to distinguish? I think (don't shoot me if I'm wrong) that if you happened to use "assert" in your code prior to JDK 1.4, then the JDK 1.4 compiler would warn you, but would not barf.

Or is there a blanket requirement in the JLS that a keyword is not usable ANYWHERE else?

Nope. Pretty sure 'in's just a static member variable in the System class.

Unless I am mistaken, the new static import feature would allow "System.in" to be referenced as just "in".

System.in is a class member of type InputStream.

a keyword can also be surrounded by other characters such as '(', EOL, TAB etc... but not '.'

A keyword is only a keyword if the Java Language Specification defines it as such.
'in' can't be a keyword if you want to use it as an identifier; an identifier can never be a keyword. Currently 'in' is not a keyword.

There don't have to be spaces around a keyword:

System.out.println(Object.class);

'class' is a keyword.

- Erwin

No. "in" is not a keyword (and never was). The reason why they didn't use "in" was that a lot developers used "in" as a variable (e. g. for input streams), and introducing a new keyword that would conflict with legacy code didn't seem so intelligent... so they used the less readable but safe ":". But maybe they sometimes confuse the keywords of the languages they get their "inspirations" from with Java ;-)

No. "in" is not a keyword (and never was). The reason why they didn't use "in" was that a lot developers used "in" as a variable (e. g. for input streams), and introducing a new keyword that would conflict with legacy code ...

But a variable isn't allowed in that context anyway, is it? As I understand it, the syntax is basically this:

for (<TypeName> <VariableName> : <Expression>)

I don't quite see why it shouldn't be

for (<TypeName> <VariableName> in <Expression>)

The worst thing that could happen is a slightly confusing but nontheless valid statement like this:

for (InputStream in in myStreamCollection)

So what? No ambiguity there. Or am I missing something? I believe that the real problem not ambiguity. I think they have certain principles for keeping the compiler simple (and fast) and one of those principles is to never allow user defined names to be the same as keywords, even in places where there wouldn't be a problem of ambiguity.

Personnaly I don't see the issue with:
> for (<TypeName> <VariableName> : <Expression>)
It's not as if Java has a BASIC or COBOL syntax.

Java already has the non-intuitive:
     for (<TypeName> <VariableName> = <EXPR>; <COND>; <EXPR>)
looping construct.

And Smalltalk (the grandaddy of all OO languages) has an even less intuitive syntax:
     Expression do: [ :VariableName | statements ]

All these syntaxes may be unintuitive, but they're easy to learn because they each represent a simple semantic idea.

There might be no ambiguity for in, but you can not guaranty that for other keywords. The consistency of rules for every keyword to follow will keep compiler easy to write/maintain/less buggy. I am sure you can write your mini-lang compiler to do that, but think about the size of Java.

No. "in" is not a keyword (and never was). The reason why they didn't use "in" was that a lot developers used "in" as a variable (e. g. for input streams), and introducing a new keyword that would conflict with legacy code ...

But a variable isn't allowed in that context anyway, is it? As I understand it, the syntax is basically this:for (<TypeName> <VariableName> : <Expression>)I don't quite see why it shouldn't befor (<TypeName> <VariableName> in <Expression>)The worst thing that could happen is a slightly confusing but nontheless valid statement like this:for (InputStream in in myStreamCollection)So what? No ambiguity there. Or am I missing something? I believe that the real problem not ambiguity. I think they have certain principles for keeping the compiler simple (and fast) and one of those principles is to never allow user defined names to be the same as keywords, even in places where there wouldn't be a problem of ambiguity.

I guess you should be able to change
MyBean myBean = (MyBean)applicationContext.getBean("myBeanName");
to
MyBean myBean = applicationContext.getBean<MyBean>("myBeanName");

This would eliminate the cast in the code, but you cannot guarantee that the bean named "myBeanName" implements MyBean, so you'd probably throw an ClassCastException inside the getBean method, instead of in the calling method...

You even could make this work:
MyBean myBean = applicationContext.getBean<MyBean>();
if you had a default mapping scheme for className to beanName, but this would reduce flexibility, no?

I guess you should be able to changeMyBean myBean = (MyBean)applicationContext.getBean("myBeanName");toMyBean myBean = applicationContext.getBean<MyBean>("myBeanName");This would eliminate the cast...

IMO: absolutely the same typing and behavior if "myBeanName" is not a MyBean, I see no gains.

Take Pico IoC as an example MyBean myBean = (MyBean) picoContext.get( MyBean.class ); , that returns whatever have been configured as implementer of MyBean or subclass of MyBean, and it is virtually guaranteed that returned object is some sort of MyBean..

I guess you should be able to changeMyBean myBean = (MyBean)applicationContext.getBean("myBeanName");toMyBean myBean = applicationContext.getBean<MyBean>("myBeanName");This would eliminate the cast...

IMO: absolutely the same typing and behavior if "myBeanName" is not a MyBean, I see no gains.Take Pico IoC as an example MyBean myBean = (MyBean) picoContext.get( MyBean.class ); , that returns whatever have been configured as implementer of MyBean or subclass of MyBean, and it is virtually guaranteed that returned object is some sort of MyBean..

I agree--there's not much gain and I don't see this causing a problem in practice. Btw Spring provides an overloaded getBean() method taking a Class argument as well as name.

JDK 5 also simplifies reflection. Class Class has been generified - Class literal Foo.class is of type Class<Foo>. This enables compile-time type-safe reflection w/o casting. The following used to return an Object and required casting.

Foo foo = Foo.class.newInstance();

This enables strongly typed static factories. I wonder if this can be used with Spring so you don't have to cast a bean when grabbing it from the ApplicationContext?


Is this supposed to be supported by the Servlet Container first, then in our JSP/Servlet application, we can apply this feature ( Grab the bean from either Context without casting)?

As far I understood java 1.5's generic mechanism you cannot use
type parameter in a static context.
E.g. this will NOT work
public class <T> GenericFactory {
  public static T create() { return Class<T>.newInstance(); }
}

Looks like DJUG moved their presentations when they redesigned their site last week. Here's the updated links:

Programming Puzzles and Taming the Tiger

Read the section "Comparing C# and Java Generics" on the Artima Developer site. An interview with Anders Hejlsberg (author of well known Turbo Pascal and C#) illustrates the differences between Java and C# generics and also shows why Java can't take it any longer than it did.

What's the current status about the "Autoboxing surprise" ? (https://www.theserverside.com/news/thread.tss?thread_id=27129)
To me, if a cool functionality introduces such strange behaviors, it should simply be removed from the language.

What's the current status about the "Autoboxing surprise" ? (https://www.theserverside.com/news/thread.tss?thread_id=27129)To me, if a cool functionality introduces such strange behaviors, it should simply be removed from the language.

Autoboxing is still in. Read Gilad Bracha reply to the problems with autoboxing in this thread: http://www.javalobby.com/thread.jspa?messageID=91803558&threadID=13257&forumID=61

Personally, I think autoboxing and static imports are two features the Java language could have done without. They will cause a lot of confusion.

A useful feature in IDE code parsers (like the ones in Eclipse and IDEA) would be to be able to turn on a usage warning for each new language feature in Java 1.5. That way you could for example get warnings each time autoboxing or static imports are used in your project.

Doh. IDEA already supports issuing warnings or errors when individual Java 1.5 features are used. This IDE never stops to amaze me. :-)

is this:
http://java.sun.com/features/2003/05/bloch_qa.html

Good article from Josh and Neal :-)

Yes a very good article from Joshua and Neal and well presented by Matt (with his short comments). Interesting part is the static imports. Not sure how far it complies to the Inheritence principle