From neal at gafter.com  Sun Jun  1 20:37:42 2008
From: neal at gafter.com (Neal Gafter)
Date: Sun, 1 Jun 2008 20:37:42 -0700
Subject: Closures in openjdk
In-Reply-To: <20080528044258.9A79F2558@callebaut.niobe.net>
References: <15e8b9d20805241812h5433b2c8qb0f1957f54103cd5@mail.gmail.com>
	<20080528044258.9A79F2558@callebaut.niobe.net>
Message-ID: <15e8b9d20806012037k35b65584m1ffa9274cea0238a@mail.gmail.com>

On Tue, May 27, 2008 at 9:42 PM, Mark Reinhold <mr at sun.com> wrote:

> > Date: Sat, 24 May 2008 18:12:19 -0700
> > From: Neal Gafter <neal at gafter.com>
>
> > I haven't pushed the closures changes to the openjdk repository at your
> > request (April 21) because I'm awaiting confirmation that there are no
> issue
> > with copyrights on the sources.  Jon Gibbons has the diffs, but he's not
> > quite sure what you want him to look for.  Because the code is awaiting
> > review, I'm holding off on making any more changes, which means that bugs
> > people are reporting now are not being fixed.  As soon as I have your OK
> I
> > will push the code to the closures forest and resume development.
> >
> > Please let me know how you want to proceed.
>
> Sorry, but I'm out of the office for most of the next week or so.
> I'll get back to you by the end of next week.


Mark: I'd like to remind you that the Closures project is on hold at your
request while you review the IP ownership issues.  In my opinion, there are
no issues: I plan to distribute my changes through the closures openjdk
project under the GPLv2 license, and contribute them to Sun under the SCA.
All of the code in this project is either from the openjdk project or
written by me, and it is all uniformly licensed under GPLv2 with the
Classpath exception.  Please resolve whatever issue caused you to ask me to
put the project on hold.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080601/76976530/attachment.html 

From neal at gafter.com  Thu Jun 12 12:55:12 2008
From: neal at gafter.com (Neal Gafter)
Date: Thu, 12 Jun 2008 12:55:12 -0700
Subject: Fwd: Closures in openjdk
In-Reply-To: <15e8b9d20805241812h5433b2c8qb0f1957f54103cd5@mail.gmail.com>
References: <15e8b9d20805241812h5433b2c8qb0f1957f54103cd5@mail.gmail.com>
Message-ID: <15e8b9d20806121255w17ca914etcc80cf5e2dffb97b@mail.gmail.com>

Mark-

I haven't pushed the closures changes to the openjdk repository at your
request (April 21) because I'm awaiting confirmation that there are no issue
with copyrights on the sources.  Jon Gibbons has the diffs, but he's not
quite sure what you want him to look for.  Sun legal has provided no
guidance.  Because the code is awaiting copyright review at your request,
I've held off on making any more changes, which means that bugs people have
reported have not been fixed.  I have asked you repeatedly how you'd like to
proceed, but you have not responded.  This project has a time schedule and
deadline <
http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-February/000047.html>,
which has already slipped due to your request.

If you do not tell my of any specific problems with the copyrights on the
proposed "Closures" code changes by the end of next week (June 21), I will
push my changes to the public repository and resume development.

Regards,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080612/a7997958/attachment.html 

From mr at sun.com  Thu Jun 12 14:29:03 2008
From: mr at sun.com (Mark Reinhold)
Date: Thu, 12 Jun 2008 14:29:03 -0700
Subject: Fwd: Closures in openjdk 
In-Reply-To: neal@gafter.com; Thu, 12 Jun 2008 12:55:12 PDT;
	<15e8b9d20806121255w17ca914etcc80cf5e2dffb97b@mail.gmail.com> 
Message-ID: <20080612212903.DD09D8DD3@eggemoggin.niobe.net>

> Date: Thu, 12 Jun 2008 12:55:12 -0700
> From: Neal Gafter <neal at gafter.com>

> I haven't pushed the closures changes to the openjdk repository at your
> request (April 21) because I'm awaiting confirmation that there are no issue
> with copyrights on the sources.  Jon Gibbons has the diffs, but he's not
> quite sure what you want him to look for.

I apologize for the delay on this, but I've been out of the office for
most of the last few weeks tending to unexpected family business.

The issue here is not one of copyright.

