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
-
JDK 1.5 from Joshua Bloch and Neal Gafter (27 messages)
- Posted by: Nate Borg
- Posted on: August 26 2004 15:24 EDT
Threaded Messages (27)
- "in" is a keyword??? by Anki Nelaturu on August 26 2004 18:58 EDT
- "in" is a keyword??? by Matt Raible on August 26 2004 19:17 EDT
- "in" is a keyword??? by rachel wu on August 26 2004 07:59 EDT
- "in" is a keyword??? by Michael Li on August 26 2004 19:35 EDT
- "in" is a keyword??? by Sumit K on August 28 2004 12:22 EDT
- "in" is a keyword??? by Gordon Krefting on August 26 2004 19:41 EDT
- "in" is a keyword??? by Ghanshyam Patel on August 26 2004 07:50 EDT
- a keyword is surrounded by spaces, and in as in System.in is NOT by Jerome Lacoste on August 27 2004 02:42 EDT
-
To be correct by Jerome Lacoste on August 27 2004 02:46 EDT
- A keyword is only a keyword if it is defined as such in the JLS by Erwin Bolwidt on August 27 2004 04:31 EDT
-
To be correct by Jerome Lacoste on August 27 2004 02:46 EDT
- "in" is a keyword??? by Michael Mayr on August 27 2004 09:19 EDT
-
Where's the conflict? by Alexander Jerusalem on August 27 2004 04:15 EDT
- Where's the conflict? by Robert Devi on August 28 2004 09:24 EDT
- Where's the conflict? by Michael Li on August 30 2004 04:58 EDT
-
Where's the conflict? by Alexander Jerusalem on August 27 2004 04:15 EDT
- Strongly Typed static factories for ApplicationContext? by Geert Pante on August 27 2004 10:59 EDT
-
Strongly Typed static factories for ApplicationContext? by Konstantin Ignatyev on August 27 2004 11:11 EDT
- Strongly Typed static factories for ApplicationContext? by Rod Johnson on September 03 2004 07:02 EDT
-
Strongly Typed static factories for ApplicationContext? by Konstantin Ignatyev on August 27 2004 11:11 EDT
- "in" is a keyword??? by Matt Raible on August 26 2004 19:17 EDT
- JDK 1.5 from Joshua Bloch and Neal Gafter by rachel wu on August 26 2004 19:32 EDT
- "This enables strongly typed static factories". Really ? by Burkhard Neppert on August 30 2004 10:46 EDT
- DJUG moved Presentations by Matt Raible on August 26 2004 21:01 EDT
- New features all right, but what about PIZZA? by Dag H. Baardsen on August 27 2004 03:29 EDT
- Autoboxing surprises by Jean-Pol Landrain on August 27 2004 04:58 EDT
- Autoboxing and static imports by Jesper Nordenberg on August 27 2004 05:34 EDT
-
A note to IDE developers by Jesper Nordenberg on August 27 2004 05:41 EDT
- A note to IDE developers by Jesper Nordenberg on August 27 2004 02:57 EDT
-
A note to IDE developers by Jesper Nordenberg on August 27 2004 05:41 EDT
- Autoboxing and static imports by Jesper Nordenberg on August 27 2004 05:34 EDT
- Link to all new Features in JDK 1.5 by prashant pachouri on September 01 2004 01:46 EDT
- JDK 1.5 from Joshua Bloch and Neal Gafter by mahesh d on October 13 2004 09:24 EDT
-
"in" is a keyword???[ Go to top ]
- Posted by: Anki Nelaturu
- Posted on: August 26 2004 18:58 EDT
- in response to Nate Borg
???????
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 ??? :( :-/ -
"in" is a keyword???[ Go to top ]
- Posted by: Matt Raible
- Posted on: August 26 2004 19:17 EDT
- in response to Anki Nelaturu
Don't shoot the messenger. ;-) -
"in" is a keyword???[ Go to top ]
- Posted by: rachel wu
- Posted on: August 26 2004 19:59 EDT
- in response to Matt Raible
Thanks for the article ! It is very helpful ! Great job on capturing so many stuff in a half-hour meeting.. -
"in" is a keyword???[ Go to top ]
- Posted by: Michael Li
- Posted on: August 26 2004 19:35 EDT
- in response to Anki Nelaturu
reverse it. if "in" is a keyword, "System.in" will be in trouble. -
"in" is a keyword???[ Go to top ]
- Posted by: Sumit K
- Posted on: August 28 2004 12:22 EDT
- in response to Michael Li
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? -
"in" is a keyword???[ Go to top ]
- Posted by: Gordon Krefting
- Posted on: August 26 2004 19:41 EDT
- in response to Anki Nelaturu
Nope. Pretty sure 'in's just a static member variable in the System class. -
"in" is a keyword???[ Go to top ]
- Posted by: Ghanshyam Patel
- Posted on: August 26 2004 19:50 EDT
- in response to Gordon Krefting
Unless I am mistaken, the new static import feature would allow "System.in" to be referenced as just "in". -
a keyword is surrounded by spaces, and in as in System.in is NOT[ Go to top ]
- Posted by: Jerome Lacoste
- Posted on: August 27 2004 02:42 EDT
- in response to Anki Nelaturu
System.in is a class member of type InputStream. -
To be correct[ Go to top ]
- Posted by: Jerome Lacoste
- Posted on: August 27 2004 02:46 EDT
- in response to Jerome Lacoste
a keyword can also be surrounded by other characters such as '(', EOL, TAB etc... but not '.' -
A keyword is only a keyword if it is defined as such in the JLS[ Go to top ]
- Posted by: Erwin Bolwidt
- Posted on: August 27 2004 04:31 EDT
- in response to Jerome Lacoste
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 -
"in" is a keyword???[ Go to top ]
- Posted by: Michael Mayr
- Posted on: August 27 2004 09:19 EDT
- in response to Anki Nelaturu
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 ;-) -
Where's the conflict?[ Go to top ]
- Posted by: Alexander Jerusalem
- Posted on: August 27 2004 16:15 EDT
- in response to Michael Mayr
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. -
Where's the conflict?[ Go to top ]
- Posted by: Robert Devi
- Posted on: August 28 2004 09:24 EDT
- in response to Alexander Jerusalem
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. -
Where's the conflict?[ Go to top ]
- Posted by: Michael Li
- Posted on: August 30 2004 16:58 EDT
- in response to Alexander Jerusalem
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. -
Strongly Typed static factories for ApplicationContext?[ Go to top ]
- Posted by: Geert Pante
- Posted on: August 27 2004 10:59 EDT
- in response to Anki Nelaturu
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? -
Strongly Typed static factories for ApplicationContext?[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: August 27 2004 11:11 EDT
- in response to Geert Pante
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.. -
Strongly Typed static factories for ApplicationContext?[ Go to top ]
- Posted by: Rod Johnson
- Posted on: September 03 2004 07:02 EDT
- in response to Konstantin Ignatyev
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.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.. -
JDK 1.5 from Joshua Bloch and Neal Gafter[ Go to top ]
- Posted by: rachel wu
- Posted on: August 26 2004 19:32 EDT
- in response to Nate Borg
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)? -
"This enables strongly typed static factories". Really ?[ Go to top ]
- Posted by: Burkhard Neppert
- Posted on: August 30 2004 10:46 EDT
- in response to rachel wu
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(); }
} -
DJUG moved Presentations[ Go to top ]
- Posted by: Matt Raible
- Posted on: August 26 2004 21:01 EDT
- in response to Nate Borg
Looks like DJUG moved their presentations when they redesigned their site last week. Here's the updated links:
Programming Puzzles and Taming the Tiger -
New features all right, but what about PIZZA?[ Go to top ]
- Posted by: Dag H. Baardsen
- Posted on: August 27 2004 03:29 EDT
- in response to Nate Borg
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. -
Autoboxing surprises[ Go to top ]
- Posted by: Jean-Pol Landrain
- Posted on: August 27 2004 04:58 EDT
- in response to Nate Borg
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 and static imports[ Go to top ]
- Posted by: Jesper Nordenberg
- Posted on: August 27 2004 05:34 EDT
- in response to Jean-Pol Landrain
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 note to IDE developers[ Go to top ]
- Posted by: Jesper Nordenberg
- Posted on: August 27 2004 05:41 EDT
- in response to Jesper Nordenberg
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. -
A note to IDE developers[ Go to top ]
- Posted by: Jesper Nordenberg
- Posted on: August 27 2004 14:57 EDT
- in response to Jesper Nordenberg
Doh. IDEA already supports issuing warnings or errors when individual Java 1.5 features are used. This IDE never stops to amaze me. :-) -
Link to all new Features in JDK 1.5[ Go to top ]
- Posted by: prashant pachouri
- Posted on: September 01 2004 01:46 EDT
- in response to Nate Borg
-
JDK 1.5 from Joshua Bloch and Neal Gafter[ Go to top ]
- Posted by: mahesh d
- Posted on: October 13 2004 09:24 EDT
- in response to Nate Borg
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