This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Closures make it into Java 7

14 replies
Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Sun has announced at Devoxx that closures will be in Java 7 (which has been pushed back to late 2010).

http://www.javac.info/closures-v06a.html

What does this mean for Scala-Java interop post-Java7?

--j

Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: Closures make it into Java 7
Some observations:

* It looks like function interfaces will be specialized based on return type and parameter types. I wonder how many interfaces they'll generate (@specialized Function22 is impractical), or if they'll be compiler- or VM-generated on an as-needed basis.

* Function type are effectively covariant in their return type and contravariant in their argument types, but this is done through existential type hackery, not true co-/contra-variance.

* "thrown types" are introduced to represent which exceptions a function can throw.

* "thrown types" have disjunction types.

* Java adds the Nothing type.

* It's illegal to break/continue out of a lambda, and return exits the closest lambda (not the closest true method, like in Scala). (That is, no non-local returns, hence no ControlFlowExceptions.)

* Captured non-final variables can be referenced in a lambda, but will emit a warning unless an annotation is added.

Some thoughts:

Since the addition of generics (thanks Martin!), this is the biggest change to Java's type system, and Scala's influence clearly shows through (congrats Martin!).

--j

On Wed, Nov 18, 2009 at 2:01 PM, Jorge Ortiz <jorge [dot] ortiz [at] gmail [dot] com> wrote:
Sun has announced at Devoxx that closures will be in Java 7 (which has been pushed back to late 2010).

http://www.javac.info/closures-v06a.html

What does this mean for Scala-Java interop post-Java7?

--j


ijuma
Joined: 2008-08-20,
User offline. Last seen 22 weeks 2 days ago.
Re: Closures make it into Java 7

Hi Jorge,

Jorge Ortiz gmail.com> writes:
> Some observations:

That spec seems quite similar to the one Neal had written previously with
changes to match the new syntax. For example, the Scala reference in the
changelog regarding Nothing existed in the BGGA version too.

Do you know if this is actually close to what they want to do or is a very early
proof of concept?

> * It looks like function interfaces will be specialized
> based on return type and parameter types. I wonder how many interfaces
> they'll generate ( specialized Function22 is impractical), or if
> they'll be compiler- or VM-generated on an as-needed basis.*

I think that part looks the same as BGGA. I tried the prototype in the past and
it generated the function types on the fly. I think this was temporary though
and it would probably be done by the VM, but I don't know.

Also, as I recall the prototype compiler did not do specialisation like the one
we expect from Scala. Basically primitives and objects were not unified (just
like everywhere else in Java) so if you used primitives in a function type, it
would not inherit from a base function with the same arity for Any/Object. I am
not sure if the spec has been changed regarding this, but it wasn't clear to me
how it was meant to work.

Best,
Ismael

Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: Re: Closures make it into Java 7
There are a couple of comments in that document saying stuff to the effect of "this is a placeholder for a more precise description" or "this deserves a more formal treatment", so if this is the direction they're taking, then it's probably an early/rough guideline, not a final spec.

As to whether or not this is the direction they're taking, I only know what Twitter tells me :)

--j

On Wed, Nov 18, 2009 at 2:45 PM, Ismael Juma <mlists [at] juma [dot] me [dot] uk> wrote:
Hi Jorge,

Jorge Ortiz <jorge.ortiz <at> gmail.com> writes:
> Some observations:

That spec seems quite similar to the one Neal had written previously with
changes to match the new syntax. For example, the Scala reference in the
changelog regarding Nothing existed in the BGGA version too.

Do you know if this is actually close to what they want to do or is a very early
proof of concept?

> * It looks like function interfaces will be specialized
> based on return type and parameter types. I wonder how many interfaces
> they'll generate ( <at> specialized Function22 is impractical), or if
> they'll be compiler- or VM-generated on an as-needed basis.*

I think that part looks the same as BGGA. I tried the prototype in the past and
it generated the function types on the fly. I think this was temporary though
and it would probably be done by the VM, but I don't know.

