The Artima Developer Community
Sponsored Link

Weblogs Forum
JavaOne 2010: Upcoming Java Features

47 replies on 4 pages. Most recent reply: Oct 30, 2010 11:19 AM by Morgan Conrad

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 47 replies on 4 pages [ « | 1 2 3 4 | » ]
Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 4, 2010 10:57 AM
Reply to this message Reply
Advertisement
> Pragmatically, I could care less, I'm just happy to have
> half as much typing.
>
:__)

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 4, 2010 11:23 AM
Reply to this message Reply
> Not to make a big deal of it, but, from a "purist" point
> of view, one could argue that the Java way is superior.
> Why? Because "they say" that you should code to the
> e interface
, not the implementation.

Languages with type inference even use it for things other than interfaces, generic containers, etc.

var x = 100;


Or, more Java-ish:

var x = Integer.valueOf(100);


Under Java's new "type inference", since Integer is not a Generic type, you still have to go through the trouble of saying:

Integer x = Integer.valueOf(100);


It's hard to call this a win: "We will give you one syntactical shortcut to handle one specific use case, and leave every other use case unresolved; additionally, we will introduce a syntax that will make it harder for us to eventually add a different syntax to resolve those other use cases."

Ian Robertson

Posts: 68
Nickname: ianr
Registered: Apr, 2007

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 4, 2010 12:00 PM
Reply to this message Reply
> Under Java's new "type inference", since Integer is not a
> Generic type, you still have to go through the trouble of
> saying:
>
> Integer x = Integer.valueOf(100);

Or just:

Integer x = 100;

The compiler will silently translate that to Integer.valueOf(100).

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 4, 2010 12:56 PM
Reply to this message Reply
@Max

var x = 100;

I can live with this, but the algorithms guy in me immediately wants to know if x is an int or a double.

more realistically, (sadly)

var x = getFooBeanStrategy().getFooBeanFactory().getFooProxy().getValue();

here, I think a pragmatic programmer would say "screw all those good programmers using Scala" and want to know what the heck x is. :-)

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 4, 2010 4:39 PM
Reply to this message Reply
> the algorithms guy in me immediately wants to know if x is an int or a double.

That was my initial aversion to type inference as well. However, it's a solvable problem: just as there are rules about what type integer literals are (eg., if it's too large to fit in an int, it's a long) there can be rules that guarantee that x is an Integer because the literal 100 is an Integer (and that var y = 7.0 is a Float for similar reasons).

> I think a pragmatic programmer would ... want to know what the heck x is

That's funny, because pragmatism is precisely what sold me on type inference. Specifically in C++, given std::vector<std::string> foo, if I want the begin iterator for foo (and I want that iterator because I know what I can do with iterators), should I need to write std::vector<std::string>::iterator itor = foo.begin(); or auto itor = foo.begin();? Note, this works because I know that foo.begin() returns. In your example, you presumably don't know what getValue() returns and you don't have Intellisense available.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 5, 2010 12:52 AM
Reply to this message Reply
>
> (and
> that var y = 7.0 is a Float for
> similar reasons).

More likely to be a Double. Does this indicate a simple oversight, or a more serious flaw in infering types.

Mark Thornton

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 5, 2010 3:00 AM
Reply to this message Reply
> @Max
>
> var x = 100;
>
> I can live with this, but the algorithms guy in me
> immediately wants to know if x is an int or a double.
>
> more realistically, (sadly)
>
> var x =
> getFooBeanStrategy().getFooBeanFactory().getFooProxy().getV
> alue();
>
> here, I think a pragmatic programmer would say "screw all
> those good programmers using Scala" and want to know what
> the heck x is. :-)

If you want to know what getValue() returns, just hover your mouse over the function call. The IDE will show it to you.

The times you need to know what a variable's type is are much less than the times that you don't need to know.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 5, 2010 8:12 AM
Reply to this message Reply
> More likely to be a Double. Does this indicate a simple oversight, or a more serious flaw in inferring types.

Regardless, the problem is solvable by setting a rule. About what the literal 7.0 is. And, in fact, those rules already exist for constants.

Jonathan Finn

Posts: 10
Nickname: lucretius
Registered: Jun, 2006

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 5, 2010 9:48 AM
Reply to this message Reply
The burning question for me is: does anyone know why Java 7 won't allow type inference like Scala's the likes of:

var x = "some ";
x = x + " text";
final y = x; // using final like Scala's val

Presumably you'd have to declare types of method parameters, fields, and a few other cases. I have no problem with type inference like this as long as the language is statically typed: after all, you can specify types wherever you think there's a lack of clarity, and your IDE could also remind you the type if you get lost.

Is there a technical problem with this, or is it considered an anti-feature?

