The Artima Developer Community
Sponsored Link

Java Community News
JavaOne, Day 3: Java Puzzlers

7 replies on 1 page. Most recent reply: Jun 25, 2007 1:13 PM by Raoul Duke

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 7 replies on 1 page
Admin Admin

Posts: 39
Nickname: admin
Registered: Jan, 2002

JavaOne, Day 3: Java Puzzlers Posted: May 11, 2007 12:49 AM
Reply to this message Reply
Summary
John Mitchell blogged about Josh Bloch and Neal Gafter's annual Java Puzzlers session at JavaOne (this year, Bill Pugh stood in for Neal Gafter). Mitchell points out how some of the puzzles show that adding new features to Java can on occasion confuse developers.
Advertisement

John Mitchell points out in his blog, penned after attending the Java Puzzlers session at JavaOne, that:

The moral of these puzzles isn't merely "be careful of using wrapper types with the ternary operator", but that auto-boxing is evil and should have never been added to the language in the first place.

Of course, it goes without saying that this is just one example of how new "features" added to a mature language are very dangerous. One of the big, currently brewing brouhahas is over the proposed addition of closures to Java. Perhaps folks might want to pause their rampant fervor for a bit and actually look at the history of these attempts and realize just how costly these changes really are. Especially when there are plenty of alternatives like using other languages which have their pet features which target the underlying JVM.

As Josh so eloquently put, "APIs, like diamonds, are forever."

What newly proposed Java feature do you think could confuse developers the most?


James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: JavaOne, Day 3: Java Puzzlers Posted: May 11, 2007 7:16 AM
Reply to this message Reply
Autoboxing was a really bad idea. The worst thing about it is that to understand what's going wrong you basically have to know how Java worked without autoboxing. This is not a good thing for developers learning Java in 1.5.

Generics is confusing. Not at first but once you start dealing with raw types and wildcards, variance, inference, and method signature implications it becomes pretty hairy. Get some arrays involved for a real party. I think they do have benefits but you need a pretty strong Java developer around to keep a team out of trouble.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: JavaOne, Day 3: Java Puzzlers Posted: May 11, 2007 3:13 PM
Reply to this message Reply
> Generics is confusing. Not at first but once you start
> dealing with raw types and wildcards, variance, inference,
> and method signature implications it becomes pretty hairy.
> Get some arrays involved for a real party. I think they
> y do have benefits but you need a pretty strong Java
> developer around to keep a team out of trouble.

I agree that generics is confusing. As many others have noted, it is more confusing than it could have been if keeping the JVM static wasn't such a high priority to Sun.

We can all debate the wisdom of that approach, but if Sun really believes that JVM compatibility is key, they should recognize the consequences: the value of many new Java features will be compromised.

Kannan Goundan

Posts: 18
Nickname: cakoose
Registered: Nov, 2005

Re: JavaOne, Day 3: Java Puzzlers Posted: May 11, 2007 6:15 PM
Reply to this message Reply
Yeah, autoboxing in Java isn't ideal (though, for me, they're a net benefit). However, when I hear "autoboxing is evil", I worry that maybe people are making a generalization about the language-neutral concept of autoboxing based on their experience with Java-specific autoboxing problems

The root cause of the NPE-related weirdness is that Java doesn't distinguish between pointers and "pointers that can be null". The fact that those two logically distinct types aren't distinguished by the type system is the real problem. Essentially, Java code is filled with implicit unsafe casts between those two types. Every NullPointerException is really a ClassCastException.

That is evil. All autoboxing did is make it more apparent.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: JavaOne, Day 3: Java Puzzlers Posted: May 11, 2007 7:47 PM
Reply to this message Reply
I am intrigued. Why did Neil Gafter need a stand in? Did this talk clash with another presentation?

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: JavaOne, Day 3: Java Puzzlers Posted: May 17, 2007 3:40 PM
Reply to this message Reply
> The root cause of the NPE-related weirdness is that Java
> doesn't distinguish between pointers and "pointers that
> can be null".

Are there languages which do have such distinctions? Is it those which support "nullable"-ness e.g. Nice?

Kannan Goundan

Posts: 18
Nickname: cakoose
Registered: Nov, 2005

Re: JavaOne, Day 3: Java Puzzlers Posted: May 17, 2007 10:14 PM
Reply to this message Reply
> Are there languages which do have such distinctions? Is it
> those which support "nullable"-ness e.g. Nice?

Yes, Nice has two different types for "pointer" (ex: String) and "pointer that might be null" (ex: ?String). But since Nice is constrained by the JVM and by the desire to mix easily with Java, the "?" modifier isn't totally generic. For example, you can't say "??String" and there's an explicit modifier ("!") to indicate that a type parameter can't be null.

Haskell and ML are cleaner in that they don't even have the concept of the "null" special case. They support optionality with a parameterized algebraic data type. For example, any Haskell type can be wrapped by the "Maybe" type; so the type "Integer" refers to an integer while "Maybe(Integer)" can either be an integer or be the singelton value "Nothing".

A roughly-equivalent implementation in Java might look like:

abstract class Maybe<T> {}
 
class Nothing<T> extends Maybe<T> {}
 
class Just<T> extends Maybe<T> {
   final T value;
   Just(T value) { this.value = value; }
}
 
String s = "hi";
Maybe<String> ms = new Just<String>("hi");
 
String greet(Maybe<String> name) {
   if (name instanceof Just) {
      return "Hello, " + ((Just)name).value;
   } else {
      return "Hello, Anonymous";
   }
}


(This would be much less verbose in Haskell.)

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: JavaOne, Day 3: Java Puzzlers Posted: Jun 25, 2007 1:13 PM
Reply to this message Reply
> (This would be much less verbose in Haskell.)

seems like that - verbatim, with nothing else - would make a good t-shirt to sell at FP conferences.

Flat View: This topic has 7 replies on 1 page
Topic: Joshua Marinacci on Generating PDF from XHTML Previous Topic   Next Topic Topic: Gavin King: In Defence of the RDBMS

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use