Also, as I recall the prototype compiler did not do specialisation like the one
we expect from Scala. Basically primitives and objects were not unified (just
like everywhere else in Java) so if you used primitives in a function type, it
would not inherit from a base function with the same arity for Any/Object. I am
not sure if the spec has been changed regarding this, but it wasn't clear to me
how it was meant to work.

Best,
Ismael


Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Re: Closures make it into Java 7

> I think that part looks the same as BGGA. I tried the prototype in the past and
> it generated the function types on the fly. I think this was temporary though
> and it would probably be done by the VM, but I don't know.

Yes, and yes.

> Also, as I recall the prototype compiler did not do specialisation like the one
> we expect from Scala. Basically primitives and objects were not unified (just
> like everywhere else in Java) so if you used primitives in a function type, it
> would not inherit from a base function with the same arity for Any/Object. I am
> not sure if the spec has been changed regarding this, but it wasn't clear to me
> how it was meant to work.

It did.

{int, int => int} would generate a class called FIII. {String, String
=> String} would generate FOOO and use it as FOOO. {int => String} - FIO. The names might be slightly
out but that's the idea.

ijuma
Joined: 2008-08-20,
User offline. Last seen 22 weeks 2 days ago.
Re: Closures make it into Java 7

Hey Ricky,

Ricky Clarkson gmail.com> writes:
> It did.

Not exactly sure what part of the paragraph this refers to. :)

> {int, int => int} would generate a class called FIII. {String, String
> => String} would generate FOOO and use it as FOOO String>. {int => String} - FIO. The names might be slightly
> out but that's the idea.

Right. That's more or less what I remembered. I wasn't clear on what I meant by
"it wasn't clear how it was meant to work", so let me clarify. I was wondering
how one would work with functions generically, e.g. would there be a way to say,
I can accept any Function with 3 parameters even if one of them is a primitive?
From the output of the prototype compiler, it seemed like the answer would be
no, but I didn't read the spec carefully enough to work out whether I was
missing something.

Best,
Ismael

Dave Griffith
Joined: 2009-01-14,
User offline. Last seen 42 years 45 weeks ago.
Re: Closures make it into Java 7

18 months ago I would have thought this news was quite important.

After writen Groovy and Scala in anger, and Clojure for fun, I have
absolutely no idea what sort of project I would possibly recommend Java 7
for. It's baffling.