IMHO this would really help Java 'catch up' with one aspect of (say) Scala, and give it a new lease of life. If Scala can have it, why not Java?

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 5, 2010 9:55 AM
Reply to this message Reply
> The burning question for me is: does anyone know why Java
> 7 won't allow type inference like Scala's the likes
> of:
>
> var x = "some ";
> x = x + " text";
> final y = x; // using final like Scala's val
>


As already noted it conflicts with the program to the interface style and requires an extra keyword(var). Evidently program to the interface exponents have the upper hand where it matters for jdk7.

Jonathan Finn

Posts: 10
Nickname: lucretius
Registered: Jun, 2006

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 5, 2010 10:15 AM
Reply to this message Reply
> As already noted it conflicts with the program to the interface style and requires an extra keyword(var). Evidently program to the interface exponents have the upper hand where it matters for jdk7.

All I can say is: I hope 'program to the interface' wasn't the real reason. The interface is explicit in some cases (the types of methods and fields) and 'obvious' in others (where the type can be inferred from these). The programmer can choose to make types even more obvious where he/she wishes.

Again I hope avoiding a new keyword wasn't another reason: there are certainly ways round that. That was the reasoning that gave us horrors like the keyword overloading in '? extends X' and '? super X'.

I can only wish that any objection was a more serious one (lack of time for this Java version, or a technical/logical problem).

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 5, 2010 10:43 AM
Reply to this message Reply
> All I can say is: I hope 'program to the interface' wasn't the real reason.

Looking at the proposal ( http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000009.html ):

> An argument can also be made for more full type inference:

auto map = new HashMap<String, String>();
map.get("Foo"); // map is understood to be a Map<String, String>


> or, alternatively, for a typedef like feature, where type
> identiļ¬ers are assigned to longer typenames:

typedef MyMap HashMap<String, List<String>>;
MyMap m = new MyMap();


> Both of these approaches, which are present in the
> forthcoming C++ standard, would eliminate a lot of
> verbosity, at the expense of (potentially) obscuring the
> type of the variable. Neither of these proposals are
> precluded by this proposal; one, both or neither can be
> done at a later date.

Note, (1) C++0x is not the only language with this "other" kind of type inference, it's in C# and any number of functional languages; (2) implementing both the Java-style type inference and the more common type inference will lead to the need to explain to beginning programmers that var x = new ArrayList<>(); is an abomination because the compiler doesn't have enough information to determine what type of elements can go in x.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 5, 2010 10:55 AM
Reply to this message Reply
>If you want to know what getValue() returns, just hover your mouse
>over the function call. The IDE will show it to you.

Do any IDEs have a quick control-something command to TYPE that information into the source code?

That seems like a great idea that would make a bunch of us happy.

In other words, I type

x = someCall();

hover over "someCall", see that it returns an ExtremelyLongToTypeFoo, hit the magic command and the IDE adds it to the start of the line

ExtremelyLongToTypeFoo x = someCall();


I think the error checking/correcting stuff does something close but not as conveniently.

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 5, 2010 11:14 AM
Reply to this message Reply
> >If you want to know what getValue() returns, just hover
> your mouse
> >over the function call. The IDE will show it to you.
>
> Do any IDEs have a quick control-something command to TYPE
> that information into the source code?
>
> That seems like a great idea that would make a bunch of us
> happy.
>
> In other words, I type
>
> x = someCall();
>
> hover over "someCall", see that it returns an
> ExtremelyLongToTypeFoo, hit the magic command and the IDE
> adds it to the start of the line
>
> ExtremelyLongToTypeFoo x = someCall();
>
>
> I think the error checking/correcting stuff does something
> close but not as conveniently.

There might be a experimental feature in the Scala Eclipse plugin that does something similar to that.

http://www.scala-ide.org/2010/08/google-summer-of-code-2010/

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: JavaOne 2010: Upcoming Java Features Posted: Oct 5, 2010 11:17 AM
Reply to this message Reply
> >If you want to know what getValue() returns, just hover
> your mouse
> >over the function call. The IDE will show it to you.
>
> Do any IDEs have a quick control-something command to TYPE
> that information into the source code?
>
> That seems like a great idea that would make a bunch of us
> happy.
>
> In other words, I type
>
> x = someCall();
>
> hover over "someCall", see that it returns an
> ExtremelyLongToTypeFoo, hit the magic command and the IDE
> adds it to the start of the line
>
> ExtremelyLongToTypeFoo x = someCall();
>
>
> I think the error checking/correcting stuff does something
> close but not as conveniently.

Or better yet, be able to toggle type annotations for whatever selection of code.

Flat View: This topic has 47 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: Practical Scala/Java interoperability by small examples Previous Topic   Next Topic Topic: Why To Go Into Bioinformatics

Sponsored Links



Google
  Web Artima.com   

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