The problem is, as I explained back in April, that you based the Closures
prototype on the JRL source distribution, and under the terms of the JRL
you don't have the right to publish your modified version under the GPL,
or to forward-port your changes to a GPL'd OpenJDK source tree and
publish that.  (IANAL, but that's my best understanding of the story.)

This situation is similar to that of the FreeBSD port, so we've already
been working with Sun Legal on a solution.  Yesterday I received final
approval on a letter to you which will clarify Sun's understanding of the
situation.  I'll send that to you in a moment.

If you find the letter acceptable then the next step is for you to send
diffs of your changes relative to an OpenJDK tree to Jonathan Gibbons as
a contribution under the SCA.  Jon can then apply the diffs, push the
result into the Closures forest, and from that point onward the code will
be GPL'd.

- Mark


From neal at gafter.com  Fri Jun 13 00:36:41 2008
From: neal at gafter.com (Neal Gafter)
Date: Fri, 13 Jun 2008 00:36:41 -0700
Subject: Fwd: Closures in openjdk
In-Reply-To: <20080612212903.DD09D8DD3@eggemoggin.niobe.net>
References: <15e8b9d20806121255w17ca914etcc80cf5e2dffb97b@mail.gmail.com>
	<20080612212903.DD09D8DD3@eggemoggin.niobe.net>
Message-ID: <15e8b9d20806130036k7a0f523ct52b23f86ac19687b@mail.gmail.com>

On Thu, Jun 12, 2008 at 2:29 PM, Mark Reinhold <mr at sun.com> wrote:

> The issue here is not one of copyright.
>
> The problem is, as I explained back in April, that you based the Closures
> prototype on the JRL source distribution, and under the terms of the JRL
> you don't have the right to publish your modified version under the GPL,
> or to forward-port your changes to a GPL'd OpenJDK source tree and
> publish that.  (IANAL, but that's my best understanding of the story.)


Your understanding of my development processes is incorrect.  In any case,
my development processes are irrelevant. I own my changes until I license or
contribute them to another party.  Sun has granted me a license to the
openjdk code under GPLv2.  Under section 2 of that license I have been
granted the right to distribute my modified version - that is, a version
that contains only Sun's GPLv2 code with my own changes.  *Sun is attempting
to repudiate its license to me under the GPL by adding additional
restrictions to my ability to distribute my modified version - specifically,
the requirement that I contribute my changes to Sun Microsystems before
publishing them under GPL.  That is a violation of section 6 of the GPL.*
Presuming you want downstream receivers of openjdk code to be bound by GPLv2
section 6, Sun Microsystems must honor its license.

You have my changes.  Please describe precisely what intellectual property I
have misused and in what way.  Otherwise I plan to publish my changes on or
after June 21.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080613/37b0eac0/attachment.html 

From neal at gafter.com  Fri Jun 13 16:16:39 2008
From: neal at gafter.com (Neal Gafter)
Date: Fri, 13 Jun 2008 16:16:39 -0700
Subject: Fwd: Closures in openjdk
In-Reply-To: <15e8b9d20806130036k7a0f523ct52b23f86ac19687b@mail.gmail.com>
References: <15e8b9d20806121255w17ca914etcc80cf5e2dffb97b@mail.gmail.com>
	<20080612212903.DD09D8DD3@eggemoggin.niobe.net>
	<15e8b9d20806130036k7a0f523ct52b23f86ac19687b@mail.gmail.com>
Message-ID: <15e8b9d20806131616m7810aa5cmd16431df7aabf6ef@mail.gmail.com>

Mark-

First, I'd like to apologize for the tone of my previous messages.  The past
couple of weeks has been very stressful for me (we just moved our
household), but I shouldn't be taking it out on you or Sun.  I believe you
were trying to help me resolve a possible license conflict that you
perceived to exist in my sources.

I think there has been a misunderstaing about how I developed the closures
prototype.  The binaries I distributed were generated by applying a set of
diffs to the JRL version of the code.  Every distributed version I produced
was generated from sources that were uniformly licensed under the JRL plus
my own original deltas.  My new source files were under headers asserting my
own personal copyright.

The underlying code that my diffs are applicable to have been dual licensed
to me by Sun under both the JRL and GPLv2.  The diffs I sent to Jonathan
contain no JRL code whatsoever. The full patch is based on and contains only
code licensed under GPLv2.  I have even added GPLv2 license headers to my
new source files.  Therefore both you and I are free to distribute that set
of changes under GPLv2.  I am depending only on rights granted under GPLv2.
I am not depending on any rights granted under the JRL for the openjdk
closures project, so my proposed actions cannot reasonably be interpreted as
a violation of that license.

I don't think I need any special dispensation from Sun to continue
development of the closures project.

Regards,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080613/383c2eea/attachment.html 

From mark at twistedbanana.demon.co.uk  Mon Jun 16 05:42:08 2008
From: mark at twistedbanana.demon.co.uk (Mark Mahieu)
Date: Mon, 16 Jun 2008 13:42:08 +0100
Subject: Incorrect line number in stack trace
Message-ID: <23C81417-2A1D-4F9A-93EB-EB523B39C9B6@twistedbanana.demon.co.uk>

There appears to be some interaction between closures and for-each  
loops which can cause incorrect line numbers in stack traces.

A couple of examples:


public class StackTraceWrongLine1 {
	
	public static void main(String[] args) {

		// Stack trace indicates that the NPE occurs here:
		String[] items = null;
		
		// Comment out this line, and the stack trace is fine
		{==> void} notInvoked = {==> items = args; };
		
		for (String item : items) { }
	}
}


Exception in thread "main" java.lang.NullPointerException
         at StackTraceWrongLine1.main(StackTraceWrongLine1.java:6)


- - - - - - - -


public class StackTraceWrongLine2 {
	
	public static void main(String[] args) {

		// Stack trace indicates that items.iterator() is called here:
		Iterable<String> items = {=> throw new RuntimeException(); };
		
		for (String item : items) { }
	}
}


Exception in thread "main" java.lang.RuntimeException
         at StackTraceWrongLine2$2.+invoke(StackTraceWrongLine2.java:6)
         at StackTraceWrongLine2$2.iterator(StackTraceWrongLine2.java:6)
         at StackTraceWrongLine2.main(StackTraceWrongLine2.java:6)



Regards,

Mark



From neal at gafter.com  Mon Jun 16 08:27:28 2008
From: neal at gafter.com (Neal Gafter)
Date: Mon, 16 Jun 2008 08:27:28 -0700
Subject: Incorrect line number in stack trace
In-Reply-To: <23C81417-2A1D-4F9A-93EB-EB523B39C9B6@twistedbanana.demon.co.uk>
References: <23C81417-2A1D-4F9A-93EB-EB523B39C9B6@twistedbanana.demon.co.uk>
Message-ID: <15e8b9d20806160827t5b4d3e4kf2508c9e01adeb00@mail.gmail.com>

Mark-

Thanks for the report!  I'll look into this after I've pushed the initial
prototype to the openjdk project.

Regards,
Neal

On Mon, Jun 16, 2008 at 5:42 AM, Mark Mahieu <mark at twistedbanana.demon.co.uk>
wrote:

> There appears to be some interaction between closures and for-each loops
> which can cause incorrect line numbers in stack traces.
>
> A couple of examples:
>
>
> public class StackTraceWrongLine1 {
>
>        public static void main(String[] args) {
>
>                // Stack trace indicates that the NPE occurs here:
>                String[] items = null;
>
>                // Comment out this line, and the stack trace is fine
>                {==> void} notInvoked = {==> items = args; };
>
>                for (String item : items) { }
>        }
> }
>
>
> Exception in thread "main" java.lang.NullPointerException
>        at StackTraceWrongLine1.main(StackTraceWrongLine1.java:6)
>
>
> - - - - - - - -
>
>
> public class StackTraceWrongLine2 {
>
>        public static void main(String[] args) {
>
>                // Stack trace indicates that items.iterator() is called
> here:
>                Iterable<String> items = {=> throw new RuntimeException();
> };
>
>                for (String item : items) { }
>        }
> }
>
>
> Exception in thread "main" java.lang.RuntimeException
>        at StackTraceWrongLine2$2.+invoke(StackTraceWrongLine2.java:6)
>        at StackTraceWrongLine2$2.iterator(StackTraceWrongLine2.java:6)
>        at StackTraceWrongLine2.main(StackTraceWrongLine2.java:6)
>
>
>
> Regards,
>
> Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080616/113678cb/attachment.html 

From mark at twistedbanana.demon.co.uk  Tue Jun 17 01:22:01 2008
From: mark at twistedbanana.demon.co.uk (Mark Mahieu)
Date: Tue, 17 Jun 2008 09:22:01 +0100
Subject: Compiler crash - StackOverflowError
Message-ID: <39DE81E4-CC00-448C-A9BF-B825ED6E8414@twistedbanana.demon.co.uk>

The following class triggers a StackOverflowError in the compiler:


class StackOverflow {

	class Inner {
		{=> String} ref = this#toString();
	}
}


The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
         at com.sun.tools.javac.comp.Lower.access(Lower.java:970)
         at com.sun.tools.javac.comp.Lower.access(Lower.java:1060)
         at com.sun.tools.javac.comp.Lower.makeOwnerThisN(Lower.java: 
1401)
         at com.sun.tools.javac.comp.Lower.makeOwnerThis(Lower.java: 
1385)
         at com.sun.tools.javac.comp.Lower.accessBase(Lower.java:886)
         at com.sun.tools.javac.comp.Lower.access(Lower.java:1046)
         at com.sun.tools.javac.comp.Lower.access(Lower.java:1060)
         at com.sun.tools.javac.comp.Lower.makeOwnerThisN(Lower.java: 
1401)
         at com.sun.tools.javac.comp.Lower.makeOwnerThis(Lower.java: 
1385)
         at com.sun.tools.javac.comp.Lower.accessBase(Lower.java:886)
         at com.sun.tools.javac.comp.Lower.access(Lower.java:1046)
         at com.sun.tools.javac.comp.Lower.access(Lower.java:1060)
         at com.sun.tools.javac.comp.Lower.makeOwnerThisN(Lower.java: 
1401)
         at com.sun.tools.javac.comp.Lower.makeOwnerThis(Lower.java: 
1385)
         at com.sun.tools.javac.comp.Lower.accessBase(Lower.java:886)
         at com.sun.tools.javac.comp.Lower.access(Lower.java:1046)
         at com.sun.tools.javac.comp.Lower.access(Lower.java:1060)
         ....



Regards,

Mark


From mark at twistedbanana.demon.co.uk  Tue Jun 17 01:35:10 2008
From: mark at twistedbanana.demon.co.uk (Mark Mahieu)
Date: Tue, 17 Jun 2008 09:35:10 +0100
Subject: 'no enclosing instance' error
Message-ID: <637A5315-22B9-4A59-8AC4-C8F0A21C2E5C@twistedbanana.demon.co.uk>

While producing the StackOverflowError test case I noticed that this  
doesn't compile either - perhaps it's related:


class NoEnclosingInstance {

	{=> String} ref = this#toString();
}


NoEnclosingInstance.java:3: no enclosing instance of type  
NoEnclosingInstance is in scope
         {=> String} ref = this#toString();
                               ^


Regards,

Mark



From neal at gafter.com  Tue Jun 17 08:13:48 2008
From: neal at gafter.com (Neal Gafter)
Date: Tue, 17 Jun 2008 08:13:48 -0700
Subject: 'no enclosing instance' error
In-Reply-To: <637A5315-22B9-4A59-8AC4-C8F0A21C2E5C@twistedbanana.demon.co.uk>
References: <637A5315-22B9-4A59-8AC4-C8F0A21C2E5C@twistedbanana.demon.co.uk>
Message-ID: <15e8b9d20806170813n38aa3f07nc44dc21516439229@mail.gmail.com>

Mark-

Thanks for the report!  This is definitely a bug.

On Tue, Jun 17, 2008 at 1:35 AM, Mark Mahieu <mark at twistedbanana.demon.co.uk>
wrote:

> While producing the StackOverflowError test case I noticed that this
> doesn't compile either - perhaps it's related:
>
>
> class NoEnclosingInstance {
>
>        {=> String} ref = this#toString();
> }
>
>
> NoEnclosingInstance.java:3: no enclosing instance of type
> NoEnclosingInstance is in scope
>        {=> String} ref = this#toString();
>                              ^
>
>
> Regards,
>
> Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080617/79ca8933/attachment.html 

From neal at gafter.com  Tue Jun 17 08:15:00 2008
From: neal at gafter.com (Neal Gafter)
Date: Tue, 17 Jun 2008 08:15:00 -0700
Subject: Compiler crash - StackOverflowError
In-Reply-To: <39DE81E4-CC00-448C-A9BF-B825ED6E8414@twistedbanana.demon.co.uk>
References: <39DE81E4-CC00-448C-A9BF-B825ED6E8414@twistedbanana.demon.co.uk>
Message-ID: <15e8b9d20806170815h5a2771fem48f261b86de49199@mail.gmail.com>

Mark-

Yes, this is a bug.  Thanks for reporting it!

Regards,
Neal

On Tue, Jun 17, 2008 at 1:22 AM, Mark Mahieu <mark at twistedbanana.demon.co.uk>
wrote:

> The following class triggers a StackOverflowError in the compiler:
>
>
> class StackOverflow {
>
>        class Inner {
>                {=> String} ref = this#toString();
>        }
> }
>
>
> The system is out of resources.
> Consult the following stack trace for details.
> java.lang.StackOverflowError
>        at com.sun.tools.javac.comp.Lower.access(Lower.java:970)
>        at com.sun.tools.javac.comp.Lower.access(Lower.java:1060)
>        at com.sun.tools.javac.comp.Lower.makeOwnerThisN(Lower.java:1401)
>        at com.sun.tools.javac.comp.Lower.makeOwnerThis(Lower.java:1385)
>        at com.sun.tools.javac.comp.Lower.accessBase(Lower.java:886)
>        at com.sun.tools.javac.comp.Lower.access(Lower.java:1046)
>        at com.sun.tools.javac.comp.Lower.access(Lower.java:1060)
>        at com.sun.tools.javac.comp.Lower.makeOwnerThisN(Lower.java:1401)
>        at com.sun.tools.javac.comp.Lower.makeOwnerThis(Lower.java:1385)
>        at com.sun.tools.javac.comp.Lower.accessBase(Lower.java:886)
>        at com.sun.tools.javac.comp.Lower.access(Lower.java:1046)
>        at com.sun.tools.javac.comp.Lower.access(Lower.java:1060)
>        at com.sun.tools.javac.comp.Lower.makeOwnerThisN(Lower.java:1401)
>        at com.sun.tools.javac.comp.Lower.makeOwnerThis(Lower.java:1385)
>        at com.sun.tools.javac.comp.Lower.accessBase(Lower.java:886)
>        at com.sun.tools.javac.comp.Lower.access(Lower.java:1046)
>        at com.sun.tools.javac.comp.Lower.access(Lower.java:1060)
>        ....
>
>
>
> Regards,
>
> Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080617/03ed92e0/attachment.html 

From mr at sun.com  Wed Jun 18 09:59:19 2008
From: mr at sun.com (Mark Reinhold)
Date: Wed, 18 Jun 2008 09:59:19 -0700
Subject: Fwd: Closures in openjdk 
In-Reply-To: neal@gafter.com; Fri, 13 Jun 2008 16:16:39 PDT;
	<15e8b9d20806131616m7810aa5cmd16431df7aabf6ef@mail.gmail.com> 
Message-ID: <20080618165919.38F5B5BCB@eggemoggin.niobe.net>

> Date: Fri, 13 Jun 2008 16:16:39 -0700
> From: Neal Gafter <neal at gafter.com>

> I think there has been a misunderstaing about how I developed the closures
> prototype.  The binaries I distributed were generated by applying a set of
> diffs to the JRL version of the code.  Every distributed version I produced
> was generated from sources that were uniformly licensed under the JRL plus
> my own original deltas.  My new source files were under headers asserting my
> own personal copyright.

I don't see any problem with this (though IANAL).

> The underlying code that my diffs are applicable to have been dual licensed
> to me by Sun under both the JRL and GPLv2.  The diffs I sent to Jonathan
> contain no JRL code whatsoever. The full patch is based on and contains only
> code licensed under GPLv2.  I have even added GPLv2 license headers to my
> new source files.  Therefore both you and I are free to distribute that set
> of changes under GPLv2.  I am depending only on rights granted under GPLv2.
> I am not depending on any rights granted under the JRL for the openjdk
> closures project, so my proposed actions cannot reasonably be interpreted as
> a violation of that license.
> 
> I don't think I need any special dispensation from Sun to continue
> development of the closures project.

Here, things get tricky.

Sun has never dual-licensed any code under both the JRL and GPLv2, at
least not by the usual definition of that term, i.e., by shipping one
source bundle that carries both licenses.  Much of the JDK code that
was (and still is) available under the JRL was also made available
under GPLv2 starting in May 2007, in entirely separate source bundles.
Changes developed against that code under the JRL prior to May 2007 are,
from a strict legal perspective, covered by the JRL rather than GPLv2.

My understanding -- which may be incorrect -- is that you began work
on the Closures prototype before May 2007, using the javac code that
was GPL'd in November 2006 combined with some non-javac code (e.g.,
some existing java.lang classes) acquired under the JRL.  If this is
true then your modifications to the non-javac code are covered by the
JRL rather than GPLv2 even though the same non-javac code was later
made available under GPLv2.

I realize that, from a purely practical perspective, this may seem
rather artificial.  I've therefore asked Sun legal to check the above
analysis and consider whether there's some way for you to go ahead and
publish all of your changes under GPLv2 without "special dispensation",
as you say, from Sun.  I hope to get an answer from them in the next
few days.

In the meantime, you've already received the letter granting you the
right to contribute changes originally developed under the JRL after
forward-porting them to the current GPLv2 code.  If you want to get
moving today rather than wait for this legalistic corner case to be
settled then all you need to do is send your patch to Jon Gibbons as
a contribution under the SCA.  Jon can then apply the diffs, push the
result into the Closures forest, and from that point onward the code
will be GPL'd.

- Mark


From mark at twistedbanana.demon.co.uk  Wed Jun 18 14:06:28 2008
From: mark at twistedbanana.demon.co.uk (Mark Mahieu)
Date: Wed, 18 Jun 2008 22:06:28 +0100
Subject: Unable to instantiate a local class within a closure literal
Message-ID: <C994D133-083F-49FD-836A-09BCE9608D95@twistedbanana.demon.co.uk>

Attempting to declare and then instantiate a local class within a  
closure literal fails to compile if that closure literal is not in a  
static method or block:


class NotEnclosingClass {
	
	{=> void} block1 = {=> class Local {}; new Local(); };
	
	static {
		// fine here
		{=> void} block2 = {=> class Local {}; new Local(); };
	}
}


NotEnclosingClass.java:3: not an enclosing class: <anonymous  
NotEnclosingClass$1>
         {=> void} block1 = {=> class Local {}; new Local(); };
                                                ^
1 error


Regards,

Mark


From neal at gafter.com  Wed Jun 18 15:24:55 2008
From: neal at gafter.com (Neal Gafter)
Date: Wed, 18 Jun 2008 15:24:55 -0700
Subject: Unable to instantiate a local class within a closure literal
In-Reply-To: <C994D133-083F-49FD-836A-09BCE9608D95@twistedbanana.demon.co.uk>
References: <C994D133-083F-49FD-836A-09BCE9608D95@twistedbanana.demon.co.uk>
Message-ID: <15e8b9d20806181524vd00e7d2p19a44d089cbd326f@mail.gmail.com>

Thanks for the report!  This is an interesting one.  I'll look at it
when I resume development.

On Wed, Jun 18, 2008 at 2:06 PM, Mark Mahieu
<mark at twistedbanana.demon.co.uk> wrote:
> Attempting to declare and then instantiate a local class within a closure
> literal fails to compile if that closure literal is not in a static method
> or block:
>
>
> class NotEnclosingClass {
>
>        {=> void} block1 = {=> class Local {}; new Local(); };
>
>        static {
>                // fine here
>                {=> void} block2 = {=> class Local {}; new Local(); };
>        }
> }
>
>
> NotEnclosingClass.java:3: not an enclosing class: <anonymous
> NotEnclosingClass$1>
>        {=> void} block1 = {=> class Local {}; new Local(); };
>                                               ^
> 1 error
>
>
> Regards,
>
> Mark
>


From tronicek at fel.cvut.cz  Wed Jun 18 23:33:01 2008
From: tronicek at fel.cvut.cz (Zdenek Tronicek)
Date: Thu, 19 Jun 2008 08:33:01 +0200
Subject: Changes
In-Reply-To: <20080618165919.38F5B5BCB@eggemoggin.niobe.net>
References: <20080618165919.38F5B5BCB@eggemoggin.niobe.net>
Message-ID: <20080619083301.matuoknd748sk8so@wimap.feld.cvut.cz>

Hi Neal,

I would like to ask you for one thing: if you plan any changes in  
syntax (e.g. -> instead of =>), do it now and not at the very end.

> My understanding -- which may be incorrect -- is that you began work
> on the Closures prototype before May 2007, using the javac code that
> was GPL'd in November 2006 combined with some non-javac code (e.g.,
> some existing java.lang classes) acquired under the JRL.  If this is
> true then your modifications to the non-javac code are covered by the
> JRL rather than GPLv2 even though the same non-javac code was later
> made available under GPLv2.

I must admit I do not understand the matter here. Is it a problem for  
you to say something like: "ok, I throw away all the old code and  
start now from the scratch... so all my code is based on code under  
GPLv2"? Or, this is not possible?

Zdenek
-- 
Zdenek Tronicek
Department of Computer Science and Engineering
Prague                   tel: +420 2 2435 7410
http://cs.felk.cvut.cz/~tronicek





From mark at twistedbanana.demon.co.uk  Thu Jun 19 03:15:04 2008
From: mark at twistedbanana.demon.co.uk (Mark Mahieu)
Date: Thu, 19 Jun 2008 11:15:04 +0100
Subject: Compiler crash - AssertionError
Message-ID: <8926757E-B2EB-4ED7-BBF9-917DEC9CFAF6@twistedbanana.demon.co.uk>

This class triggers an AssertionError:


class AssertionErrorCrash {
	
	interface A {}
	interface B {}
	
	static class AB1 implements A, B {}
	static class AB2 implements A, B {}
	
	static <T> void foo({=>T} fn1, {=>T} fn2) {}
	
	public static void main(String[] args) {
		
		foo({=> new AB1()}, {=> new AB2()});
	}
}


java.lang.AssertionError
         at com.sun.tools.javac.jvm.ClassWriter.enterInner 
(ClassWriter.java:902)
         at com.sun.tools.javac.jvm.ClassWriter.assembleClassSig 
(ClassWriter.java:387)
         at com.sun.tools.javac.jvm.ClassWriter.assembleSig 
(ClassWriter.java:305)
         at com.sun.tools.javac.jvm.ClassWriter.assembleSig 
(ClassWriter.java:318)
         at com.sun.tools.javac.jvm.ClassWriter.typeSig 
(ClassWriter.java:444)
         at com.sun.tools.javac.jvm.ClassWriter.writeMemberAttrs 
(ClassWriter.java:696)
         at com.sun.tools.javac.jvm.ClassWriter.writeMethod 
(ClassWriter.java:1011)
         at com.sun.tools.javac.jvm.ClassWriter.writeMethods 
(ClassWriter.java:1467)
         at com.sun.tools.javac.jvm.ClassWriter.writeClassFile 
(ClassWriter.java:1548)
         at com.sun.tools.javac.jvm.ClassWriter.writeClass 
(ClassWriter.java:1485)
         at com.sun.tools.javac.main.JavaCompiler.genCode 
(JavaCompiler.java:646)
         at com.sun.tools.javac.main.JavaCompiler.generate 
(JavaCompiler.java:1315)
         at com.sun.tools.javac.main.JavaCompiler.generate 
(JavaCompiler.java:1285)
         at com.sun.tools.javac.main.JavaCompiler.compile2 
(JavaCompiler.java:793)
         at com.sun.tools.javac.main.JavaCompiler.compile 
(JavaCompiler.java:758)
         at com.sun.tools.javac.main.Main.compile(Main.java:380)
         at com.sun.tools.javac.main.Main.compile(Main.java:306)
         at com.sun.tools.javac.main.Main.compile(Main.java:297)
         at com.sun.tools.javac.Main.compile(Main.java:82)
         at com.sun.tools.javac.Main.main(Main.java:67)


Regards,

Mark



From neal at gafter.com  Thu Jun 19 08:42:20 2008
From: neal at gafter.com (Neal Gafter)
Date: Thu, 19 Jun 2008 08:42:20 -0700
Subject: Compiler crash - AssertionError
In-Reply-To: <8926757E-B2EB-4ED7-BBF9-917DEC9CFAF6@twistedbanana.demon.co.uk>
References: <8926757E-B2EB-4ED7-BBF9-917DEC9CFAF6@twistedbanana.demon.co.uk>
Message-ID: <15e8b9d20806190842l486bf5b1p899ce24c46336b19@mail.gmail.com>

Thanks for the report.  This is very interesting; the inferred type
for T is A&B.  I'll look at this when I resume development.

Regards,
Neal

On Thu, Jun 19, 2008 at 3:15 AM, Mark Mahieu
<mark at twistedbanana.demon.co.uk> wrote:
> This class triggers an AssertionError:
>
>
> class AssertionErrorCrash {
>
>        interface A {}
>        interface B {}
>
>        static class AB1 implements A, B {}
>        static class AB2 implements A, B {}
>
>        static <T> void foo({=>T} fn1, {=>T} fn2) {}
>
>        public static void main(String[] args) {
>
>                foo({=> new AB1()}, {=> new AB2()});
>        }
> }
>
>
> java.lang.AssertionError
>        at
> com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:902)
>        at
> com.sun.tools.javac.jvm.ClassWriter.assembleClassSig(ClassWriter.java:387)
>        at
> com.sun.tools.javac.jvm.ClassWriter.assembleSig(ClassWriter.java:305)
>        at
> com.sun.tools.javac.jvm.ClassWriter.assembleSig(ClassWriter.java:318)
>        at com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:444)
>        at
> com.sun.tools.javac.jvm.ClassWriter.writeMemberAttrs(ClassWriter.java:696)
>        at
> com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1011)
>        at
> com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1467)
>        at
> com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1548)
>        at
> com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1485)
>        at
> com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:646)
>        at
> com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1315)
>        at
> com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1285)
>        at
> com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:793)
>        at
> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:758)
>        at com.sun.tools.javac.main.Main.compile(Main.java:380)
>        at com.sun.tools.javac.main.Main.compile(Main.java:306)
>        at com.sun.tools.javac.main.Main.compile(Main.java:297)
>        at com.sun.tools.javac.Main.compile(Main.java:82)
>        at com.sun.tools.javac.Main.main(Main.java:67)
>
>
> Regards,
>
> Mark
>
>


From neal at gafter.com  Thu Jun 19 09:15:23 2008
From: neal at gafter.com (Neal Gafter)
Date: Thu, 19 Jun 2008 09:15:23 -0700
Subject: Changes
In-Reply-To: <20080619083301.matuoknd748sk8so@wimap.feld.cvut.cz>
References: <20080618165919.38F5B5BCB@eggemoggin.niobe.net>
	<20080619083301.matuoknd748sk8so@wimap.feld.cvut.cz>
Message-ID: <15e8b9d20806190915xf3fd8e2ma1d882089ab44d13@mail.gmail.com>

On Wed, Jun 18, 2008 at 11:33 PM, Zdenek Tronicek <tronicek at fel.cvut.cz> wrote:
> Hi Neal,
>
> I would like to ask you for one thing: if you plan any changes in syntax
> (e.g. -> instead of =>), do it now and not at the very end.
>
>> My understanding -- which may be incorrect -- is that you began work
>> on the Closures prototype before May 2007, using the javac code that
>> was GPL'd in November 2006 combined with some non-javac code (e.g.,
>> some existing java.lang classes) acquired under the JRL.  If this is
>> true then your modifications to the non-javac code are covered by the
>> JRL rather than GPLv2 even though the same non-javac code was later
>> made available under GPLv2.
>
> I must admit I do not understand the matter here. Is it a problem for you to
> say something like: "ok, I throw away all the old code and start now from
> the scratch... so all my code is based on code under GPLv2"? Or, this is not
> possible?

Sure, that would be possible if I had another month of vacation time
that I wanted to throw away.  But I don't.  I don't think it is
reasonable for Sun to assert any restrictions on my changes that are
not permitted by the underlying license to the modified GPLv2 code.
Moreover, the OpenJDK Innovators Grant rules require that I contribute
the code to the openjdk through prevailing processes; Mark's
suggestion has Sun contributing the code.

As far as I can tell, the only changes that fall into the category
that Mark is expressing concern about are the addition of some
"extends" clauses in interfaces like java.lang.Comparable,
java.lang.Iterable, and java.lang.Runnable. I fail to see how applying
those changes to the GPLv2 code and releasing them under GPLv2 can be
construed as an infringement of Sun's copyrights, as the underlying
code has been licensed to me under GPLv2.  If I redo those changes
from scratch the result would be bit-for-bit identical to what I have
now.


From mark at twistedbanana.demon.co.uk  Fri Jun 20 02:06:48 2008
From: mark at twistedbanana.demon.co.uk (Mark Mahieu)
Date: Fri, 20 Jun 2008 10:06:48 +0100
Subject: 'improperly formed type' error
Message-ID: <CA9B7315-12C8-4475-BDAF-9903D76ACA48@twistedbanana.demon.co.uk>

This one's a minor niggle - a non-static generic inner class nested  
in another generic class cannot be instantiated from within a closure  
unless qualified with the enclosing type:


class ImproperlyFormedType<E> {
	
	class Inner<T> {}

	void makeInner() {
		
		// this is ok
		new Inner<String>();
		
		// but not when wrapped in a closure
		{=> new Inner<String>(); }.invoke();
		
		// qualifying it solves the problem
		{=> new ImproperlyFormedType<E>.Inner<String>(); }.invoke();
	}
}


ImproperlyFormedType.java:11: improperly formed type, type parameters  
given on a raw type
                 {=> new Inner<String>(); }.invoke();
                              ^
1 error


Regards,

Mark


From neal at gafter.com  Fri Jun 20 12:32:53 2008
From: neal at gafter.com (Neal Gafter)
Date: Fri, 20 Jun 2008 12:32:53 -0700
Subject: 'improperly formed type' error
In-Reply-To: <CA9B7315-12C8-4475-BDAF-9903D76ACA48@twistedbanana.demon.co.uk>
References: <CA9B7315-12C8-4475-BDAF-9903D76ACA48@twistedbanana.demon.co.uk>
Message-ID: <15e8b9d20806201232o4ba694d6v8ad98c26aad623d9@mail.gmail.com>

Mark-

This is definitely a bug.  It should work the same with or without the
qualification.

Thanks for the report!

Regards,
Neal

On Fri, Jun 20, 2008 at 2:06 AM, Mark Mahieu <mark at twistedbanana.demon.co.uk>
wrote:

> This one's a minor niggle - a non-static generic inner class nested in
> another generic class cannot be instantiated from within a closure unless
> qualified with the enclosing type:
>
>
> class ImproperlyFormedType<E> {
>
>        class Inner<T> {}
>
>        void makeInner() {
>
>                // this is ok
>                new Inner<String>();
>
>                // but not when wrapped in a closure
>                {=> new Inner<String>(); }.invoke();
>
>                // qualifying it solves the problem
>                {=> new ImproperlyFormedType<E>.Inner<String>(); }.invoke();
>        }
> }
>
>
> ImproperlyFormedType.java:11: improperly formed type, type parameters given
> on a raw type
>                {=> new Inner<String>(); }.invoke();
>                             ^
> 1 error
>
>
> Regards,
>
> Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080620/9203f55c/attachment.html 

From mark at twistedbanana.demon.co.uk  Sun Jun 22 19:15:30 2008
From: mark at twistedbanana.demon.co.uk (Mark Mahieu)
Date: Mon, 23 Jun 2008 03:15:30 +0100
Subject: Intersection bounds on 'throws' type variables
Message-ID: <EF497D60-D10D-42CC-AE59-51A8935A3542@twistedbanana.demon.co.uk>

Should 'throws' type variables accept intersection type bounds?  The  
parser doesn't seem to like that at the moment:


class MultipleBoundsOnThrowsTypeVar {

	interface Marker {}
	static class MyException extends Exception implements Marker {}

	static <throws X extends Throwable & Marker> void foo({==>void  
throws X} block) throws X { block.invoke(); }
	
	public static void main(String[] args) throws MyException {
		
		foo({=> if (args.length == 1) throw new MyException(); });
	}
}


MultipleBoundsOnThrowsTypeVar.java:6: > expected
         static <throws X extends Throwable & Marker> void foo 
({==>void throws X} block) throws X { block.invoke(); }
                                           ^
MultipleBoundsOnThrowsTypeVar.java:6: illegal start of type
         static <throws X extends Throwable & Marker> void foo 
({==>void throws X} block) throws X { block.invoke(); }
                                            ^
MultipleBoundsOnThrowsTypeVar.java:6: '(' expected
         static <throws X extends Throwable & Marker> void foo 
({==>void throws X} block) throws X { block.invoke(); }
                                                    ^
3 errors


Regards,

Mark


From neal at gafter.com  Sun Jun 22 20:07:55 2008
From: neal at gafter.com (Neal Gafter)
Date: Sun, 22 Jun 2008 20:07:55 -0700
Subject: Intersection bounds on 'throws' type variables
In-Reply-To: <EF497D60-D10D-42CC-AE59-51A8935A3542@twistedbanana.demon.co.uk>
References: <EF497D60-D10D-42CC-AE59-51A8935A3542@twistedbanana.demon.co.uk>
Message-ID: <15e8b9d20806222007o3820a277l6ba4ad6dc9f0807c@mail.gmail.com>

Mark-

It was probably just an oversight in the parser.  I'll look into this.

Thanks for the report!

Regards,
Neal


On Sun, Jun 22, 2008 at 7:15 PM, Mark Mahieu
<mark at twistedbanana.demon.co.uk> wrote:
> Should 'throws' type variables accept intersection type bounds?  The parser
> doesn't seem to like that at the moment:
>
>
> class MultipleBoundsOnThrowsTypeVar {
>
>        interface Marker {}
>        static class MyException extends Exception implements Marker {}
>
>        static <throws X extends Throwable & Marker> void foo({==>void throws
> X} block) throws X { block.invoke(); }
>
>        public static void main(String[] args) throws MyException {
>
>                foo({=> if (args.length == 1) throw new MyException(); });
>        }
> }
>
>
> MultipleBoundsOnThrowsTypeVar.java:6: > expected
>        static <throws X extends Throwable & Marker> void foo({==>void throws
> X} block) throws X { block.invoke(); }
>                                          ^
> MultipleBoundsOnThrowsTypeVar.java:6: illegal start of type
>        static <throws X extends Throwable & Marker> void foo({==>void throws
> X} block) throws X { block.invoke(); }
>                                           ^
> MultipleBoundsOnThrowsTypeVar.java:6: '(' expected
>        static <throws X extends Throwable & Marker> void foo({==>void throws
> X} block) throws X { block.invoke(); }
>                                                   ^
> 3 errors
>
>
> Regards,
>
> Mark
>


From mark at twistedbanana.demon.co.uk  Tue Jun 24 12:57:40 2008
From: mark at twistedbanana.demon.co.uk (Mark Mahieu)
Date: Tue, 24 Jun 2008 20:57:40 +0100
Subject: Compiler crash - NPE in Resolve.isAccessible
Message-ID: <9826C57D-DAC9-4988-907C-E45FCEC8CA84@twistedbanana.demon.co.uk>

This class triggers a NullPointerException in the compiler:


class PrivateCrash {
	
	private interface Block {}
	
	static ThreadLocal<Block> tl;
	
	public static void main(String[] args) {

		Object o = {=> Block b = tl.get(); };
	}
}


java.lang.NullPointerException
         at com.sun.tools.javac.comp.Resolve.isAccessible 
(Resolve.java:140)
         at com.sun.tools.javac.comp.TransTypes.cast(TransTypes.java: 
111)
         at com.sun.tools.javac.comp.TransTypes.coerce 
(TransTypes.java:128)
         at com.sun.tools.javac.comp.TransTypes.retype 
(TransTypes.java:162)
         at com.sun.tools.javac.comp.TransTypes.visitApply 
(TransTypes.java:595)
         at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept 
(JCTree.java:1395)
         at com.sun.tools.javac.tree.TreeTranslator.translate 
(TreeTranslator.java:62)
         at com.sun.tools.javac.comp.TransTypes.translate 
(TransTypes.java:421)
         at com.sun.tools.javac.comp.TransTypes.visitVarDef 
(TransTypes.java:478)
         at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept 
(JCTree.java:803)
         at com.sun.tools.javac.tree.TreeTranslator.translate 
(TreeTranslator.java:62)
         at com.sun.tools.javac.tree.TreeTranslator.translate 
(TreeTranslator.java:74)
         at com.sun.tools.javac.tree.TreeTranslator.visitBlock 
(TreeTranslator.java:164)
         at com.sun.tools.javac.tree.JCTree$JCBlock.accept 
(JCTree.java:859)
         at com.sun.tools.javac.tree.TreeTranslator.translate 
(TreeTranslator.java:62)
         at com.sun.tools.javac.comp.TransTypes.translate 
(TransTypes.java:421)
         at com.sun.tools.javac.comp.TransTypes.visitMethodDef 
(TransTypes.java:455)
         ...


Regards,

Mark



From neal at gafter.com  Tue Jun 24 13:11:57 2008
From: neal at gafter.com (Neal Gafter)
Date: Tue, 24 Jun 2008 13:11:57 -0700
Subject: Compiler crash - NPE in Resolve.isAccessible
In-Reply-To: <9826C57D-DAC9-4988-907C-E45FCEC8CA84@twistedbanana.demon.co.uk>
References: <9826C57D-DAC9-4988-907C-E45FCEC8CA84@twistedbanana.demon.co.uk>
Message-ID: <15e8b9d20806241311v6fad08e7q122fb6ddca07f3a5@mail.gmail.com>

Mark-

Thanks for the report!  I'm a little surprised this is broken.  I'll
look at it when I resume development, which I expect will be within a
week or so.

Regards,
Neal

On Tue, Jun 24, 2008 at 12:57 PM, Mark Mahieu
<mark at twistedbanana.demon.co.uk> wrote:
> This class triggers a NullPointerException in the compiler:
>
>
> class PrivateCrash {
>
>        private interface Block {}
>
>        static ThreadLocal<Block> tl;
>
>        public static void main(String[] args) {
>
>                Object o = {=> Block b = tl.get(); };
>        }
> }
>
>
> java.lang.NullPointerException
>        at com.sun.tools.javac.comp.Resolve.isAccessible(Resolve.java:140)
>        at com.sun.tools.javac.comp.TransTypes.cast(TransTypes.java:111)
>        at com.sun.tools.javac.comp.TransTypes.coerce(TransTypes.java:128)
>        at com.sun.tools.javac.comp.TransTypes.retype(TransTypes.java:162)
>        at
> com.sun.tools.javac.comp.TransTypes.visitApply(TransTypes.java:595)
>        at
> com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1395)
>        at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:62)
>        at com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:421)
>        at
> com.sun.tools.javac.comp.TransTypes.visitVarDef(TransTypes.java:478)
>        at
> com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:803)
>        at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:62)
>        at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:74)
>        at
> com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:164)
>        at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:859)
>        at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:62)
>        at com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:421)
>        at
> com.sun.tools.javac.comp.TransTypes.visitMethodDef(TransTypes.java:455)
>        ...
>
>
> Regards,
>
> Mark
>
>


From mr at sun.com  Tue Jun 24 13:38:07 2008
From: mr at sun.com (Mark Reinhold)
Date: Tue, 24 Jun 2008 13:38:07 -0700
Subject: Fwd: Closures in openjdk 
In-Reply-To: mr@sun.com; Wed, 18 Jun 2008 09:59:19 PDT;
	<20080618165919.38F5B5BCB@eggemoggin.niobe.net> 
Message-ID: <20080624203807.33C6628BF@eggemoggin.niobe.net>

After looking into this further I now believe that you can forward-port
the changes you made to code you licensed under the JRL and publish them
under GPLv2.  This is possible solely because the exact same code is now
available under GPLv2 and you could simply license it from Sun under
GPLv2 and achieve the same result.

The resulting files should, of course, carry the usual OpenJDK GPLv2
legal notice at the top, rather than the original JRL notice.

As far as I can see, you need no "special dispensation" at this point in
order to publish your Closures prototype under GPLv2.

(As always, IANAL and this does not constitute legal advice.)

- Mark


From neal at gafter.com  Tue Jun 24 14:24:18 2008
From: neal at gafter.com (Neal Gafter)
Date: Tue, 24 Jun 2008 14:24:18 -0700
Subject: Fwd: Closures in openjdk
In-Reply-To: <20080624203807.33C6628BF@eggemoggin.niobe.net>
References: <20080618165919.38F5B5BCB@eggemoggin.niobe.net>
	<20080624203807.33C6628BF@eggemoggin.niobe.net>
Message-ID: <15e8b9d20806241424k42f665dbi8fa77744b1888a78@mail.gmail.com>

On Tue, Jun 24, 2008 at 1:38 PM, Mark Reinhold <mr at sun.com> wrote:

> After looking into this further I now believe that you can forward-port
> the changes you made to code you licensed under the JRL and publish them
> under GPLv2.  This is possible solely because the exact same code is now
> available under GPLv2 and you could simply license it from Sun under
> GPLv2 and achieve the same result.
>
> The resulting files should, of course, carry the usual OpenJDK GPLv2
> legal notice at the top, rather than the original JRL notice.
>
> As far as I can see, you need no "special dispensation" at this point in
> order to publish your Closures prototype under GPLv2.


Mark-

Thanks for following up.  The delta I sent has only GPLv2 licenses (no JRL
licenses), so I'm all set to push those changes after merging with the
latest.

(As always, IANAL and this does not constitute legal advice.)


For intellectual property matters I get my legal advice from Stuart Clark of
Carr and Ferrell LLP <http://www.carrferrell.com/attorneys_clark.html>.  :-)

Regards,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080624/a21e60ec/attachment.html 

From karmazilla at gmail.com  Tue Jun 24 14:48:54 2008
From: karmazilla at gmail.com (Christian Vest Hansen)
Date: Tue, 24 Jun 2008 23:48:54 +0200
Subject: Fwd: Closures in openjdk
In-Reply-To: <15e8b9d20806241424k42f665dbi8fa77744b1888a78@mail.gmail.com>
References: <20080618165919.38F5B5BCB@eggemoggin.niobe.net>
	<20080624203807.33C6628BF@eggemoggin.niobe.net>
	<15e8b9d20806241424k42f665dbi8fa77744b1888a78@mail.gmail.com>
Message-ID: <90622e530806241448o4063cebeqc2a0a4e801f7a51a@mail.gmail.com>

So... Neal is writing code again?


On 6/24/08, Neal Gafter <neal at gafter.com> wrote:
> On Tue, Jun 24, 2008 at 1:38 PM, Mark Reinhold <mr at sun.com> wrote:
>
> > After looking into this further I now believe that you can forward-port
> > the changes you made to code you licensed under the JRL and publish them
> > under GPLv2.  This is possible solely because the exact same code is now
> > available under GPLv2 and you could simply license it from Sun under
> > GPLv2 and achieve the same result.
> >
> > The resulting files should, of course, carry the usual OpenJDK GPLv2
> > legal notice at the top, rather than the original JRL notice.
> >
> > As far as I can see, you need no "special dispensation" at this point in
> > order to publish your Closures prototype under GPLv2.
>
>  Mark-
>
>  Thanks for following up.  The delta I sent has only GPLv2 licenses (no JRL
> licenses), so I'm all set to push those changes after merging with the
> latest.
>
> > (As always, IANAL and this does not constitute legal advice.)
>
> For intellectual property matters I get my legal advice from Stuart Clark of
> Carr and Ferrell LLP.  :-)
>
>  Regards,
>  Neal
>


-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.


From mark at twistedbanana.demon.co.uk  Wed Jun 25 02:07:35 2008
From: mark at twistedbanana.demon.co.uk (Mark Mahieu)
Date: Wed, 25 Jun 2008 10:07:35 +0100
Subject: Compiling call to 'for' method can fail
Message-ID: <6E243336-9D56-439C-BA7E-B40D08B76D8A@twistedbanana.demon.co.uk>

I guess this is likely to be a known 'to do' item, but just in case  
it isn't...

It seems that compiling a call to a method declared with the 'for'  
modifier only succeeds if that method is being compiled at the same  
time.  For example, given these two source files:


// foo/ForCaller.java

package foo;
import static foo.ForEver.*;

class ForCaller {
	public static void main(String[] args) {
		for ever() {}
	}
}


// foo/ForEver.java

package foo;

class ForEver {
	static for void ever({==>void} block) {}
}


Then this succeeds:

$ rm foo/*.class
$ $BGGA_HOME/bin/javac foo/ForCaller.java
$


But this doesn't:

$ rm foo/*.class
$ $BGGA_HOME/bin/javac foo/ForEver.java
$ $BGGA_HOME/bin/javac foo/ForCaller.java
foo/ForCaller.java:7: for may only be used on an invocation if the  
method was declared with the 'for' modifier
                 for ever() {}
                     ^
1 error
$


Regards,

Mark



From neal at gafter.com  Wed Jun 25 07:07:05 2008
From: neal at gafter.com (Neal Gafter)
Date: Wed, 25 Jun 2008 07:07:05 -0700
Subject: Compiling call to 'for' method can fail
In-Reply-To: <6E243336-9D56-439C-BA7E-B40D08B76D8A@twistedbanana.demon.co.uk>
References: <6E243336-9D56-439C-BA7E-B40D08B76D8A@twistedbanana.demon.co.uk>
Message-ID: <15e8b9d20806250707y7b8520ddrd407958ed6e0456c@mail.gmail.com>

Yes, this is on my TODO list.  I need to store a class file attribute for this.

Regards,
Neal

On Wed, Jun 25, 2008 at 2:07 AM, Mark Mahieu
<mark at twistedbanana.demon.co.uk> wrote:
> I guess this is likely to be a known 'to do' item, but just in case it
> isn't...
>
> It seems that compiling a call to a method declared with the 'for' modifier
> only succeeds if that method is being compiled at the same time.  For
> example, given these two source files:
>
>
> // foo/ForCaller.java
>
> package foo;
> import static foo.ForEver.*;
>
> class ForCaller {
>        public static void main(String[] args) {
>                for ever() {}
>        }
> }
>
>
> // foo/ForEver.java
>
> package foo;
>
> class ForEver {
>        static for void ever({==>void} block) {}
> }
>
>
> Then this succeeds:
>
> $ rm foo/*.class
> $ $BGGA_HOME/bin/javac foo/ForCaller.java
> $
>
>
> But this doesn't:
>
> $ rm foo/*.class
> $ $BGGA_HOME/bin/javac foo/ForEver.java
> $ $BGGA_HOME/bin/javac foo/ForCaller.java
> foo/ForCaller.java:7: for may only be used on an invocation if the method
> was declared with the 'for' modifier
>                for ever() {}
>                    ^
> 1 error
> $
>
>
> Regards,
>
> Mark
>
>


From mark at twistedbanana.demon.co.uk  Thu Jun 26 04:27:21 2008
From: mark at twistedbanana.demon.co.uk (Mark Mahieu)
Date: Thu, 26 Jun 2008 12:27:21 +0100
Subject: Method reference assignment compatibility
Message-ID: <A673662C-C7E4-4444-A2F9-2254FBB22F8A@twistedbanana.demon.co.uk>

Neal,

Given a method with the signature:

	void subscribe(Topic topic, {Message=>void} processor)

I might want to pass myPriorityQueue#offer(Message) as the second  
argument, but this isn't permitted since Queue<E>#offer(E) has a  
boolean rather than void result type.

Obviously I can get around this using a closure literal {Message msg  
=> myPriorityQueue.offer(msg);}, however given:

	final class Processor {
		// ...
		void process(Message msg) {
			//...
		}
	}

In Java 6, if I were to alter the process(Message) method to return a  
value, such as a boolean indicating success or failure of the  
operation, then I'd break binary compatibility but I think source  
compatibility would be preserved.

Under BGGA, if I had used a method reference myProcessor#process 
(Message) as the argument to the subscribe() method above, then this  
API change will have broken source compatibility.

So my question is: would it be problematic to allow a method  
reference with a non-void result type to be assignment compatible  
with an interface or function type with a void result type (all other  
conditions being satisfied)?


Regards,

Mark



From neal at gafter.com  Thu Jun 26 15:20:27 2008
From: neal at gafter.com (Neal Gafter)
Date: Thu, 26 Jun 2008 15:20:27 -0700
Subject: Method reference assignment compatibility
In-Reply-To: <A673662C-C7E4-4444-A2F9-2254FBB22F8A@twistedbanana.demon.co.uk>
References: <A673662C-C7E4-4444-A2F9-2254FBB22F8A@twistedbanana.demon.co.uk>
Message-ID: <15e8b9d20806261520v49ba8700xfa08b1794f5227b0@mail.gmail.com>

On Thu, Jun 26, 2008 at 4:27 AM, Mark Mahieu <mark at twistedbanana.demon.co.uk>
wrote:

> Neal,
>
> Given a method with the signature:
>
>        void subscribe(Topic topic, {Message=>void} processor)
>
> I might want to pass myPriorityQueue#offer(Message) as the second argument,
> but this isn't permitted since Queue<E>#offer(E) has a boolean rather than
> void result type.
>
> Obviously I can get around this using a closure literal {Message msg =>
> myPriorityQueue.offer(msg);}, however given:
>
>        final class Processor {
>                // ...
>                void process(Message msg) {
>                        //...
>                }
>        }
>
> In Java 6, if I were to alter the process(Message) method to return a
> value, such as a boolean indicating success or failure of the operation,
> then I'd break binary compatibility but I think source compatibility would
> be preserved.


No, this breaks source compatibility.  Another class might extend Processor
and implement an interface, and use the inherited process(Message) method as
an inherited overrider.


> Under BGGA, if I had used a method reference myProcessor#process(Message)
> as the argument to the subscribe() method above, then this API change will
> have broken source compatibility.
>
> So my question is: would it be problematic to allow a method reference with
> a non-void result type to be assignment compatible with an interface or
> function type with a void result type (all other conditions being
> satisfied)?


I don't really have strong feelings about this one way or another.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080626/fce5eb14/attachment.html