Pretty scary, considering I helped instigate a Java 7 JSR back around 3.5
years ago. (JSR-305, if anyone cares. I honestly don't.)

--Dave

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Closures make it into Java 7

It is important, both for those who still use Java, and those who
still use the JVM. Having the VM generate function types is likely to
positively impact interaction between JVM languages.

As to projects I'd recommend Java 7 for.. that'd be projects written
in previous versions of Java.

2009/11/19 Dave Griffith :
>
>
> 18 months ago I would have thought this news was quite important.
>
> After writen Groovy and Scala in anger, and Clojure for fun, I have
> absolutely no idea what sort of project I would possibly recommend Java 7
> for.   It's baffling.
>
> Pretty scary, considering I helped instigate a Java 7 JSR back around 3.5
> years ago.  (JSR-305, if anyone cares.  I honestly don't.)
>
> --Dave
> --
> View this message in context: http://old.nabble.com/Closures-make-it-into-Java-7-tp26416600p26419142.html
> Sent from the Scala - Debate mailing list archive at Nabble.com.
>
>

marius
Joined: 2008-08-31,
User offline. Last seen 3 years 19 weeks ago.
Re: Re: Closures make it into Java 7
I really dislike the # presence for function types.

Br's,
Marius

On Thu, Nov 19, 2009 at 12:13 AM, Jorge Ortiz <jorge [dot] ortiz [at] gmail [dot] com> wrote:
Some observations:

* It looks like function interfaces will be specialized based on return type and parameter types. I wonder how many interfaces they'll generate (@specialized Function22 is impractical), or if they'll be compiler- or VM-generated on an as-needed basis.

* Function type are effectively covariant in their return type and contravariant in their argument types, but this is done through existential type hackery, not true co-/contra-variance.

* "thrown types" are introduced to represent which exceptions a function can throw.

* "thrown types" have disjunction types.

* Java adds the Nothing type.

* It's illegal to break/continue out of a lambda, and return exits the closest lambda (not the closest true method, like in Scala). (That is, no non-local returns, hence no ControlFlowExceptions.)

* Captured non-final variables can be referenced in a lambda, but will emit a warning unless an annotation is added.

Some thoughts:

Since the addition of generics (thanks Martin!), this is the biggest change to Java's type system, and Scala's influence clearly shows through (congrats Martin!).

--j

On Wed, Nov 18, 2009 at 2:01 PM, Jorge Ortiz <jorge [dot] ortiz [at] gmail [dot] com> wrote:
Sun has announced at Devoxx that closures will be in Java 7 (which has been pushed back to late 2010).

http://www.javac.info/closures-v06a.html

What does this mean for Scala-Java interop post-Java7?

--j



ijuma
Joined: 2008-08-20,
User offline. Last seen 22 weeks 2 days ago.
Re: Closures make it into Java 7

Ricky Clarkson gmail.com> writes:
> It is important, both for those who still use Java, and those who
> still use the JVM. Having the VM generate function types is likely to
> positively impact interaction between JVM languages.

Yeah. Java is a strong driver for the JVM even though it's not the only one (see
the invokedynamic work).

For the closures case, one can imagine that it would increase motivation for Sun
to improve inlining heuristics for methods that take closures (like foreach) so
that one can avoid the megamorphic call site. It may also consider approaches
that reduce the code bloat produced by the Scala approach (two options here are:
reduce duplication in the anonymous classes used for closures or use method
handles and make sure they perform as well).

Scala can certainly benefit from another statically typed language in the JVM
that tries to solve similar issues. Competition is good and in some cases,
changes in the JVM may automatically help Scala.

Best,
Ismael

Ben Hutchison 3
Joined: 2009-11-02,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Closures make it into Java 7

On Thu, Nov 19, 2009 at 7:53 PM, Ismael Juma wrote:
> Scala can certainly benefit from another statically typed language in the JVM
> that tries to solve similar issues. Competition is good and in some cases,
> changes in the JVM may automatically help Scala.

Is Fortress is the most likely candidate?
[http://projectfortress.sun.com/Projects/Community]

The Fortress language looks really cool. But every time I look at it,
it looks more, and more, and more, like Scala. Probably a good thing:
they recognize good ideas when they see them. What are the significant
differences..?

Perhaps one is that concurrency seems even more ingrained in Fortress
than Scala. Fortress lead Guy Steel's talk at ICFP, arguing that
sequential traversal over data structures is a weak approach in the
face of parallelism, that can often be replaced by trees + associative
operators, is well worth watching [http://www.vimeo.com/6624203]. That
puts the venerable linked list out of favor as a default data
structure.

-Ben

ijuma
Joined: 2008-08-20,
User offline. Last seen 22 weeks 2 days ago.
Re: Closures make it into Java 7

Ben Hutchison gmail.com> writes:
> On Thu, Nov 19, 2009 at 7:53 PM, Ismael Juma juma.me.uk> wrote:
> > Scala can certainly benefit from another statically typed language in the JVM
> > that tries to solve similar issues. Competition is good and in some cases,
> > changes in the JVM may automatically help Scala.
>
> Is Fortress is the most likely candidate?
> [http://projectfortress.sun.com/Projects/Community]

Fortress is certainly an interesting language and if they achieve some of their
objectives while staying in the JVM, this would require some improvements to the
JVM that would benefit Scala too.

> The Fortress language looks really cool. But every time I look at it,
> it looks more, and more, and more, like Scala. Probably a good thing:
> they recognize good ideas when they see them.

They also use Scala in their implementation so they can see them first hand. :)

> What are the significant differences..?

Fortress seemed to have more of a focus on performance (particularly for
numerical code), concurrency and mathematical notation. As I understand, the
next big target for Scala is concurrency, so the differences may shrink there.

Best,
Ismael

Chris Marshall
Joined: 2009-06-17,
User offline. Last seen 44 weeks 3 days ago.
RE: Closures make it into Java 7
> From: dave [dot] l [dot] griffith [at] gmail [dot] com
> After writen Groovy and Scala in anger, and Clojure for fun, I have
> absolutely no idea what sort of project I would possibly recommend Java 7
> for. It's baffling.
>
> Pretty scary, considering I helped instigate a Java 7 JSR back around 3.5
> years ago. (JSR-305, if anyone cares. I honestly don't.)

If that doesn't illuminate what is wrong with the JCP process, I don't know what does!

Dave, this isn't meant as a criticism of you, as I'm not surprised that 3.5 years down the line you've found a "workaround" (i.e. don't use Java)!

The more I use scala, the more I think that Josh Bloch was right about JDK7 closures in many respects. The lack of type inference in Java turns any program using closures and an unreadable morass of types and braces. (Which given that about 70% of any given snippet of Java was types-and-braces to start with, is not encouraging).



Use Hotmail to send and receive mail from your different email accounts. Find out how.
Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Closures make it into Java 7

Adding closures now doesn't preclude later type inference.

Anonymous classes are already an unreadable morass of types and
braces. imo any of the closures proposals for Java improve on that no
end.

2009/11/19 christopher marshall :
>> From: dave [dot] l [dot] griffith [at] gmail [dot] com
>> After writen Groovy and Scala in anger, and Clojure for fun, I have
>> absolutely no idea what sort of project I would possibly recommend Java 7
>> for. It's baffling.
>>
>> Pretty scary, considering I helped instigate a Java 7 JSR back around 3.5
>> years ago. (JSR-305, if anyone cares. I honestly don't.)
>
> If that doesn't illuminate what is wrong with the JCP process, I don't know
> what does!
>
> Dave, this isn't meant as a criticism of you, as I'm not surprised that 3.5
> years down the line you've found a "workaround" (i.e. don't use Java)!
>
> The more I use scala, the more I think that Josh Bloch was right about JDK7
> closures in many respects. The lack of type inference in Java turns any
> program using closures and an unreadable morass of types and braces. (Which
> given that about 70% of any given snippet of Java was types-and-braces to
> start with, is not encouraging).
>
>
>
> ________________________________
> Use Hotmail to send and receive mail from your different email accounts.
> Find out how.

Erik Engbrecht
Joined: 2008-12-19,
User offline. Last seen 3 years 18 weeks ago.
Re: Closures make it into Java 7
Adding closures to Java is important to other JVM languages for two reasons:(1) Once they are in Java, optimization of them will likely receive much more attention by the JVM team(2) Java is the least common denominator for most JVM languages.  In other words, they all interop with Java (to varying degrees), but for the most part they don't interop with each other.  If Java provides a good, standard way to implement closures, the other languages will adopt it (albeit probably with some of their own flavor) so that they can interop with Java libraries designed to use the closures.  The end result will be more compatibility among JVM languages.  It will also lead to libraries being written in Java that use closures, which will be much more idiomatic to use for JVM languages that make heavy use of closures.

On Wed, Nov 18, 2009 at 8:57 PM, Dave Griffith <dave [dot] l [dot] griffith [at] gmail [dot] com> wrote:


18 months ago I would have thought this news was quite important.

After writen Groovy and Scala in anger, and Clojure for fun, I have
absolutely no idea what sort of project I would possibly recommend Java 7
for.   It's baffling.

Pretty scary, considering I helped instigate a Java 7 JSR back around 3.5
years ago.  (JSR-305, if anyone cares.  I honestly don't.)

--Dave
--
View this message in context: http://old.nabble.com/Closures-make-it-into-Java-7-tp26416600p26419142.html
Sent from the Scala - Debate mailing list archive at Nabble.com.




--
http://erikengbrecht.blogspot.com/

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland