From david.lloyd at redhat.com Mon Oct 1 06:09:53 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 01 Oct 2012 08:09:53 -0500 Subject: Serialization stability and naming (and syntax) In-Reply-To: <1A0559B6-5F80-43B9-B155-BF97C5A17F16@oracle.com> References: <174C39C6-9033-4DEA-9B31-5FAD38274E00@oracle.com> <5068B50B.6080601@redhat.com> <1A0559B6-5F80-43B9-B155-BF97C5A17F16@oracle.com> Message-ID: <50699621.1040204@redhat.com> I agree it would be a shame. If there's a way that we can include non-capturing lambdas cleanly without making the exclusion of capturing lambdas awkward, then we should do it, but I have a feeling we won't be able to do that. In that case I'd rather lose non-capturing lambdas than have to come up with some way to deal with capturing lambdas. On 09/30/2012 04:46 PM, Brian Goetz wrote: > The set of non capturing lambdas similarly has little stabity problems. It would be a shame to exclude those -- and they will be common. > > Sent from my iPhone > > On Sep 30, 2012, at 2:09 PM, "David M. Lloyd" wrote: > >> On 09/30/2012 09:43 AM, Brian Goetz wrote: >>> A confounding factor with picking a serialization syntax is "does the syntax provide a place to put a name, or do we need to do something else for that?" >>> >>> The reality is that there is relatively little we can do to make serialized lambdas stable across recompilation. The desugared method name is one aspect of instability, but it is only one. This problem is worse than the "unstable class name" problem of inner classes, and I don't think we have the will to distort the design very much to make it all that much better. My conclusion is that being able to specify a stable name is only slightly less brittle than not being able to, which leads me to believe that we should not value a "name" slot very highly in picking a syntax. >> >> Why not consider limiting serializability to lambdas built from method references? I am in serious, serious doubt that any benefit derived from serializing capturing lambdas would outweigh the pain for users and implementors. We should not introduce any more of this type of instability than already exists in the serialization protocol due to inner classes. >> >>> >>> Example: order of capture. Suppose we have a lambda >>> x -> (capA < capB) ? x : 0; >>> >>> If this is refactored into >>> >>> x -> (capB >= capA) ? 0 : x; >>> >>> as your IDE will happily do for you, you've broken serialized instances. If the compiler picks a stable algorithm at all for assigning captured values to indexed slots, it will probably be something like "the order in which the captured vars appear in the body." >>> >>> >>> Example: capture arity change. This one is obvious; if you add or remove a captured variable, you change the arity of the desugared lambda body. >>> >>> >>> Example: captured type change. If we have: >>> >>> Collection c = ... >>> x -> c.contains(x); >>> >>> and change the type of the captured variable outside the lambda: >>> >>> List c = ... >>> x -> c.contains(x); >>> >>> this will change the signature of the desguared lambda body. >>> >>> >>> Example: compiler optimization >>> >>> Given: >>> >>> class X { >>> public final int x = 3; >>> >>> ... >>> y -> (y > x) ? y : 0; >>> } >>> >>> Ordinarily we translate this by capturing 'this' so we can refer to this.x; a smarter compiler could realize that we can constant-fold x into the lambda and make it noncapturing. Again, breaking serialized instances. >>> >>> >>> The bottom line is that there are so many ways that we can break eisting serialized instances -- even more than with inner classes. The target profile we set at the outset -- serialization works when you have bytecode-identical classes on both sides -- is really the only thing that is guaranteed to work. >>> >>> Eliminate one source of instability -- the name -- yields only a minor improvement. If we care about name stability, perhaps we should spend the effort on a better naming scheme than lambda$nnn, one that is less sensitive to small changes into the source code. >>> >>> >> >> >> -- >> - DML -- - DML From brian.goetz at oracle.com Mon Oct 1 07:02:57 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 1 Oct 2012 07:02:57 -0700 Subject: Serialization stability and naming (and syntax) In-Reply-To: <5068C294.9000504@cs.oswego.edu> References: <174C39C6-9033-4DEA-9B31-5FAD38274E00@oracle.com> <5068B50B.6080601@redhat.com> <5068C294.9000504@cs.oswego.edu> Message-ID: >> Why not consider limiting serializability to lambdas built from method >> references? > > Yes! I can't think of any reason not to do this. Its a good complexity-reducing idea, but I think its impractical. Users will expect, reasonably, for this to work: interface SerializablePredicate extends Predicate, Serializable { } SerializablePredicate p = e -> true; // serialize p Failing to have p be serializable here would definitely violate the principle of least surprise. So we cannot draw the line at "method refs OK, lambdas not". Similarly, trying to draw the line at "non capturing lambdas OK, capturing not" is similarly problematic; users won't even realize when they're capturing something. But, as long as we're satisfied with the serialization stability requirements that we discussed at the outset -- that it works as long as the bytecode is the same on both sides, and we're not trying to make heroic efforts beyond that, I think we're fine. And I think we've mostly concluded that the primary motivator for having a name for a lambda is not serialization, but toString. From brian.goetz at oracle.com Mon Oct 1 07:47:19 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 1 Oct 2012 07:47:19 -0700 Subject: Serialization opt-in syntax (again) In-Reply-To: <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> Message-ID: <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> We need to wrap this up. Does anyone have a *significant objection* to the syntax (cast to intersection type) suggested below? > Here is another option that we explored a while ago and initially turned our nose up at, but we are still willing to explore: using intersection types in a cast to target type, inspired by multiple type bounds in generics: > > Predicate ps = (Predicate & Serializable) x-> x.isEmpty(); > > The major downsides are: > - Verbose (have to repeat the target type) > - Another ad-hoc context where we allow intersection types, though offers some runway in the event we want to extend the use of intersection types in the future. > > It extends to inner class expressions in an OK manner: > > new Foo(blah) & Serializable { ... } > > Again, the cast syntax can apply to any intersection of types that meets the SAM-ness requirement, and the inner class syntax can be any arbitrary set of interfaces. > > > On Sep 28, 2012, at 11:48 PM, Brian Goetz wrote: > >> Bob is definitely right here that the semantics of this are closer to what we want than any of the others. While the proximate problem is "how do I make a serializable lambda", the way you make a class serializable in Java is (in part) to extend Serializable. So something that addresses the "how to I extend Serializable" question is much more in the spirit of how serialization works (for better or worse) than a special magic serialization syntax. >> >> >> On Sep 28, 2012, at 4:14 PM, Bob Lee wrote: >> >>> I like the semantics a lot! Maybe moving the "implements" decl to the right of the -> would address Kevin's concerns? Then it would read "lambda (->) implements ..." >>> >>> Bob >>> >>> On Fri, Sep 28, 2012 at 1:47 PM, Brian Goetz wrote: >>> I put all the candidate syntaxes so far in the JIRA issue for this, but a new one came to light this week that we kind of like. >>> >>> The problem is: let's say you have a SAM that is not serializable, but you want the instance to be, such as in: >>> >>> Runnable r = () -> { }; >>> >>> The problem is that we really want to specify multiple interfaces for the lambda, and as long as their intersection has only one abstract method, that should be OK. >>> >>> So, how about using the space between the closing paren and the arrow: >>> >>> Runnable r = () implements Serializable -> { ... } >>> >>> As a bonus, if we wanted to be explicit about all the implemented interfaces, this easily extends to: >>> >>> Object p = (String s) implements Predicate, Serializable -> { ... } >>> >>> >>> This also extends nicely to inner class creation expressions. Right now there is a limit of one named supertype. But this could be extended: >>> >>> Predicate p = new Predicate() implements Serializable { ... } >>> >>> In this case, there is no single-method restriction; you could implement Iterator and Runnable if you wanted: >>> >>> new Iterator() implements Runnable { ... } >>> >>> Note that none of this is serialization-specific; it is simply a way of being explicit about multiple supertypes in contexts there this was not previously allowed. >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121001/9c238e61/attachment-0001.html From david.lloyd at redhat.com Mon Oct 1 08:24:02 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 01 Oct 2012 10:24:02 -0500 Subject: Serialization stability and naming (and syntax) In-Reply-To: References: <174C39C6-9033-4DEA-9B31-5FAD38274E00@oracle.com> <5068B50B.6080601@redhat.com> <5068C294.9000504@cs.oswego.edu> Message-ID: <5069B592.3070600@redhat.com> On 10/01/2012 09:02 AM, Brian Goetz wrote: >>> Why not consider limiting serializability to lambdas built from method >>> references? >> >> Yes! I can't think of any reason not to do this. > > Its a good complexity-reducing idea, but I think its impractical. > > Users will expect, reasonably, for this to work: > > interface SerializablePredicate extends Predicate, Serializable { } > > SerializablePredicate p = e -> true; > > // serialize p > > Failing to have p be serializable here would definitely violate the principle of least surprise. So we cannot draw the line at "method refs OK, lambdas not". There is precedent for this kind of potentially surprising behavior. The java.lang.reflect.Proxy base class is Serializable, though not all proxies are indeed actually serializable. Non-capturing lambdas are really very proxy-like; I think it's perfectly reasonable for all lambda implementation classes to be serializable and defer that check to, say, the MethodHandle. I don't think the principle of least surprise is a good first principle. I think first must come "works correctly/predictably/consistently or doesn't work at all". I realize there will be surprises; this is unavoidable. I'd rather the surprise be "oh, I guess need to move this to a method" in response to a very clear error/warning during build or testing than even one "oh, my app worked in production for years and broke after this upgrade and I have absolutely no idea why". > Similarly, trying to draw the line at "non capturing lambdas OK, capturing not" is similarly problematic; users won't even realize when they're capturing something. I agree this is a problem. It would be nice if we could simply not have capturing lambdas at all, but I will never win that battle, even though implementation-wise it still seems hard to see a clear benefit of a capturing lambda over an inner class. > But, as long as we're satisfied with the serialization stability requirements that we discussed at the outset -- that it works as long as the bytecode is the same on both sides, and we're not trying to make heroic efforts beyond that, I think we're fine. I do not find this answer satisfactory; I think we will cases (especially in Java EE applications) where application upgrades will cause bizarre regressions that even experienced developers will miss because of this, even more so than inner classes due to the fact that we and others will no doubt be strongly pushing people to use these things in their code much more than anyone ever promoted inner classes. > And I think we've mostly concluded that the primary motivator for having a name for a lambda is not serialization, but toString. That's valid from the POV of a lambda implementer but I don't think typical application developers, who rely on serialization heavily whether we like it or not, will find that to be a great comfort in that logic. -- - DML From david.lloyd at redhat.com Mon Oct 1 08:47:29 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 01 Oct 2012 10:47:29 -0500 Subject: Serialization opt-in syntax (again) In-Reply-To: <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> Message-ID: <5069BB11.3020509@redhat.com> I like it, not so much as a solution for serializability but as a general tool and for the aforementioned "runway". On 10/01/2012 09:47 AM, Brian Goetz wrote: > We need to wrap this up. Does anyone have a *significant objection* to > the syntax (cast to intersection type) suggested below? > >> Here is another option that we explored a while ago and initially >> turned our nose up at, but we are still willing to explore: using >> intersection types in a cast to target type, inspired by multiple type >> bounds in generics: >> >> Predicate ps = (Predicate & Serializable) x-> >> x.isEmpty(); >> >> The major downsides are: >> - Verbose (have to repeat the target type) >> - Another ad-hoc context where we allow intersection types, though >> offers some runway in the event we want to extend the use of >> intersection types in the future. >> >> It extends to inner class expressions in an OK manner: >> >> new Foo(blah) & Serializable { ... } >> >> Again, the cast syntax can apply to any intersection of types that >> meets the SAM-ness requirement, and the inner class syntax can be any >> arbitrary set of interfaces. >> >> >> On Sep 28, 2012, at 11:48 PM, Brian Goetz wrote: >> >>> Bob is definitely right here that the semantics of this are closer to >>> what we want than any of the others. While the proximate problem is >>> "how do I make a serializable lambda", the way you make a class >>> serializable in Java is (in part) to extend Serializable. So >>> something that addresses the "how to I extend Serializable" question >>> is much more in the spirit of how serialization works (for better or >>> worse) than a special magic serialization syntax. >>> >>> >>> On Sep 28, 2012, at 4:14 PM, Bob Lee wrote: >>> >>>> I like the semantics a lot! Maybe moving the "implements" decl to >>>> the right of the -> would address Kevin's concerns? Then it would >>>> read "lambda (->) implements ..." >>>> >>>> Bob >>>> >>>> On Fri, Sep 28, 2012 at 1:47 PM, Brian Goetz >>> > wrote: >>>> >>>> I put all the candidate syntaxes so far in the JIRA issue for >>>> this, but a new one came to light this week that we kind of like. >>>> >>>> The problem is: let's say you have a SAM that is not >>>> serializable, but you want the instance to be, such as in: >>>> >>>> Runnable r = () -> { }; >>>> >>>> The problem is that we really want to specify multiple >>>> interfaces for the lambda, and as long as their intersection has >>>> only one abstract method, that should be OK. >>>> >>>> So, how about using the space between the closing paren and the >>>> arrow: >>>> >>>> Runnable r = () implements Serializable -> { ... } >>>> >>>> As a bonus, if we wanted to be explicit about all the >>>> implemented interfaces, this easily extends to: >>>> >>>> Object p = (String s) implements Predicate, >>>> Serializable -> { ... } >>>> >>>> >>>> This also extends nicely to inner class creation expressions. >>>> Right now there is a limit of one named supertype. But this >>>> could be extended: >>>> >>>> Predicate p = new Predicate() implements >>>> Serializable { ... } >>>> >>>> In this case, there is no single-method restriction; you could >>>> implement Iterator and Runnable if you wanted: >>>> >>>> new Iterator() implements Runnable { ... } >>>> >>>> Note that none of this is serialization-specific; it is simply a >>>> way of being explicit about multiple supertypes in contexts >>>> there this was not previously allowed. >>>> >>>> >>> >> > -- - DML From kevinb at google.com Mon Oct 1 08:57:04 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Mon, 1 Oct 2012 08:57:04 -0700 Subject: Serialization opt-in syntax (again) In-Reply-To: <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> Message-ID: (Meta-point: our discussion keeps bouncing back and forth between email and the issue log; what's the right way we're supposed to be doing this?) I'm sorry to say it, but I for one would still be shocked if that's really the best we can do. First, I'm not nearly as convinced as others here that there's a big advantage in a general solution that applies to any desired interface types. Serialization really is special. If it weren't for serialization we wouldn't even be worrying about this multi-interface problem at all. It just wouldn't rate on our top 20 list of concerns. But serialization is what it is, so we need to jam an extra interface type in -- but that's really not *all* that is happening. There is Special Magic you get by asking your lambda to be serializable (in whatever manner we provide), that's even beyond whatever Special Magic happens for declaring a regular class to implement Serializable. Special magic requiring special notation is not a terrible idea. I also don't see much benefit to our solution here generalizing to anonymous classes. If it does, fine, but helping anonymous classes a little just doesn't *matter* that much, so let's not treat that as more of an advantage than it is. In other words, I just think it's completely fair to address the serialization-for-lambdas issue specifically, head on, and not care *too* much about how it generalizes. So back to the proposed alternatives. I've expressed support for a minimally invasive syntax like (x) ~> x.y(). While that might not be perfect, compare the need for zero (maybe one) extra characters with the need, in the example given here, to add a whopping *thirty-five* extra characters. That is no small difference in verbosity. Also, as we've already found with Map> map = new HashMap>(), the need to redundantly repeat generic type information twice on the same line where the two have no valid reason to ever be different ... is a real drag. The criticisms of a special syntax like ~> that I have seen here: * "seems too clever" -- I'll admit, having the serialization concern intrude all the way into the language syntax itself is not awesome * can be visually overlooked, like 4321 vs 432l. Yes, but it seems like there's a limit on just how much pain and suffering that confusing can really cause. Meant something to be serializable that wasn't? Okay, change it. Problem solved? * doesn't generalize to anonymous classes, other interface types -- I covered why I don't put much weight on this up above * doesn't do anything for method references -- hmm, that is a bit of a problem, right? I also don't think I would completely rule out the idea of the special keyword or magic "operator" (Predicate p = serializable (x) -> x.isEmpty(), Predicate p = serializable String#isEmpty). I don't like that much, but that's what ALL the proposals have in common... not a single one of them is likable imho. And AFAIK, having all lambdas be serializable and having no lambdas be serializable are still not considered viable. So we're really in a tough spot. On Mon, Oct 1, 2012 at 7:47 AM, Brian Goetz wrote: > We need to wrap this up. Does anyone have a *significant objection* to > the syntax (cast to intersection type) suggested below? > > Here is another option that we explored a while ago and initially turned > our nose up at, but we are still willing to explore: using intersection > types in a cast to target type, inspired by multiple type bounds in > generics: > > Predicate ps = (Predicate & Serializable) x-> > x.isEmpty(); > > The major downsides are: > - Verbose (have to repeat the target type) > - Another ad-hoc context where we allow intersection types, though offers > some runway in the event we want to extend the use of intersection types in > the future. > > It extends to inner class expressions in an OK manner: > > new Foo(blah) & Serializable { ... } > > Again, the cast syntax can apply to any intersection of types that meets > the SAM-ness requirement, and the inner class syntax can be any arbitrary > set of interfaces. > > > On Sep 28, 2012, at 11:48 PM, Brian Goetz wrote: > > Bob is definitely right here that the semantics of this are closer to what > we want than any of the others. While the proximate problem is "how do I > make a serializable lambda", the way you make a class serializable in Java > is (in part) to extend Serializable. So something that addresses the "how > to I extend Serializable" question is much more in the spirit of how > serialization works (for better or worse) than a special magic > serialization syntax. > > > On Sep 28, 2012, at 4:14 PM, Bob Lee wrote: > > I like the semantics a lot! Maybe moving the "implements" decl to the > right of the -> would address Kevin's concerns? Then it would read "lambda > (->) implements ..." > > Bob > > On Fri, Sep 28, 2012 at 1:47 PM, Brian Goetz wrote: > >> I put all the candidate syntaxes so far in the JIRA issue for this, but a >> new one came to light this week that we kind of like. >> >> The problem is: let's say you have a SAM that is not serializable, but >> you want the instance to be, such as in: >> >> Runnable r = () -> { }; >> >> The problem is that we really want to specify multiple interfaces for the >> lambda, and as long as their intersection has only one abstract method, >> that should be OK. >> >> So, how about using the space between the closing paren and the arrow: >> >> Runnable r = () implements Serializable -> { ... } >> >> As a bonus, if we wanted to be explicit about all the implemented >> interfaces, this easily extends to: >> >> Object p = (String s) implements Predicate, Serializable -> { >> ... } >> >> >> This also extends nicely to inner class creation expressions. Right now >> there is a limit of one named supertype. But this could be extended: >> >> Predicate p = new Predicate() implements Serializable { >> ... } >> >> In this case, there is no single-method restriction; you could implement >> Iterator and Runnable if you wanted: >> >> new Iterator() implements Runnable { ... } >> >> Note that none of this is serialization-specific; it is simply a way of >> being explicit about multiple supertypes in contexts there this was not >> previously allowed. >> >> > > > > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121001/116efaef/attachment.html From kevinb at google.com Mon Oct 1 09:11:49 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Mon, 1 Oct 2012 09:11:49 -0700 Subject: Serialization opt-in syntax (again) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> Message-ID: On Mon, Oct 1, 2012 at 8:57 AM, Kevin Bourrillion wrote: And AFAIK, having all lambdas be serializable and having no lambdas be > serializable are still not considered viable. So we're really in a tough > spot. > Actually, given the horrors we're discussing here, let's be sure about this. If all lambdas were serializable it would be a get out of jail free card for this design conundrum, so I must ask: are we all satisfied that we have accurately quantified just *how* bad it would be performance-wise? If so: how bad? -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121001/ff83e123/attachment-0001.html From Vladimir.Zakharov at gs.com Mon Oct 1 13:10:51 2012 From: Vladimir.Zakharov at gs.com (Zakharov, Vladimir) Date: Mon, 1 Oct 2012 16:10:51 -0400 Subject: Serialization opt-in syntax (again) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> Message-ID: Excellent question. What is the cost and under what circumstances will it be incurred? I suspect, based on our experience with GS Collections, where all interfaces extend Serializable (including Predicates, Functions, etc.), the practical cost would be negligible. The Goldman Sachs Group, Inc. All rights reserved. See http://www.gs.com/disclaimer/global_email for important risk disclosures, conflicts of interest and other terms and conditions relating to this e-mail and your reliance on information contained in it. This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. From: lambda-spec-experts-bounces at openjdk.java.net [mailto:lambda-spec-experts-bounces at openjdk.java.net] On Behalf Of Kevin Bourrillion Sent: Monday, October 01, 2012 12:12 PM To: Brian Goetz Cc: lambda-spec-experts at openjdk.java.net Subject: Re: Serialization opt-in syntax (again) On Mon, Oct 1, 2012 at 8:57 AM, Kevin Bourrillion > wrote: And AFAIK, having all lambdas be serializable and having no lambdas be serializable are still not considered viable. So we're really in a tough spot. Actually, given the horrors we're discussing here, let's be sure about this. If all lambdas were serializable it would be a get out of jail free card for this design conundrum, so I must ask: are we all satisfied that we have accurately quantified just how bad it would be performance-wise? If so: how bad? -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121001/7ab59b3c/attachment.html From brian.goetz at oracle.com Mon Oct 1 21:26:27 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 1 Oct 2012 21:26:27 -0700 Subject: Serialization opt-in syntax (again) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> Message-ID: <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> Unfortunately I do not believe the cost is negligible. One of the downsides of our translation approach is that serialization overhead is higher. For inner classes, it is just a matter of tagging the class as serializable, which is negligible. But for our approach, we would have to carry more information in the lambda itself, and the "must be serializable" constraint also rules out several possible metafactory approaches. Also, in our approach, serializable lambdas require a lot of additional static footprint in the capturing class to deal with the potential security issues. Also, I believe that serialization really needs to be somethign users opt explicitly into. Foisting transparent serializaxbility on users seems rude. Overall I do not see this as a realistic option. On Oct 1, 2012, at 1:10 PM, Zakharov, Vladimir wrote: > Excellent question. What is the cost and under what circumstances will it be incurred? I suspect, based on our experience with GS Collections, where all interfaces extend Serializable (including Predicates, Functions, etc.), the practical cost would be negligible. > > The Goldman Sachs Group, Inc. All rights reserved. > See http://www.gs.com/disclaimer/global_email for important risk disclosures, conflicts of interest and other terms and conditions relating to this e-mail and your reliance on information contained in it. This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. > > From: lambda-spec-experts-bounces at openjdk.java.net [mailto:lambda-spec-experts-bounces at openjdk.java.net] On Behalf OfKevin Bourrillion > Sent: Monday, October 01, 2012 12:12 PM > To: Brian Goetz > Cc: lambda-spec-experts at openjdk.java.net > Subject: Re: Serialization opt-in syntax (again) > > On Mon, Oct 1, 2012 at 8:57 AM, Kevin Bourrillion wrote: > > And AFAIK, having all lambdas be serializable and having no lambdas be serializable are still not considered viable. So we're really in a tough spot. > > Actually, given the horrors we're discussing here, let's be sure about this. If all lambdas were serializable it would be a get out of jail free card for this design conundrum, so I must ask: are we all satisfied that we have accurately quantified just how bad it would be performance-wise? If so: how bad? > > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121001/f4f39c5d/attachment-0001.html From forax at univ-mlv.fr Tue Oct 2 01:55:58 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 02 Oct 2012 10:55:58 +0200 Subject: Serialization opt-in syntax (again) In-Reply-To: <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> Message-ID: <506AAC1E.5020507@univ-mlv.fr> On 10/02/2012 06:26 AM, Brian Goetz wrote: > Unfortunately I do not believe the cost is negligible. I think the opposite. > One of the downsides of our translation approach is that > serialization overhead is higher. For inner classes, it is just a > matter of tagging the class as serializable, which is negligible. But > for our approach, we would have to carry more information in the > lambda itself, and the "must be serializable" constraint also rules > out several possible metafactory approaches. ?? You're talking about the method handle approach, as I already says, being serailizable implies two things. You need to be able to have a runtime description of the lambda, this object is created once for all lambdas, so it has a small footprint cost but not more than the additional footprint cost we have because we use a metafactory (the bootstrap method + callsite initialization has an overhead compare to a classical Java call). Then you need to access to the bounded values, the value copied from the current scope, there is two ways to deal with them, either we stored them as a reference in the SAM proxy and then we teach the VM to inline the value when the method is called (John Rose has just landed a patch for that in Hotspot) or you can bound the parameter to the method handle and we need to crack the method handle to get the values back when you want to serialize (again, this is not hard to do that with the current implementation). Whatever the way you choose, there is no runtime cost at all when you call the lambda if there is no bound values or if the VM is able to see that the lambda doesn't escape (if the VM inlines together the site when you create the lambda and the site you call the lambda. If the lambda escape, it means you store it in a field somewhere, so the users use the stream API ou Doug's API by example, and we know that these APIs creates objects too so the overhead of serailizable lambdas will not be that visible (my gut feeling is that you will not see the overhead at all). > Also, in our approach, serializable lambdas require a lot of > additional static footprint in the capturing class to deal with the > potential security issues. Not a lot, and this static values are stored in an object once. > Also, I believe that serialization really needs to be somethign users > opt explicitly into. Foisting transparent serializaxbility on users > seems rude. It just works, is it that rude ? And if users don't want a serializable lambdas they can still use inner classes. > > Overall I do not see this as a realistic option. I think you're wrong. R?mi > > On Oct 1, 2012, at 1:10 PM, Zakharov, Vladimir wrote: > >> Excellent question. What is the cost and under what circumstances >> will it be incurred? I suspect, based on our experience with GS >> Collections, where all interfaces extend Serializable (including >> Predicates, Functions, etc.), the practical cost would be negligible. >> *The Goldman Sachs Group, Inc. All rights reserved*. >> Seehttp://www.gs.com/disclaimer/global_emailfor important risk >> disclosures, conflicts of interest and other terms and conditions >> relating to this e-mail and your reliance on information contained in >> it. This message may contain confidential or privileged >> information. If you are not the intended recipient, please advise us >> immediately and delete this message. >> Seehttp://www.gs.com/disclaimer/emailfor further information on >> confidentiality and the risks of non-secure electronic communication. >> If you cannot access these links, please notify us by reply message >> and we will send the contents to you. >> *From:*lambda-spec-experts-bounces at openjdk.java.net >> >> [mailto:lambda-spec-experts-bounces at openjdk.java.net]*On Behalf >> Of*Kevin Bourrillion >> *Sent:*Monday, October 01, 2012 12:12 PM >> *To:*Brian Goetz >> *Cc:*lambda-spec-experts at openjdk.java.net >> >> *Subject:*Re: Serialization opt-in syntax (again) >> On Mon, Oct 1, 2012 at 8:57 AM, Kevin Bourrillion > > wrote: >> >> And AFAIK, having all lambdas be serializable and having no >> lambdas be serializable are still not considered viable. So we're >> really in a tough spot. >> >> Actually, given the horrors we're discussing here, let's be sure >> about this. If all lambdas were serializable it would be a get out >> of jail free card for this design conundrum, so I must ask: are we >> all satisfied that we have accurately quantified just/how/ bad it >> would be performance-wise? If so: how bad? >> -- >> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com >> > From brian.goetz at oracle.com Sun Oct 7 09:30:08 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 07 Oct 2012 12:30:08 -0400 Subject: Transitioning JSR-335 to JCP 2.8 -- EG approval needed In-Reply-To: <506496B0.5000109@oracle.com> References: <50636072.5040407@oracle.com> <506496B0.5000109@oracle.com> Message-ID: <5071AE10.10602@oracle.com> So far we have Yes votes from: Oracle, IBM, Red Hat, JetBrains, Goldman Sachs, Doug Lea, Remi Forax, Sam Pullara Waiting for votes from: Bob Lee From andrey.breslav at jetbrains.com Sun Oct 7 11:44:05 2012 From: andrey.breslav at jetbrains.com (Andrey Breslav) Date: Sun, 7 Oct 2012 22:44:05 +0400 Subject: Serialization stability and naming (and syntax) In-Reply-To: <5069B592.3070600@redhat.com> References: <174C39C6-9033-4DEA-9B31-5FAD38274E00@oracle.com> <5068B50B.6080601@redhat.com> <5068C294.9000504@cs.oswego.edu> <5069B592.3070600@redhat.com> Message-ID: <5AF38F6C-9B93-4BEE-9AD1-0B2406ECA04E@jetbrains.com> I would like to point out one thing that somehow keeps escaping our discussions of this matter. Although for some people serialization is the biggest concern here, for a lot more people a much bigger concern is hot-swapping, where name stability is very important as well. In my mind, this requires us to reconsider the arguments for having/not having stable names/signatures where we could have that. -- Andrey Breslav http://jetbrains.com Develop with pleasure! From andrey.breslav at jetbrains.com Sun Oct 7 12:17:54 2012 From: andrey.breslav at jetbrains.com (Andrey Breslav) Date: Sun, 7 Oct 2012 23:17:54 +0400 Subject: Serialization opt-in syntax (again) In-Reply-To: <506AAC1E.5020507@univ-mlv.fr> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> Message-ID: <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> A few thoughts: 1. Why I am against the ~> syntax. Serialization is one of the more obscure features of Java. This makes it much more important that to make related syntax self-explanatory than for more ubiquitous features. "~>" is about the least self-explanatory syntax we could possibly have. 2. Why I'd prefer something like (a) "() -> serializable expr" to (b) "() implements Serializable -> ?" (a) suggests that something is serializable here, as opposed to (b) that suggests that something implements java.io.Serializable. It's a huge difference. I'd prefer lambdas eventually evolve into a relatively independent concept that would make "lambda implements interface" a leak in the abstraction. I'd say those annotation-based options look most adequate to me. (In the issue tracker there is some consensus of two more people about this, so I'm the third) 3. I agree with Kevin that we shouldn't say "this thing is better because now a lambda/anonymous class can implement more than one interface", because this is not really an issue. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121007/c94f3bac/attachment.html From brian.goetz at oracle.com Sun Oct 7 20:13:32 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 07 Oct 2012 23:13:32 -0400 Subject: Serialization opt-in syntax (again) In-Reply-To: <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> Message-ID: <507244DC.4080902@oracle.com> > 1. Why I am *against* the *~>* syntax. > > Serialization is one of the more obscure features of Java. This makes it > much more important that to make related syntax *self-explanatory* than > for more ubiquitous features. > "~>" is about the least self-explanatory syntax we could possibly have. Totally agreed. ~> is off the table. > I'd say those *annotation-based options look most adequate to me*. > (In the issue tracker there is some consensus of two more people about > this, so I'm the third) Yeah, its pretty attractive -- from the end-user perspective. Except that after reviewing the options I just don't think this is going to be acceptable to us. While it doesn't create much new syntax, it does cross some big lines we have spent eight years deliberately not crossing: - annotations don't affect language semantics - annotations don't affect bytecode generation - can't annotate expressions While there are lots of people who want annotations to be something they are not, what they are is deliberate and I'm not looking for an opportunity to make that radical change. (Also, the work of creating new targets like "lambda" for annotations is far more significant than some of the other approaches, and we're very short on time.) What annotations are and aren't is already a confusing and contentious enough topic; this would further blur the boundaries in ways that might be convenient in the short term but problematic in the long term. So I think we're going to have to take annotations mostly off the table, too. The approach I have come to prefer is a target-type approach, because this is most consistent with how lambda translation is driven now, and most consistent with how objects become serializable in other situations (by extending Serializable). Of the target-type options, the intersection type cast seems the obvious choice because (a) the syntax already has precedent and (b) we may well want to expand the set of places where intersection types are allowed in the future, so it makes more sense to extend an existing concept that we might extend further anyway than create a new dead-end special-case concept. There are some others (notably keyword) that are not outright unacceptable, but still seem less desirable than just using the (admittedly verbose) target type approach. So, let's go back to where I set the bar earlier this week: aside from "I like XYZ better", are there any reasons why the intersection type cast should be unacceptable? From kevinb at google.com Sun Oct 7 23:33:23 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Sun, 7 Oct 2012 23:33:23 -0700 Subject: Serialization opt-in syntax (again) In-Reply-To: <507244DC.4080902@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> Message-ID: Did we rule out Predicate p = (& Serializable) (s) -> s.isEmpty(); methodExpectingPredicateOfString((& Serializable) String#isEmpty); ? I realize it's more language-innovating than the full conjunctive "cast", but it saves all that redundant text... On Sun, Oct 7, 2012 at 8:13 PM, Brian Goetz wrote: > 1. Why I am *against* the *~>* syntax. >> >> >> Serialization is one of the more obscure features of Java. This makes it >> much more important that to make related syntax *self-explanatory* than >> >> for more ubiquitous features. >> "~>" is about the least self-explanatory syntax we could possibly have. >> > > Totally agreed. ~> is off the table. > > I'd say those *annotation-based options look most adequate to me*. >> >> (In the issue tracker there is some consensus of two more people about >> this, so I'm the third) >> > > Yeah, its pretty attractive -- from the end-user perspective. Except that > after reviewing the options I just don't think this is going to be > acceptable to us. While it doesn't create much new syntax, it does cross > some big lines we have spent eight years deliberately not crossing: > - annotations don't affect language semantics > - annotations don't affect bytecode generation > - can't annotate expressions > > While there are lots of people who want annotations to be something they > are not, what they are is deliberate and I'm not looking for an opportunity > to make that radical change. (Also, the work of creating new targets like > "lambda" for annotations is far more significant than some of the other > approaches, and we're very short on time.) What annotations are and aren't > is already a confusing and contentious enough topic; this would further > blur the boundaries in ways that might be convenient in the short term but > problematic in the long term. > > So I think we're going to have to take annotations mostly off the table, > too. > > The approach I have come to prefer is a target-type approach, because this > is most consistent with how lambda translation is driven now, and most > consistent with how objects become serializable in other situations (by > extending Serializable). Of the target-type options, the intersection type > cast seems the obvious choice because (a) the syntax already has precedent > and (b) we may well want to expand the set of places where intersection > types are allowed in the future, so it makes more sense to extend an > existing concept that we might extend further anyway than create a new > dead-end special-case concept. > > There are some others (notably keyword) that are not outright > unacceptable, but still seem less desirable than just using the (admittedly > verbose) target type approach. > > So, let's go back to where I set the bar earlier this week: aside from "I > like XYZ better", are there any reasons why the intersection type cast > should be unacceptable? > > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121007/bf206609/attachment.html From andrey.breslav at jetbrains.com Mon Oct 8 01:56:01 2012 From: andrey.breslav at jetbrains.com (Andrey Breslav) Date: Mon, 8 Oct 2012 12:56:01 +0400 Subject: Serialization opt-in syntax (again) In-Reply-To: <507244DC.4080902@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> Message-ID: <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> > So, let's go back to where I set the bar earlier this week: aside from "I like XYZ better", are there any reasons why the intersection type cast should be unacceptable? I see only two problems there: * Allowing this kind of cast only on lambdas, which is ugly, but I'm OK with it. * Verbosity: it's hard for me to asses how bad it is as I don't have enough contact with code relying on serialization of behavior. But judging by what concerns Kevin, looks like it may be problematic. I imagine that remembering the name of the target type would be bad enough, and if it has generic parameters, it is even worse. Note: The IDE (if one uses it, which is frequently not the case in Google, AFAIK) can help you both write the cast and hide it... -- Andrey Breslav http://jetbrains.com Develop with pleasure! From david.lloyd at redhat.com Mon Oct 8 06:35:27 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 08 Oct 2012 08:35:27 -0500 Subject: Serialization opt-in syntax (again) In-Reply-To: <507244DC.4080902@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> Message-ID: <5072D69F.9030000@redhat.com> On 10/07/2012 10:13 PM, Brian Goetz wrote: >> 1. Why I am *against* the *~>* syntax. >> >> Serialization is one of the more obscure features of Java. This makes it >> much more important that to make related syntax *self-explanatory* than >> for more ubiquitous features. >> "~>" is about the least self-explanatory syntax we could possibly have. > > Totally agreed. ~> is off the table. > >> I'd say those *annotation-based options look most adequate to me*. >> (In the issue tracker there is some consensus of two more people about >> this, so I'm the third) >[...] > So I think we're going to have to take annotations mostly off the table, > too. > [...] > So, let's go back to where I set the bar earlier this week: aside from > "I like XYZ better", are there any reasons why the intersection type > cast should be unacceptable? Well, they don't really solve the problem of making serialization correct; they accept as given that it's OK for anonymous and (worse yet) capturing lambdas to be serialized with the expectation that it'll just be flat-out wrong if you change the source in any way, which is something I absolutely do not concede and which I firmly believe will bite us (where "us"=="Java EE vendors"... and RMI users, and JPA users, and just about any of the hundreds of widely-used serialization-based technologies out there). That said, and as I also said before, I like the general idea anyway; I think it could be pretty handy (especially if applied to anonymous classes), but not for solving the problem of serializability. -- - DML From brian.goetz at oracle.com Mon Oct 8 08:20:35 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 08 Oct 2012 11:20:35 -0400 Subject: Serialization opt-in syntax (again) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> Message-ID: <5072EF43.6000400@oracle.com> > Did we rule out > > Predicate p = (& Serializable) (s) -> s.isEmpty(); > methodExpectingPredicateOfString((& Serializable) String#isEmpty); > > ? I realize it's more language-innovating than the full conjunctive > "cast", but it saves all that redundant text... No, not ruled out. From brian.goetz at oracle.com Mon Oct 8 08:24:01 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 08 Oct 2012 11:24:01 -0400 Subject: Serialization opt-in syntax (again) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> Message-ID: <5072F011.8040800@oracle.com> BTW, if we did this, we would have to do BOTH this and the full intersection type. Because, otherwise you would lose the ability to use a target-type cast to both provide a target type (if the compiler can't infer it) and provide serializability. In which case the (&Serializable) becomes a shorthand for (TargetType&Serializable). (And, if we're going to do support such a shorthand, I prefer to have it be something that works in more contexts than just serialization.) On 10/8/2012 2:33 AM, Kevin Bourrillion wrote: > Did we rule out > > Predicate p = (& Serializable) (s) -> s.isEmpty(); > methodExpectingPredicateOfString((& Serializable) String#isEmpty); > > ? I realize it's more language-innovating than the full conjunctive > "cast", but it saves all that redundant text... > > > > On Sun, Oct 7, 2012 at 8:13 PM, Brian Goetz > wrote: > > 1. Why I am *against* the *~>* syntax. > > > Serialization is one of the more obscure features of Java. This > makes it > much more important that to make related syntax > *self-explanatory* than > > for more ubiquitous features. > "~>" is about the least self-explanatory syntax we could > possibly have. > > > Totally agreed. ~> is off the table. > > I'd say those *annotation-based options look most adequate to me*. > > (In the issue tracker there is some consensus of two more people > about > this, so I'm the third) > > > Yeah, its pretty attractive -- from the end-user perspective. > Except that after reviewing the options I just don't think this is > going to be acceptable to us. While it doesn't create much new > syntax, it does cross some big lines we have spent eight years > deliberately not crossing: > - annotations don't affect language semantics > - annotations don't affect bytecode generation > - can't annotate expressions > > While there are lots of people who want annotations to be something > they are not, what they are is deliberate and I'm not looking for an > opportunity to make that radical change. (Also, the work of > creating new targets like "lambda" for annotations is far more > significant than some of the other approaches, and we're very short > on time.) What annotations are and aren't is already a confusing > and contentious enough topic; this would further blur the boundaries > in ways that might be convenient in the short term but problematic > in the long term. > > So I think we're going to have to take annotations mostly off the > table, too. > > The approach I have come to prefer is a target-type approach, > because this is most consistent with how lambda translation is > driven now, and most consistent with how objects become serializable > in other situations (by extending Serializable). Of the target-type > options, the intersection type cast seems the obvious choice because > (a) the syntax already has precedent and (b) we may well want to > expand the set of places where intersection types are allowed in the > future, so it makes more sense to extend an existing concept that we > might extend further anyway than create a new dead-end special-case > concept. > > There are some others (notably keyword) that are not outright > unacceptable, but still seem less desirable than just using the > (admittedly verbose) target type approach. > > So, let's go back to where I set the bar earlier this week: aside > from "I like XYZ better", are there any reasons why the intersection > type cast should be unacceptable? > > > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com > > From brian.goetz at oracle.com Mon Oct 8 08:39:26 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 08 Oct 2012 11:39:26 -0400 Subject: Serialization opt-in syntax (again) In-Reply-To: <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> Message-ID: <5072F3AE.8000007@oracle.com> Also, let's compare the verbosity problem to the status quo: declaring a *named* (not even anonymous) class, with a constructor, serialVersionUID field, etc. (Predicate&Serializable) may be verbose, but its *nothing* compared to what people would have to do in the absence of a use-site lambda serialization opt-in (and we're rapidly converging on that being the alternative.) On 10/8/2012 4:56 AM, Andrey Breslav wrote: > >> So, let's go back to where I set the bar earlier this week: aside from "I like XYZ better", are there any reasons why the intersection type cast should be unacceptable? > I see only two problems there: > > * Allowing this kind of cast only on lambdas, which is ugly, but I'm OK with it. > > * Verbosity: it's hard for me to asses how bad it is as I don't have enough contact with code relying on serialization of behavior. But judging by what concerns Kevin, looks like it may be problematic. I imagine that remembering the name of the target type would be bad enough, and if it has generic parameters, it is even worse. > > Note: The IDE (if one uses it, which is frequently not the case in Google, AFAIK) can help you both write the cast and hide it... > > -- > Andrey Breslav > http://jetbrains.com > Develop with pleasure! > > From brian.goetz at oracle.com Mon Oct 8 08:45:12 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 08 Oct 2012 11:45:12 -0400 Subject: Serialization stability (was: syntax) In-Reply-To: <5072D69F.9030000@redhat.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <5072D69F.9030000@redhat.com> Message-ID: <5072F508.7020705@oracle.com> > Well, they don't really solve the problem of making serialization > correct; they accept as given that it's OK for anonymous and (worse yet) > capturing lambdas to be serialized with the expectation that it'll just > be flat-out wrong if you change the source in any way, which is > something I absolutely do not concede and which I firmly believe will > bite us (where "us"=="Java EE vendors"... and RMI users, and JPA users, > and just about any of the hundreds of widely-used serialization-based > technologies out there). I think the correctness you seek is just inachievable. Even with named classes, serialization has all sorts of limits and gotchas. With inner classes, people have learned that you can use inner classes with serialization when you have identical bytecode on both sides of the pipe, and can't otherwise. Its imperfect, but it seems a reasonable bar to say "no worse than inner classes". I get that you would like to set a higher bar -- and I'm open to seeing what we can do to meet a higher bar. But first we should meet the bar we have, and we're stuck there. From brian.goetz at oracle.com Mon Oct 8 09:04:16 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 08 Oct 2012 12:04:16 -0400 Subject: Serialization opt-in syntax (again) In-Reply-To: <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> Message-ID: <5072F980.6030004@oracle.com> > I see only two problems there: > > * Allowing this kind of cast only on lambdas, which is ugly, but I'm OK with it. I don't even think that this is actually the restriction. Yes, it affects translation of lambdas, but would also work in cases where we currently already allow intersection types: foo(T t) { ... } ... Object o = makeXAndY(); foo((X&Y) o); In fact, the cast to X&Y fills in a current language hole, since there's no way today to say "I *know* this is an X&Y, trust me" We just would not be able to call foo() without knowing the name of the class. Admittedly this is a rare situation and has not been a significant problem so far and is clearly not the goal of this effort. But, I do believe it provides a good example why, in the absence of an "obviously good" ad-hoc syntax, we should lean harder on extending existing concepts rather than inventing yet new ones. From kevinb at google.com Mon Oct 8 09:09:33 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Mon, 8 Oct 2012 09:09:33 -0700 Subject: Serialization opt-in syntax (again) In-Reply-To: <5072F980.6030004@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> <5072F980.6030004@oracle.com> Message-ID: I agree with all the points in your last flood of responses, Brian. I'm ready to give up fighting against (Foo & Serializable), and we should move toward finalizing that decision, but also (separately?) still evaluate whether it's worth offering the (& Serializable) shorthand as well. The shorthand has benefits similar to the Java 7 "diamond", though I must concede the situation only comes up a tiny fraction as often. On Mon, Oct 8, 2012 at 9:04 AM, Brian Goetz wrote: > I see only two problems there: >> >> * Allowing this kind of cast only on lambdas, which is ugly, but I'm OK >> with it. >> > > I don't even think that this is actually the restriction. Yes, it affects > translation of lambdas, but would also work in cases where we currently > already allow intersection types: > > foo(T t) { ... } > ... > Object o = makeXAndY(); > foo((X&Y) o); > > In fact, the cast to X&Y fills in a current language hole, since there's > no way today to say "I *know* this is an X&Y, trust me" We just would not > be able to call foo() without knowing the name of the class. > > Admittedly this is a rare situation and has not been a significant problem > so far and is clearly not the goal of this effort. But, I do believe it > provides a good example why, in the absence of an "obviously good" ad-hoc > syntax, we should lean harder on extending existing concepts rather than > inventing yet new ones. > > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121008/cac6f48b/attachment.html From brian.goetz at oracle.com Mon Oct 8 09:20:31 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 08 Oct 2012 12:20:31 -0400 Subject: Serialization opt-in syntax (again) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> <5072F980.6030004@oracle.com> Message-ID: <5072FD4F.5030903@oracle.com> > still evaluate whether it's worth offering the (& Serializable) > shorthand as well. The shorthand has benefits similar to the Java 7 > "diamond", though I must concede the situation only comes up a tiny > fraction as often. I agree that it is worth considering such. But, my preference here would be to deal with this and other sorts of verbosity in a single more coordinated stroke, rather than ad-hoc shorthands. For example, at the EG meeting we talked about reclaiming _ as a syntactic token. One of the motivations for having an "I don't want to say" token would be to support partial type inference. For example, we currently support diamond as all-or-nothing, but something finer-grained could fit right into our existing machinery if it had a syntax: new Foo(...) // partial diamond Similarly, we support inferring lambda type parameters as all-or-nothing, but given a syntax, could do something finer-grained: (String s, _ y) -> ... // partial implicit lambda And for target-typed lambdas, we could let inference fill in what is known about the target type: (_ & Serializable) e -> true I think a more coordinated attack (in the future) on redundant type declarations would be a better choice than creating ad-hoc shorthands in specific situations. (Obviously we'd have to have a long discussion on the actual syntax.) From kevinb at google.com Mon Oct 8 09:24:46 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Mon, 8 Oct 2012 09:24:46 -0700 Subject: Serialization opt-in syntax (again) In-Reply-To: <5072FD4F.5030903@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> <5072F980.6030004@oracle.com> <5072FD4F.5030903@oracle.com> Message-ID: I'm sorry that I'd forgotten this _ suggestion before. I like it. On Mon, Oct 8, 2012 at 9:20 AM, Brian Goetz wrote: > still evaluate whether it's worth offering the (& Serializable) >> shorthand as well. The shorthand has benefits similar to the Java 7 >> "diamond", though I must concede the situation only comes up a tiny >> fraction as often. >> > > I agree that it is worth considering such. But, my preference here would > be to deal with this and other sorts of verbosity in a single more > coordinated stroke, rather than ad-hoc shorthands. For example, at the EG > meeting we talked about reclaiming _ as a syntactic token. One of the > motivations for having an "I don't want to say" token would be to support > partial type inference. For example, we currently support diamond as > all-or-nothing, but something finer-grained could fit right into our > existing machinery if it had a syntax: > > new Foo(...) // partial diamond > > Similarly, we support inferring lambda type parameters as all-or-nothing, > but given a syntax, could do something finer-grained: > > (String s, _ y) -> ... // partial implicit lambda > > And for target-typed lambdas, we could let inference fill in what is known > about the target type: > > (_ & Serializable) e -> true > > I think a more coordinated attack (in the future) on redundant type > declarations would be a better choice than creating ad-hoc shorthands in > specific situations. (Obviously we'd have to have a long discussion on the > actual syntax.) > > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121008/0f833dd4/attachment.html From kevinb at google.com Mon Oct 8 09:48:45 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Mon, 8 Oct 2012 09:48:45 -0700 Subject: Serialization stability (was: syntax) In-Reply-To: <5072F508.7020705@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <5072D69F.9030000@redhat.com> <5072F508.7020705@oracle.com> Message-ID: Two meta-questions: * Can we ensure that in every case serialization will either work correctly or fail outright? * Can we ensure that it's very clear to users exactly when it will work and when it won't? If we do right by those, then I'm okay with just about any sacrifice we have to make in the actual guarantee we make, all the way down to the bare minimum "absolutely identical class files on both sides, only." On Mon, Oct 8, 2012 at 8:45 AM, Brian Goetz wrote: > Well, they don't really solve the problem of making serialization >> correct; they accept as given that it's OK for anonymous and (worse yet) >> capturing lambdas to be serialized with the expectation that it'll just >> be flat-out wrong if you change the source in any way, which is >> something I absolutely do not concede and which I firmly believe will >> bite us (where "us"=="Java EE vendors"... and RMI users, and JPA users, >> and just about any of the hundreds of widely-used serialization-based >> technologies out there). >> > > I think the correctness you seek is just inachievable. Even with named > classes, serialization has all sorts of limits and gotchas. With inner > classes, people have learned that you can use inner classes with > serialization when you have identical bytecode on both sides of the pipe, > and can't otherwise. Its imperfect, but it seems a reasonable bar to say > "no worse than inner classes". > > I get that you would like to set a higher bar -- and I'm open to seeing > what we can do to meet a higher bar. But first we should meet the bar we > have, and we're stuck there. > > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121008/48616f9a/attachment.html From david.lloyd at redhat.com Mon Oct 8 10:10:48 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 08 Oct 2012 12:10:48 -0500 Subject: Serialization stability In-Reply-To: <5072F508.7020705@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <5072D69F.9030000@redhat.com> <5072F508.7020705@oracle.com> Message-ID: <50730918.5060301@redhat.com> On 10/08/2012 10:45 AM, Brian Goetz wrote: >> Well, they don't really solve the problem of making serialization >> correct; they accept as given that it's OK for anonymous and (worse yet) >> capturing lambdas to be serialized with the expectation that it'll just >> be flat-out wrong if you change the source in any way, which is >> something I absolutely do not concede and which I firmly believe will >> bite us (where "us"=="Java EE vendors"... and RMI users, and JPA users, >> and just about any of the hundreds of widely-used serialization-based >> technologies out there). > > I think the correctness you seek is just inachievable. Even with named > classes, serialization has all sorts of limits and gotchas. Sure, but by and large it works. There are few surprises as long as you stick to named classes. > With inner > classes, people have learned that you can use inner classes with > serialization when you have identical bytecode on both sides of the > pipe, and can't otherwise. That's not perfectly accurate; only anonymous (and, I think, local) classes have this limitation. "Regular" inner classes generally work fine, even if the source is rearranged, since by and large (from my experience anyway) everyone uses the same representation for inner class names and outer class links. > Its imperfect, but it seems a reasonable bar to say "no worse than inner classes". > I get that you would like to set a higher bar -- and I'm open to seeing > what we can do to meet a higher bar. But first we should meet the bar > we have, and we're stuck there. I disagree - anonymous classes were an oversight; just because one thing doesn't work does not give justification to make more problems. It's more of an excuse. I think we *can* limit serialization to named references, and this would cause a better user experience; and, as far as I'm able to figure, this is actually a *lower* bar implementation-wise, therefore I think *this* should be our default setting rather than (what appears to be) going out of our way to repeat mistakes of the past for the sake of consistency. -- - DML From brian.goetz at oracle.com Mon Oct 8 10:26:57 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 08 Oct 2012 13:26:57 -0400 Subject: Serialization stability In-Reply-To: <50730918.5060301@redhat.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <5072D69F.9030000@redhat.com> <5072F508.7020705@oracle.com> <50730918.5060301@redhat.com> Message-ID: <50730CE1.5070004@oracle.com> > I disagree - anonymous classes were an oversight; just because one thing > doesn't work does not give justification to make more problems. It's > more of an excuse. I think we *can* limit serialization to named > references, and this would cause a better user experience No, the user experience in this case would be terrible! People would simply not understand why the "stupid compiler" is forcing you to manually desugar lambdas to method references, why static and unbound method refs are OK but not bound ones, or why simple lambdas like s -> true will not serialize, or why things that are expressible today as serializable anonymous classes don't work as lambdas. (I am not saying that your position is not one worth discussing, just that to call it a better user experience is kind of silly.) From david.lloyd at redhat.com Mon Oct 8 10:47:31 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 08 Oct 2012 12:47:31 -0500 Subject: Serialization stability In-Reply-To: <50730CE1.5070004@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <5072D69F.9030000@redhat.com> <5072F508.7020705@oracle.com> <50730918.5060301@redhat.com> <50730CE1.5070004@oracle.com> Message-ID: <507311B3.7090102@redhat.com> On 10/08/2012 12:26 PM, Brian Goetz wrote: >> I disagree - anonymous classes were an oversight; just because one thing >> doesn't work does not give justification to make more problems. It's >> more of an excuse. I think we *can* limit serialization to named >> references, and this would cause a better user experience > > No, the user experience in this case would be terrible! People would > simply not understand why the "stupid compiler" is forcing you to > manually desugar lambdas to method references, why static and unbound > method refs are OK but not bound ones, or why simple lambdas like s -> > true will not serialize, or why things that are expressible today as > serializable anonymous classes don't work as lambdas. > > (I am not saying that your position is not one worth discussing, just > that to call it a better user experience is kind of silly.) My experience with end users would pretty much uniformly give me the opposite expectation ("if this was going to break why didn't it just say so up front?"). If the compiler tells someone to do something, for the most part they just do it (or do the couple keystrokes it takes for their IDE to do it), and then remember for next time. It's when things start falling apart in production for non-obvious reasons that people begin to feel like they've been screwed over. -- - DML From brian.goetz at oracle.com Mon Oct 8 10:54:19 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 08 Oct 2012 13:54:19 -0400 Subject: Serialization stability In-Reply-To: <507311B3.7090102@redhat.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <5072D69F.9030000@redhat.com> <5072F508.7020705@oracle.com> <50730918.5060301@redhat.com> <50730CE1.5070004@oracle.com> <507311B3.7090102@redhat.com> Message-ID: <5073134B.5080501@oracle.com> The point I am making is: if we adopt your "named only" rule, people absolutely *will* feel screwed over, and in a NEW and different way. Whereas if we go with the "no worse (and better if we can) than inner classes" bar, yes there will still be screwage, but it will be more of the same that they've been experiencing for years (and for which many people have learned to work around in one of many ways -- keep the bits constant, don't use anon classes -- all of which will still be valid.) I realize you deal with the users who are most affected by this. I don't want to minimize this, since these are real problems experienced by real users, but let's also not lose sight of the fact that lots of people have figured out how to work around the pain of serialization with anonymous classes. I think our effort is best spent choosing the best translation scheme we can, and clearly identifying what the boundary of serializability is with respect to lambdas. On 10/8/2012 1:47 PM, David M. Lloyd wrote: > On 10/08/2012 12:26 PM, Brian Goetz wrote: >>> I disagree - anonymous classes were an oversight; just because one thing >>> doesn't work does not give justification to make more problems. It's >>> more of an excuse. I think we *can* limit serialization to named >>> references, and this would cause a better user experience >> >> No, the user experience in this case would be terrible! People would >> simply not understand why the "stupid compiler" is forcing you to >> manually desugar lambdas to method references, why static and unbound >> method refs are OK but not bound ones, or why simple lambdas like s -> >> true will not serialize, or why things that are expressible today as >> serializable anonymous classes don't work as lambdas. >> >> (I am not saying that your position is not one worth discussing, just >> that to call it a better user experience is kind of silly.) > > My experience with end users would pretty much uniformly give me the > opposite expectation ("if this was going to break why didn't it just say > so up front?"). If the compiler tells someone to do something, for the > most part they just do it (or do the couple keystrokes it takes for > their IDE to do it), and then remember for next time. It's when things > start falling apart in production for non-obvious reasons that people > begin to feel like they've been screwed over. > From david.lloyd at redhat.com Mon Oct 8 11:12:49 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 08 Oct 2012 13:12:49 -0500 Subject: Serialization stability In-Reply-To: <5073134B.5080501@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <5072D69F.9030000@redhat.com> <5072F508.7020705@oracle.com> <50730918.5060301@redhat.com> <50730CE1.5070004@oracle.com> <507311B3.7090102@redhat.com> <5073134B.5080501@oracle.com> Message-ID: <507317A1.5020904@redhat.com> There is one thing I want to point out though - I think lambdas will be far more widely used than anon inner classes, especially given changes to the collections API specifically to make them more accessible. So this, along with the capture semantics which make it impossible to use certain solutions available to anon/local classes (i.e. assign captured variables to explicitly named fields) makes them not strictly equivalent in my view. I will continue to be strongly against allowing serializable anonymous lambdas, and even more strongly against allowing serializable capturing lambdas, unless someone comes up with a real mitigating solution to these problems. On 10/08/2012 12:54 PM, Brian Goetz wrote: > The point I am making is: if we adopt your "named only" rule, people > absolutely *will* feel screwed over, and in a NEW and different way. > Whereas if we go with the "no worse (and better if we can) than inner > classes" bar, yes there will still be screwage, but it will be more of > the same that they've been experiencing for years (and for which many > people have learned to work around in one of many ways -- keep the bits > constant, don't use anon classes -- all of which will still be valid.) > > I realize you deal with the users who are most affected by this. I > don't want to minimize this, since these are real problems experienced > by real users, but let's also not lose sight of the fact that lots of > people have figured out how to work around the pain of serialization > with anonymous classes. > > I think our effort is best spent choosing the best translation scheme we > can, and clearly identifying what the boundary of serializability is > with respect to lambdas. > > On 10/8/2012 1:47 PM, David M. Lloyd wrote: >> On 10/08/2012 12:26 PM, Brian Goetz wrote: >>>> I disagree - anonymous classes were an oversight; just because one >>>> thing >>>> doesn't work does not give justification to make more problems. It's >>>> more of an excuse. I think we *can* limit serialization to named >>>> references, and this would cause a better user experience >>> >>> No, the user experience in this case would be terrible! People would >>> simply not understand why the "stupid compiler" is forcing you to >>> manually desugar lambdas to method references, why static and unbound >>> method refs are OK but not bound ones, or why simple lambdas like s -> >>> true will not serialize, or why things that are expressible today as >>> serializable anonymous classes don't work as lambdas. >>> >>> (I am not saying that your position is not one worth discussing, just >>> that to call it a better user experience is kind of silly.) >> >> My experience with end users would pretty much uniformly give me the >> opposite expectation ("if this was going to break why didn't it just say >> so up front?"). If the compiler tells someone to do something, for the >> most part they just do it (or do the couple keystrokes it takes for >> their IDE to do it), and then remember for next time. It's when things >> start falling apart in production for non-obvious reasons that people >> begin to feel like they've been screwed over. >> -- - DML From forax at univ-mlv.fr Mon Oct 8 11:13:32 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 08 Oct 2012 20:13:32 +0200 Subject: Serialization opt-in syntax (again) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> <5072F980.6030004@oracle.com> <5072FD4F.5030903@oracle.com> Message-ID: <507317CC.4020509@univ-mlv.fr> On 10/08/2012 06:24 PM, Kevin Bourrillion wrote: > I'm sorry that I'd forgotten this _ suggestion before. I like it. We talk about _ as an identifier, not as a placeholder for a type. Brian, I suppose that you can use '_' everywhere the inference is used, so Array.<_>asList(2, 3) is also legal ? R?mi > > > > On Mon, Oct 8, 2012 at 9:20 AM, Brian Goetz > wrote: > > still evaluate whether it's worth offering the (& Serializable) > shorthand as well. The shorthand has benefits similar to the > Java 7 > "diamond", though I must concede the situation only comes up a > tiny > fraction as often. > > > I agree that it is worth considering such. But, my preference > here would be to deal with this and other sorts of verbosity in a > single more coordinated stroke, rather than ad-hoc shorthands. > For example, at the EG meeting we talked about reclaiming _ as a > syntactic token. One of the motivations for having an "I don't > want to say" token would be to support partial type inference. > For example, we currently support diamond as all-or-nothing, but > something finer-grained could fit right into our existing > machinery if it had a syntax: > > new Foo(...) // partial diamond > > Similarly, we support inferring lambda type parameters as > all-or-nothing, but given a syntax, could do something finer-grained: > > (String s, _ y) -> ... // partial implicit lambda > > And for target-typed lambdas, we could let inference fill in what > is known about the target type: > > (_ & Serializable) e -> true > > I think a more coordinated attack (in the future) on redundant > type declarations would be a better choice than creating ad-hoc > shorthands in specific situations. (Obviously we'd have to have a > long discussion on the actual syntax.) > > > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com > > From forax at univ-mlv.fr Mon Oct 8 11:26:12 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 08 Oct 2012 20:26:12 +0200 Subject: Serialization opt-in syntax (again) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> <5072F980.6030004@oracle.com> Message-ID: <50731AC4.70505@univ-mlv.fr> On 10/08/2012 06:09 PM, Kevin Bourrillion wrote: > I agree with all the points in your last flood of responses, Brian. > > I'm ready to give up fighting against (Foo & Serializable), and > we should move toward finalizing that decision, but also (separately?) > still evaluate whether it's worth offering the (& Serializable) > shorthand as well. The shorthand has benefits similar to the Java 7 > "diamond", though I must concede the situation only comes up a tiny > fraction as often. I also agree that we should forget the idea of trying to specify a name to provide a better user experience than with inner-classes. Brian, I'm not against the idea to add a way to use & between types in Java. But there are several issues with the cast and the generics that already exist in Java, by example, a cast like (Foo & Serializable) is unsafe and mixing type variable like T, U etc as bound of type variable is restricted. The other problem is how do you handle the SAM conversion is you have a code that use a cast like this: Object o = (I & J) () -> { ... }; at runtime, given that the meta-factory has only one SAM type. cheers, R?mi > > > On Mon, Oct 8, 2012 at 9:04 AM, Brian Goetz > wrote: > > I see only two problems there: > > * Allowing this kind of cast only on lambdas, which is ugly, > but I'm OK with it. > > > I don't even think that this is actually the restriction. Yes, it > affects translation of lambdas, but would also work in cases where > we currently already allow intersection types: > > foo(T t) { ... } > ... > Object o = makeXAndY(); > foo((X&Y) o); > > In fact, the cast to X&Y fills in a current language hole, since > there's no way today to say "I *know* this is an X&Y, trust me" > We just would not be able to call foo() without knowing the name > of the class. > > Admittedly this is a rare situation and has not been a significant > problem so far and is clearly not the goal of this effort. But, I > do believe it provides a good example why, in the absence of an > "obviously good" ad-hoc syntax, we should lean harder on extending > existing concepts rather than inventing yet new ones. > > > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com > > From andrey.breslav at jetbrains.com Mon Oct 8 11:27:35 2012 From: andrey.breslav at jetbrains.com (Andrey Breslav) Date: Mon, 8 Oct 2012 22:27:35 +0400 Subject: Serialization opt-in syntax (again) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> <5072F980.6030004@oracle.com> <5072FD4F.5030903@oracle.com> Message-ID: <1B1265D2-E83C-4D77-8E6A-F913EF667AC1@jetbrains.com> Looks like we could use * instead of _ and break no programs at all (as opposed to breaking very-very few). Nobody but hard-core functional programmers prefer one over another. I even suspect that * meaning "anything" in the shell when dealing with files is more familiar. On Oct 8, 2012, at 20:24 , Kevin Bourrillion wrote: > I'm sorry that I'd forgotten this _ suggestion before. I like it. > > > > On Mon, Oct 8, 2012 at 9:20 AM, Brian Goetz wrote: > still evaluate whether it's worth offering the (& Serializable) > shorthand as well. The shorthand has benefits similar to the Java 7 > "diamond", though I must concede the situation only comes up a tiny > fraction as often. > > I agree that it is worth considering such. But, my preference here would be to deal with this and other sorts of verbosity in a single more coordinated stroke, rather than ad-hoc shorthands. For example, at the EG meeting we talked about reclaiming _ as a syntactic token. One of the motivations for having an "I don't want to say" token would be to support partial type inference. For example, we currently support diamond as all-or-nothing, but something finer-grained could fit right into our existing machinery if it had a syntax: > > new Foo(...) // partial diamond > > Similarly, we support inferring lambda type parameters as all-or-nothing, but given a syntax, could do something finer-grained: > > (String s, _ y) -> ... // partial implicit lambda > > And for target-typed lambdas, we could let inference fill in what is known about the target type: > > (_ & Serializable) e -> true > > I think a more coordinated attack (in the future) on redundant type declarations would be a better choice than creating ad-hoc shorthands in specific situations. (Obviously we'd have to have a long discussion on the actual syntax.) > > > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > -- Andrey Breslav JetBrains, Inc. http://www.jetbrains.com "Develop with pleasure!" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121008/fdc376cd/attachment.html From brian.goetz at oracle.com Mon Oct 8 12:14:45 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 8 Oct 2012 15:14:45 -0400 Subject: Serialization opt-in syntax (again) In-Reply-To: <507317CC.4020509@univ-mlv.fr> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> <5072F980.6030004@oracle.com> <5072FD4F.5030903@oracle.com> <507317CC.4020509@univ-mlv.fr> Message-ID: >> I'm sorry that I'd forgotten this _ suggestion before. I like it. > > We talk about _ as an identifier, not as a placeholder for a type. What we talked about was removing _ from the space of identifiers, so that it could be used for something else. Using it as a placeholder for a type was one of the possible uses offered. > Brian, I suppose that you can use '_' everywhere the inference is used, > so Array.<_>asList(2, 3) is also legal ? That would be consistent with the possible future use of _ as an "infer me" token that I alluded to in my earlier message. From brian.goetz at oracle.com Mon Oct 8 12:17:11 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 8 Oct 2012 15:17:11 -0400 Subject: Serialization opt-in syntax (again) In-Reply-To: <50731AC4.70505@univ-mlv.fr> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> <5072F980.6030004@oracle.com> <50731AC4.70505@univ-mlv.fr> Message-ID: <626D1860-E3DC-4438-9792-A1DA0977D344@oracle.com> > I'm not against the idea to add a way to use & between types in Java. > But there are several issues with the cast and the generics that already exist in Java, > by example, a cast like (Foo & Serializable) is unsafe and mixing type variable like T, U > etc as bound of type variable is restricted. I am not sure what you mean, can you give an example? > The other problem is how do you handle the SAM conversion is you have a code that use a cast like this: > Object o = (I & J) () -> { ... }; > at runtime, given that the meta-factory has only one SAM type. So, in the context of a lambda, it would be a well-formed target type if it is of the form SAM&ZAM&ZAM... Arbitrary intersections of interfaces obviously would not work. If the compiler does not know what J is, then the compiler would not be able to extract enough target type information and would signal an error. From crazybob at crazybob.org Mon Oct 8 13:19:00 2012 From: crazybob at crazybob.org (Bob Lee) Date: Mon, 8 Oct 2012 15:19:00 -0500 Subject: Transitioning JSR-335 to JCP 2.8 -- EG approval needed In-Reply-To: <5071AE10.10602@oracle.com> References: <50636072.5040407@oracle.com> <506496B0.5000109@oracle.com> <5071AE10.10602@oracle.com> Message-ID: Yes. On Sun, Oct 7, 2012 at 11:30 AM, Brian Goetz wrote: > So far we have Yes votes from: > Oracle, IBM, Red Hat, JetBrains, Goldman Sachs, Doug Lea, Remi Forax, > Sam Pullara > > > Waiting for votes from: > Bob Lee > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121008/72f09efe/attachment.html From forax at univ-mlv.fr Mon Oct 8 15:42:36 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 09 Oct 2012 00:42:36 +0200 Subject: Serialization opt-in syntax (again) In-Reply-To: <626D1860-E3DC-4438-9792-A1DA0977D344@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> <5072F980.6030004@oracle.com> <50731AC4.70505@univ-mlv.fr> <626D1860-E3DC-4438-9792-A1DA0977D344@oracle.com> Message-ID: <507356DC.1080406@univ-mlv.fr> On 10/08/2012 09:17 PM, Brian Goetz wrote: >> I'm not against the idea to add a way to use & between types in Java. >> But there are several issues with the cast and the generics that already exist in Java, >> by example, a cast like (Foo & Serializable) is unsafe and mixing type variable like T, U >> etc as bound of type variable is restricted. > I am not sure what you mean, can you give an example? Foo is not a reified type, so Foo & Serializable is not a reified type too. You can't mix type variable and classical type when you specify a bound of a type parameter, e.g.. this doesn't compile: void foo() { ... } Another weird example, with a cast to T is erased to (Object) and with , a cast to T is erased to (Serializable). To sumarize, A & B is not a reified type. > >> The other problem is how do you handle the SAM conversion is you have a code that use a cast like this: >> Object o = (I & J) () -> { ... }; >> at runtime, given that the meta-factory has only one SAM type. > So, in the context of a lambda, it would be a well-formed target type if it is of the form SAM&ZAM&ZAM... Arbitrary intersections of interfaces obviously would not work. If the compiler does not know what J is, then the compiler would not be able to extract enough target type information and would signal an error. > in that case you're reifying a non reified type, I'm not sure there is an issue here but this is clearly a big departure from how the Java type system currently work and I don't think we have time to study that beast. Another way to see the problem is that i don't think you can use & with the inner class syntax, new Object & Serializable() { ... } for the same reason you can't use the diamond syntax with inner classes. R?mi From daniel.smith at oracle.com Mon Oct 8 15:55:41 2012 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 8 Oct 2012 16:55:41 -0600 Subject: Serialization opt-in syntax (again) In-Reply-To: <5072F980.6030004@oracle.com> References: <5065F0C6.4000509@oracle.com> <07C3F547-6459-412F-A13D-E2616116832E@oracle.com> <4DC8F899-2561-4453-A574-965DF8F63A13@oracle.com> <78112E44-95A0-4F25-AFE5-715CFCDB22C3@oracle.com> <6EAE24F5-1263-4E24-AA5D-69BA31E127FD@oracle.com> <506AAC1E.5020507@univ-mlv.fr> <59C5DE39-BEBD-4952-BA0F-DBD2C55588B1@jetbrains.com> <507244DC.4080902@oracle.com> <77C73BD0-D1F1-4284-86E3-B9AD14D01F66@jetbrains.com> <5072F980.6030004@oracle.com> Message-ID: <6C9AFE51-887F-4895-8CB2-07B797C514B6@oracle.com> On Oct 8, 2012, at 10:04 AM, Brian Goetz wrote: >> I see only two problems there: >> >> * Allowing this kind of cast only on lambdas, which is ugly, but I'm OK with it. > > I don't even think that this is actually the restriction. Yes, it affects translation of lambdas, but would also work in cases where we currently already allow intersection types: > > foo(T t) { ... } > ... > Object o = makeXAndY(); > foo((X&Y) o); > > In fact, the cast to X&Y fills in a current language hole, since there's no way today to say "I *know* this is an X&Y, trust me" We just would not be able to call foo() without knowing the name of the class. > > Admittedly this is a rare situation and has not been a significant problem so far and is clearly not the goal of this effort. But, I do believe it provides a good example why, in the absence of an "obviously good" ad-hoc syntax, we should lean harder on extending existing concepts rather than inventing yet new ones. There are some invariants in type-checking and inference that this may break. Plus the complicated rules for well-formed casts would need to be revisited. Would require some analysis... Certainly do-able, but we can't just flip a switch. ?Dan From forax at univ-mlv.fr Mon Oct 8 23:07:48 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 09 Oct 2012 08:07:48 +0200 Subject: Serialization opt-in syntax (summary) In-Reply-To: <50670199.8070805@univ-mlv.fr> References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> Message-ID: <5073BF34.5000207@univ-mlv.fr> We have several choices: - use an annotation like @Serial, but currently there is no way o attach an annotation to an expression, so this was rule out. - use a cast to (Foo & Serializable) but the solution to allow users to use & to specify a type is far from easy and require investigation and we haven't time for that. so if no one has a better idea, this means we need a ad-hoc syntax to specify that a lambda is serialize (David, users want to serialize capturing lambda). I think we have rule out to soon the fact that we also can use a specific syntax, perhaps not x ~> x or x -s> x (the snake arrow Josh had proposed) but a specific syntax is a ad-hoc solution too. R?mi From david.lloyd at redhat.com Tue Oct 9 06:40:12 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 09 Oct 2012 08:40:12 -0500 Subject: Serialization opt-in syntax (summary) In-Reply-To: <5073BF34.5000207@univ-mlv.fr> References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> Message-ID: <5074293C.6000902@redhat.com> On 10/09/2012 01:07 AM, Remi Forax wrote: > We have several choices: > - use an annotation like @Serial, but currently there is no way o > attach an annotation > to an expression, so this was rule out. > - use a cast to (Foo & Serializable) but the solution to allow users > to use & to specify a type > is far from easy and require investigation and we haven't time for > that. > > so if no one has a better idea, this means we need a ad-hoc syntax to > specify that a lambda is serialize > (David, users want to serialize capturing lambda). Users also want the compiler to magically do what they mean, not what they say... but in the end the best thing we can do for users is make the rules simple and predictable. > I think we have rule out to soon the fact that we also can use a > specific syntax, perhaps not x ~> x or > x -s> x (the snake arrow Josh had proposed) but a specific syntax is a > ad-hoc solution too. I don't think you are grasping how incredibly unstable it will be to serialize a capturing lambda, and the fact that we are more concerned about what (we are assuming) users (think they) want versus what we know will be very fragile is very worrisome to me. I am certain that if we allow it as-is, it *will* impact the overall perception of stability of Java EE, which (like it or not) relies heavily upon serialization (including collections). If we want to be able to support serializing capturing lambdas, they simply must have stable names, and their captured values must also have stable names; if we cannot do that then we simply cannot support it! -- - DML From forax at univ-mlv.fr Tue Oct 9 07:33:33 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 09 Oct 2012 16:33:33 +0200 Subject: Serialization opt-in syntax (summary) In-Reply-To: <5074293C.6000902@redhat.com> References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> Message-ID: <507435BD.1000702@univ-mlv.fr> On 10/09/2012 03:40 PM, David M. Lloyd wrote: > On 10/09/2012 01:07 AM, Remi Forax wrote: >> We have several choices: >> - use an annotation like @Serial, but currently there is no way o >> attach an annotation >> to an expression, so this was rule out. >> - use a cast to (Foo & Serializable) but the solution to allow users >> to use & to specify a type >> is far from easy and require investigation and we haven't time for >> that. >> >> so if no one has a better idea, this means we need a ad-hoc syntax to >> specify that a lambda is serialize >> (David, users want to serialize capturing lambda). > > Users also want the compiler to magically do what they mean, not what > they say... but in the end the best thing we can do for users is make > the rules simple and predictable. I agree, but I think that if we have a way to tag lambda as serializable, it's a simple and clear rule. > >> I think we have rule out to soon the fact that we also can use a >> specific syntax, perhaps not x ~> x or >> x -s> x (the snake arrow Josh had proposed) but a specific syntax is a >> ad-hoc solution too. > > I don't think you are grasping how incredibly unstable it will be to > serialize a capturing lambda, and the fact that we are more concerned > about what (we are assuming) users (think they) want versus what we > know will be very fragile is very worrisome to me. I am certain that > if we allow it as-is, it *will* impact the overall perception of > stability of Java EE, which (like it or not) relies heavily upon > serialization (including collections). serializing a lambda is as stable as serializing an anonymous class, so you're right that because we don't offer a way to have a stable name, collections implementations will not be able to declare lambdas exactly like currently there is no anonymous classes in the collection API, there are all refactored as static inner classes to have a name. It seems that Kevin and Don, our API writers are Ok with that. > > If we want to be able to support serializing capturing lambdas, they > simply must have stable names, and their captured values must also > have stable names; if we cannot do that then we simply cannot support it! > No, a stable name + the SAM descriptor/implementation is enough because the captured values are like values stored in fields, so being Serializable is enough to serialize them. R?mi From david.lloyd at redhat.com Tue Oct 9 08:00:19 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 09 Oct 2012 10:00:19 -0500 Subject: Serialization opt-in syntax (summary) In-Reply-To: <507435BD.1000702@univ-mlv.fr> References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> <507435BD.1000702@univ-mlv.fr> Message-ID: <50743C03.2040308@redhat.com> On 10/09/2012 09:33 AM, Remi Forax wrote: > On 10/09/2012 03:40 PM, David M. Lloyd wrote: >> On 10/09/2012 01:07 AM, Remi Forax wrote: >>> We have several choices: >>> - use an annotation like @Serial, but currently there is no way o >>> attach an annotation >>> to an expression, so this was rule out. >>> - use a cast to (Foo & Serializable) but the solution to allow users >>> to use & to specify a type >>> is far from easy and require investigation and we haven't time for >>> that. >>> >>> so if no one has a better idea, this means we need a ad-hoc syntax to >>> specify that a lambda is serialize >>> (David, users want to serialize capturing lambda). >> >> Users also want the compiler to magically do what they mean, not what >> they say... but in the end the best thing we can do for users is make >> the rules simple and predictable. > > I agree, but I think that if we have a way to tag lambda as > serializable, it's a simple and clear rule. > >> >>> I think we have rule out to soon the fact that we also can use a >>> specific syntax, perhaps not x ~> x or >>> x -s> x (the snake arrow Josh had proposed) but a specific syntax is a >>> ad-hoc solution too. >> >> I don't think you are grasping how incredibly unstable it will be to >> serialize a capturing lambda, and the fact that we are more concerned >> about what (we are assuming) users (think they) want versus what we >> know will be very fragile is very worrisome to me. I am certain that >> if we allow it as-is, it *will* impact the overall perception of >> stability of Java EE, which (like it or not) relies heavily upon >> serialization (including collections). > > serializing a lambda is as stable as serializing an anonymous class, so > you're right that because we don't offer a way > to have a stable name, collections implementations will not be able to > declare lambdas exactly like currently > there is no anonymous classes in the collection API, there are all > refactored as static inner classes to have a name. > > It seems that Kevin and Don, our API writers are Ok with that. So you're saying "in order to be stable, lambdas must be refactored to have a name". And you're saying "users can just do this refactoring if they want stability". But I ask you, what is the rationale for allowing an unstable option in the first place? If you know users have to refactor for stability, why give them the option to put a time-bomb in their code? It's fine if API writers know better but users will *not*. It's pure cargo-cultism - we're just imitating something that doesn't work for the sake of being the same, which is silly wrong-headedness. If we can't do it right we simply shouldn't do it. >> If we want to be able to support serializing capturing lambdas, they >> simply must have stable names, and their captured values must also >> have stable names; if we cannot do that then we simply cannot support it! > > No, a stable name + the SAM descriptor/implementation is enough because > the captured values are like values stored in fields, > so being Serializable is enough to serialize them. Until they are reordered in a user's simple code refactor of their EJB, and then production code begins to fail in subtle ways. It's not enough to simply allow lambdas to be serializable. We must also also ensure they are stable, otherwise we're making the world a worse place for no good reason. "People want it" isn't enough justification to do something we know is wrong. People want lots of things that we're not going to do. What people really want is their code to be stable. If superficial stability were enough, we'd all be running PHP, right? -- - DML From kevinb at google.com Tue Oct 9 08:40:24 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Tue, 9 Oct 2012 08:40:24 -0700 Subject: Named lambdas (was Re: Serialization stability and naming (and syntax)) Message-ID: Okay, so the benefits of user-provided names seem to be - More readable toString and stack traces than the auto-provided name (lambda#8 or whatever) - A very small (as noted by Brian) potential to make serialization usable across code changes in a few more situations - It should apparently help hot-swapping to be usable in a few more situations Anything else? If we come up with some syntax for users to name individual lambda expressions, do we think these benefits are great enough that enough users will name their lambdas enough of the time to get real benefit? I'm unsure. Even though lambdas are way more concise than classes, this supreme terseness of lambda expressions is sort of intoxicating and I wonder if most users will get drunk on that and not want any extra characters that weren't strictly required. Likewise, to the extent that any of the advantages can also be realized by switching to a method reference, do we think enough users will actually be willing to make that switch? On Sun, Oct 7, 2012 at 11:44 AM, Andrey Breslav < andrey.breslav at jetbrains.com> wrote: > I would like to point out one thing that somehow keeps escaping our > discussions of this matter. > > Although for some people serialization is the biggest concern here, for a > lot more people a much bigger concern is hot-swapping, where name stability > is very important as well. > > In my mind, this requires us to reconsider the arguments for having/not > having stable names/signatures where we could have that. > > -- > Andrey Breslav > http://jetbrains.com > Develop with pleasure! > > > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121009/7a072813/attachment.html From kevinb at google.com Tue Oct 9 08:50:55 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Tue, 9 Oct 2012 08:50:55 -0700 Subject: Serialization opt-in syntax (summary) In-Reply-To: <50743C03.2040308@redhat.com> References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> <507435BD.1000702@univ-mlv.fr> <50743C03.2040308@redhat.com> Message-ID: Okay, this thread seems to have become about the stability issue again, despite not having it in the subject line, so I'm going to move some comments here that I made on another thread that didn't attract attention. I don't think the first question on our minds should be how stable or not stable serialization needs to be. I think the first question is: is it at least possible to promise that serialization of an instance that was created from a lambda expression will always either work correctly or cleanly fail -- never give a bogus result? If so, great; if not, the stakes are much higher here. On Tue, Oct 9, 2012 at 8:00 AM, David M. Lloyd wrote: > On 10/09/2012 09:33 AM, Remi Forax wrote: > >> On 10/09/2012 03:40 PM, David M. Lloyd wrote: >> >>> On 10/09/2012 01:07 AM, Remi Forax wrote: >>> >>>> We have several choices: >>>> - use an annotation like @Serial, but currently there is no way o >>>> attach an annotation >>>> to an expression, so this was rule out. >>>> - use a cast to (Foo & Serializable) but the solution to allow users >>>> to use & to specify a type >>>> is far from easy and require investigation and we haven't time for >>>> that. >>>> >>>> so if no one has a better idea, this means we need a ad-hoc syntax to >>>> specify that a lambda is serialize >>>> (David, users want to serialize capturing lambda). >>>> >>> >>> Users also want the compiler to magically do what they mean, not what >>> they say... but in the end the best thing we can do for users is make >>> the rules simple and predictable. >>> >> >> I agree, but I think that if we have a way to tag lambda as >> serializable, it's a simple and clear rule. >> >> >>> I think we have rule out to soon the fact that we also can use a >>>> specific syntax, perhaps not x ~> x or >>>> x -s> x (the snake arrow Josh had proposed) but a specific syntax is a >>>> ad-hoc solution too. >>>> >>> >>> I don't think you are grasping how incredibly unstable it will be to >>> serialize a capturing lambda, and the fact that we are more concerned >>> about what (we are assuming) users (think they) want versus what we >>> know will be very fragile is very worrisome to me. I am certain that >>> if we allow it as-is, it *will* impact the overall perception of >>> stability of Java EE, which (like it or not) relies heavily upon >>> serialization (including collections). >>> >> >> serializing a lambda is as stable as serializing an anonymous class, so >> you're right that because we don't offer a way >> to have a stable name, collections implementations will not be able to >> declare lambdas exactly like currently >> there is no anonymous classes in the collection API, there are all >> refactored as static inner classes to have a name. >> >> It seems that Kevin and Don, our API writers are Ok with that. >> > > So you're saying "in order to be stable, lambdas must be refactored to > have a name". And you're saying "users can just do this refactoring if > they want stability". But I ask you, what is the rationale for allowing an > unstable option in the first place? If you know users have to refactor for > stability, why give them the option to put a time-bomb in their code? It's > fine if API writers know better but users will *not*. > > It's pure cargo-cultism - we're just imitating something that doesn't work > for the sake of being the same, which is silly wrong-headedness. If we > can't do it right we simply shouldn't do it. > > > If we want to be able to support serializing capturing lambdas, they >>> simply must have stable names, and their captured values must also >>> have stable names; if we cannot do that then we simply cannot support it! >>> >> >> No, a stable name + the SAM descriptor/implementation is enough because >> the captured values are like values stored in fields, >> so being Serializable is enough to serialize them. >> > > Until they are reordered in a user's simple code refactor of their EJB, > and then production code begins to fail in subtle ways. > > It's not enough to simply allow lambdas to be serializable. We must also > also ensure they are stable, otherwise we're making the world a worse place > for no good reason. "People want it" isn't enough justification to do > something we know is wrong. People want lots of things that we're not > going to do. What people really want is their code to be stable. If > superficial stability were enough, we'd all be running PHP, right? > > -- > - DML > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121009/1f47dbae/attachment.html From forax at univ-mlv.fr Tue Oct 9 09:01:57 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 09 Oct 2012 18:01:57 +0200 Subject: Serialization opt-in syntax (summary) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> <507435BD.1000702@univ-mlv.fr> <50743C03.2040308@redhat.com> Message-ID: <50744A75.7070500@univ-mlv.fr> On 10/09/2012 05:50 PM, Kevin Bourrillion wrote: > Okay, this thread seems to have become about the stability issue > again, despite not having it in the subject line, so I'm going to move > some comments here that I made on another thread that didn't attract > attention. > > I don't think the first question on our minds should be how stable or > not stable serialization needs to be. I think the first question > is: is it at least possible to promise that serialization of an > instance that was created from a lambda expression will always either > work correctly or cleanly fail -- never give a bogus result? > > If so, great; if not, the stakes are much higher here. If you have two lambdas in a code, serialize the first one in a file, remove the code that contains that lambda, re-compile and deserialize, you can deserialize with the wrong lambda. Now, the serialization code check that the lambda are serialized and deserialized with the same SAM type, so the two lambdas must be converted using the same SAM, so this is equivalent to changing the code of a lambda between the time the lambda is serialized and the time the lambda is deserialized. I don't know if you consider that this is a bogus result or not, with classical serialization, you can change the code of a class with no trouble because the serial UID is calculated using the shape of the class not the bytecode instructions. R?mi > > > > On Tue, Oct 9, 2012 at 8:00 AM, David M. Lloyd > wrote: > > On 10/09/2012 09:33 AM, Remi Forax wrote: > > On 10/09/2012 03:40 PM, David M. Lloyd wrote: > > On 10/09/2012 01:07 AM, Remi Forax wrote: > > We have several choices: > - use an annotation like @Serial, but currently > there is no way o > attach an annotation > to an expression, so this was rule out. > - use a cast to (Foo & Serializable) but the > solution to allow users > to use & to specify a type > is far from easy and require investigation and we > haven't time for > that. > > so if no one has a better idea, this means we need a > ad-hoc syntax to > specify that a lambda is serialize > (David, users want to serialize capturing lambda). > > > Users also want the compiler to magically do what they > mean, not what > they say... but in the end the best thing we can do for > users is make > the rules simple and predictable. > > > I agree, but I think that if we have a way to tag lambda as > serializable, it's a simple and clear rule. > > > I think we have rule out to soon the fact that we also > can use a > specific syntax, perhaps not x ~> x or > x -s> x (the snake arrow Josh had proposed) but a > specific syntax is a > ad-hoc solution too. > > > I don't think you are grasping how incredibly unstable it > will be to > serialize a capturing lambda, and the fact that we are > more concerned > about what (we are assuming) users (think they) want > versus what we > know will be very fragile is very worrisome to me. I am > certain that > if we allow it as-is, it *will* impact the overall > perception of > stability of Java EE, which (like it or not) relies > heavily upon > serialization (including collections). > > > serializing a lambda is as stable as serializing an anonymous > class, so > you're right that because we don't offer a way > to have a stable name, collections implementations will not be > able to > declare lambdas exactly like currently > there is no anonymous classes in the collection API, there are all > refactored as static inner classes to have a name. > > It seems that Kevin and Don, our API writers are Ok with that. > > > So you're saying "in order to be stable, lambdas must be > refactored to have a name". And you're saying "users can just do > this refactoring if they want stability". But I ask you, what is > the rationale for allowing an unstable option in the first place? > If you know users have to refactor for stability, why give them > the option to put a time-bomb in their code? It's fine if API > writers know better but users will *not*. > > It's pure cargo-cultism - we're just imitating something that > doesn't work for the sake of being the same, which is silly > wrong-headedness. If we can't do it right we simply shouldn't do it. > > > If we want to be able to support serializing capturing > lambdas, they > simply must have stable names, and their captured values > must also > have stable names; if we cannot do that then we simply > cannot support it! > > > No, a stable name + the SAM descriptor/implementation is > enough because > the captured values are like values stored in fields, > so being Serializable is enough to serialize them. > > > Until they are reordered in a user's simple code refactor of their > EJB, and then production code begins to fail in subtle ways. > > It's not enough to simply allow lambdas to be serializable. We > must also also ensure they are stable, otherwise we're making the > world a worse place for no good reason. "People want it" isn't > enough justification to do something we know is wrong. People > want lots of things that we're not going to do. What people > really want is their code to be stable. If superficial stability > were enough, we'd all be running PHP, right? > > -- > - DML > > > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com > > From brian.goetz at oracle.com Tue Oct 9 10:26:27 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 9 Oct 2012 18:26:27 +0100 Subject: Named lambdas (was Re: Serialization stability and naming (and syntax)) In-Reply-To: References: Message-ID: <1DCBCB7A-12D8-4542-A3CD-A6C0AFD0480A@oracle.com> > Okay, so the benefits of user-provided names seem to be > > - More readable toString and stack traces than the auto-provided name (lambda#8 or whatever) > - A very small (as noted by Brian) potential to make serialization usable across code changes in a few more situations > - It should apparently help hot-swapping to be usable in a few more situations > > Anything else? Even more indirectly, potentially useful for recursive lambdas (not in 8) or nonlocal returns (not in 8). From daniel.smith at oracle.com Tue Oct 9 10:30:26 2012 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 9 Oct 2012 11:30:26 -0600 Subject: Named lambdas (was Re: Serialization stability and naming (and syntax)) In-Reply-To: References: Message-ID: <27FF55E7-4DA7-41B8-A132-F410B3FA89F4@oracle.com> The approach we settled on for names for recursive lambdas was to use the targeted variable name: IntOp fact = x -> { if (x == 0) return 1; else return x*fact.apply(x-1); }; That also seems like a useful, unobtrusive way to give a lambda a name for debugging. If somebody cares about readable names for debugging, they'll probably also care about readable names in code, and the way you name something in code is assign it to a variable. Of course there will be cases where we'd need the name to be "fact$2" or something, but for a best-effort problem like debugging hints, that seems good enough. ?Dan On Oct 9, 2012, at 9:40 AM, Kevin Bourrillion wrote: > Okay, so the benefits of user-provided names seem to be > > - More readable toString and stack traces than the auto-provided name (lambda#8 or whatever) > - A very small (as noted by Brian) potential to make serialization usable across code changes in a few more situations > - It should apparently help hot-swapping to be usable in a few more situations > > Anything else? > > If we come up with some syntax for users to name individual lambda expressions, do we think these benefits are great enough that enough users will name their lambdas enough of the time to get real benefit? I'm unsure. Even though lambdas are way more concise than classes, this supreme terseness of lambda expressions is sort of intoxicating and I wonder if most users will get drunk on that and not want any extra characters that weren't strictly required. > > Likewise, to the extent that any of the advantages can also be realized by switching to a method reference, do we think enough users will actually be willing to make that switch? > > > On Sun, Oct 7, 2012 at 11:44 AM, Andrey Breslav wrote: > I would like to point out one thing that somehow keeps escaping our discussions of this matter. > > Although for some people serialization is the biggest concern here, for a lot more people a much bigger concern is hot-swapping, where name stability is very important as well. > > In my mind, this requires us to reconsider the arguments for having/not having stable names/signatures where we could have that. > > -- > Andrey Breslav > http://jetbrains.com > Develop with pleasure! > > > > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121009/45bee5ff/attachment.html From daniel.smith at oracle.com Tue Oct 9 10:37:55 2012 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 9 Oct 2012 11:37:55 -0600 Subject: Serialization opt-in syntax (summary) In-Reply-To: <5073BF34.5000207@univ-mlv.fr> References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> Message-ID: On Oct 9, 2012, at 12:07 AM, Remi Forax wrote: > - use a cast to (Foo & Serializable) but the solution to allow users to use & to specify a type > is far from easy and require investigation and we haven't time for that. For my part, I wouldn't claim that there's no time. It's just something for the to-do list to prioritize along with other things on the to-do list. And the option of making it only work when directly preceding lambdas/method refs is a viable fallback if general support for intersection casts doesn't make the cut. ?Dan From daniel.smith at oracle.com Wed Oct 10 16:12:18 2012 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 10 Oct 2012 17:12:18 -0600 Subject: Casts & conditionals Message-ID: <1DAC2CA5-7E20-4DE5-81DE-45A01DFD6B6A@oracle.com> I'm exploring the interaction of casts and conditional expressions. Here's an example: Object r = ...; ((Runnable) (cond ? r : ()->System.gc())).run(); The EDR spec treats the cast as a "cast to Runnable" context that gets pushed down to each arm of the conditional. As a result, the first arm interprets it as a checkcast and the second as a lambda target. This might seem kind of strange. An alternative is to treat the cast not as a general poly-expression context, but rather as a construct with special meaning for lambdas (and method references). So in the above example, the conditional is treated as a standalone expression, and an error occurs because the lambda doesn't have a target. Other illustrations: List l1 = ..., l2 = ...; (ArrayList) (cond ? l1 : l2); // EDR: checkcast for each arm // alternative: unchecked (because the standalone type is ArrayList) ((Runnable) (cond ? System::gc : System::runFinalization)).run(); // EDR: each arm is a Runnable // alternative: error -- no target type (cond ? (Runnable) r : (Runnable) ()->System.gc()).run(); // both strategies: ok Any preferences? I think this will be somewhat driven by what's easy to spec and implement, but I'm open to general language design opinions, too. One thing to think about: lambdas are unique right now as poly expressions that can use target information from casts. (Method invocations, on the other hand, cannot.) If, in the future, we add other kinds of poly expressions, would we also want to support cast targets? That decision may influence whether it's best to treat lambda casts as a special-case feature or a general poly expression feature. ((Set) (cond ? {} : {1, 2, 3})).isEmpty() // legal? ?Dan From daniel.smith at oracle.com Wed Oct 10 16:15:34 2012 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 10 Oct 2012 17:15:34 -0600 Subject: Fwd: Wanted: overloading use cases References: <61FB50C8-4270-4895-B0F8-F1E4A605AB39@oracle.com> Message-ID: <2B3A1B5F-2BFA-4836-B1AE-5E8BC07EC687@oracle.com> Drawing your attention to this open request for use cases on lambda-dev. I'm certainly interested in any unique examples EG members can provide. (This was prompted by the discussion at the EG meeting, in which there was a general push for less complexity in the overload resolution strategy.) ?Dan Begin forwarded message: > From: Dan Smith > Subject: Wanted: overloading use cases > Date: October 10, 2012 4:48:15 PM MDT > To: lambda-dev > > I've recently been exploring and refining our overload resolution algorithm for Lambda. I'm looking for some real-world examples of Lambda code that we should support. If you have experience with a library that makes use of lambda-like features (in any language, or a Java library that could naturally be enhanced with lambda support), please read on! > > A typical challenging use case for overload resolution looks like this: > > interface Stream { > Stream map(Mapper m); > IntStream map(IntMapper m); > LongStream map(LongMapper m); > } > > Stream s = ...; > s.map(f -> f.method()); > > Notable properties of this example: > 1) There are multiple methods of the same arity, differing in a functional interface parameter type > 2) The arities of the corresponding functional interfaces are identical > 3) No non-lambda argument can be used for disambiguation > 4) The functional interfaces have the same parameter type(s) > > (Also interesting, but not so relevant to this discussion: the lambda may be compatible with multiple functional interfaces, leaving us to pick a best match after throwing out the incompatible candidates.) > > 1-3 push the required complexity of our approach (assuming we want to support this use case). 4 limits the complexity. > > I'm searching for real-world examples that illustrate 1-3, but that do _not_ have 4 as a simplifying property. Here's what this might look like: > > void poke(Predicate p); > void poke(Mapper m); > > poke(x -> x.isEmpty()); > > If you can think of something like this in any real library that you're familiar with, I'd love to hear about it. (Of course, some languages have very different approaches to overloading. The idea is to identify APIs that a person could map to Java code that fits the above description, and have a reasonable expectation of smooth interaction with implicitly-typed lambdas.) > > I've done some exploring of my own in C# (LINQ) and Scala (standard libraries) and, surprisingly, have turned up very few cases at this level of complexity. My hope is that the diversity of experience of interested community members will help to cast a broader net. > > Thanks, > Dan > From kevinb at google.com Fri Oct 12 07:06:37 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Fri, 12 Oct 2012 07:06:37 -0700 Subject: Named lambdas (was Re: Serialization stability and naming (and syntax)) In-Reply-To: <27FF55E7-4DA7-41B8-A132-F410B3FA89F4@oracle.com> References: <27FF55E7-4DA7-41B8-A132-F410B3FA89F4@oracle.com> Message-ID: Huh. Can it be that simple? This works for me if no one else sees a problem with it! On Tue, Oct 9, 2012 at 10:30 AM, Dan Smith wrote: > The approach we settled on for names for recursive lambdas was to use the > targeted variable name: > > IntOp fact = x -> { > if (x == 0) return 1; > else return x*fact.apply(x-1); > }; > > That also seems like a useful, unobtrusive way to give a lambda a name for > debugging. If somebody cares about readable names for debugging, they'll > probably also care about readable names in code, and the way you name > something in code is assign it to a variable. > > Of course there will be cases where we'd need the name to be "fact$2" or > something, but for a best-effort problem like debugging hints, that seems > good enough. > > ?Dan > > On Oct 9, 2012, at 9:40 AM, Kevin Bourrillion wrote: > > Okay, so the benefits of user-provided names seem to be > > - More readable toString and stack traces than the auto-provided name > (lambda#8 or whatever) > - A very small (as noted by Brian) potential to make serialization usable > across code changes in a few more situations > - It should apparently help hot-swapping to be usable in a few more > situations > > Anything else? > > If we come up with some syntax for users to name individual lambda > expressions, do we think these benefits are great enough that enough users > will name their lambdas enough of the time to get real benefit? I'm > unsure. Even though lambdas are way more concise than classes, this > supreme terseness of lambda expressions is sort of intoxicating and I > wonder if most users will get drunk on that and not want any extra > characters that weren't strictly required. > > Likewise, to the extent that any of the advantages can also be realized by > switching to a method reference, do we think enough users will actually be > willing to make that switch? > > > On Sun, Oct 7, 2012 at 11:44 AM, Andrey Breslav < > andrey.breslav at jetbrains.com> wrote: > >> I would like to point out one thing that somehow keeps escaping our >> discussions of this matter. >> >> Although for some people serialization is the biggest concern here, for a >> lot more people a much bigger concern is hot-swapping, where name stability >> is very important as well. >> >> In my mind, this requires us to reconsider the arguments for having/not >> having stable names/signatures where we could have that. >> >> -- >> Andrey Breslav >> http://jetbrains.com >> Develop with pleasure! >> >> >> > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > > > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121012/c8ccb8f2/attachment.html From kevinb at google.com Fri Oct 12 07:11:19 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Fri, 12 Oct 2012 07:11:19 -0700 Subject: Serialization opt-in syntax (summary) In-Reply-To: <50744A75.7070500@univ-mlv.fr> References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> <507435BD.1000702@univ-mlv.fr> <50743C03.2040308@redhat.com> <50744A75.7070500@univ-mlv.fr> Message-ID: On Tue, Oct 9, 2012 at 9:01 AM, Remi Forax wrote: On 10/09/2012 05:50 PM, Kevin Bourrillion wrote: > >> Okay, this thread seems to have become about the stability issue again, >> despite not having it in the subject line, so I'm going to move some >> comments here that I made on another thread that didn't attract attention. >> >> I don't think the first question on our minds should be how stable or not >> stable serialization needs to be. I think the first question is: is it at >> least possible to promise that serialization of an instance that was >> created from a lambda expression will always either work correctly or >> cleanly fail -- never give a bogus result? >> >> If so, great; if not, the stakes are much higher here. >> > > If you have two lambdas in a code, serialize the first one in a file, > remove the code that contains that lambda, > re-compile and deserialize, you can deserialize with the wrong lambda. > Can, and *should*, we act to prevent that? Calculate a hash based on enough factors, include it in the serialized form and fail fast if the hash doesn't match? Now, the serialization code check that the lambda are serialized and > deserialized with the same SAM type, > so the two lambdas must be converted using the same SAM, so this is > equivalent to changing the code > of a lambda between the time the lambda is serialized and the time the > lambda is deserialized. > > I don't know if you consider that this is a bogus result or not, with > classical serialization, > you can change the code of a class with no trouble because the serial UID > is calculated using the shape > of the class not the bytecode instructions. > > R?mi > > >> >> >> On Tue, Oct 9, 2012 at 8:00 AM, David M. Lloyd > david.lloyd at redhat.com**>> wrote: >> >> On 10/09/2012 09:33 AM, Remi Forax wrote: >> >> On 10/09/2012 03:40 PM, David M. Lloyd wrote: >> >> On 10/09/2012 01:07 AM, Remi Forax wrote: >> >> We have several choices: >> - use an annotation like @Serial, but currently >> there is no way o >> attach an annotation >> to an expression, so this was rule out. >> - use a cast to (Foo & Serializable) but the >> solution to allow users >> to use & to specify a type >> is far from easy and require investigation and we >> haven't time for >> that. >> >> so if no one has a better idea, this means we need a >> ad-hoc syntax to >> specify that a lambda is serialize >> (David, users want to serialize capturing lambda). >> >> >> Users also want the compiler to magically do what they >> mean, not what >> they say... but in the end the best thing we can do for >> users is make >> the rules simple and predictable. >> >> >> I agree, but I think that if we have a way to tag lambda as >> serializable, it's a simple and clear rule. >> >> >> I think we have rule out to soon the fact that we also >> can use a >> specific syntax, perhaps not x ~> x or >> x -s> x (the snake arrow Josh had proposed) but a >> specific syntax is a >> ad-hoc solution too. >> >> >> I don't think you are grasping how incredibly unstable it >> will be to >> serialize a capturing lambda, and the fact that we are >> more concerned >> about what (we are assuming) users (think they) want >> versus what we >> know will be very fragile is very worrisome to me. I am >> certain that >> if we allow it as-is, it *will* impact the overall >> perception of >> stability of Java EE, which (like it or not) relies >> heavily upon >> serialization (including collections). >> >> >> serializing a lambda is as stable as serializing an anonymous >> class, so >> you're right that because we don't offer a way >> to have a stable name, collections implementations will not be >> able to >> declare lambdas exactly like currently >> there is no anonymous classes in the collection API, there are all >> refactored as static inner classes to have a name. >> >> It seems that Kevin and Don, our API writers are Ok with that. >> >> >> So you're saying "in order to be stable, lambdas must be >> refactored to have a name". And you're saying "users can just do >> this refactoring if they want stability". But I ask you, what is >> the rationale for allowing an unstable option in the first place? >> If you know users have to refactor for stability, why give them >> the option to put a time-bomb in their code? It's fine if API >> writers know better but users will *not*. >> >> It's pure cargo-cultism - we're just imitating something that >> doesn't work for the sake of being the same, which is silly >> wrong-headedness. If we can't do it right we simply shouldn't do it. >> >> >> If we want to be able to support serializing capturing >> lambdas, they >> simply must have stable names, and their captured values >> must also >> have stable names; if we cannot do that then we simply >> cannot support it! >> >> >> No, a stable name + the SAM descriptor/implementation is >> enough because >> the captured values are like values stored in fields, >> so being Serializable is enough to serialize them. >> >> >> Until they are reordered in a user's simple code refactor of their >> EJB, and then production code begins to fail in subtle ways. >> >> It's not enough to simply allow lambdas to be serializable. We >> must also also ensure they are stable, otherwise we're making the >> world a worse place for no good reason. "People want it" isn't >> enough justification to do something we know is wrong. People >> want lots of things that we're not going to do. What people >> really want is their code to be stable. If superficial stability >> were enough, we'd all be running PHP, right? >> >> -- - DML >> >> >> >> >> -- >> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com> kevinb at google.com> >> >> > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121012/be543d59/attachment-0001.html From brian.goetz at oracle.com Fri Oct 12 07:33:50 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 12 Oct 2012 15:33:50 +0100 Subject: Named lambdas (was Re: Serialization stability and naming (and syntax)) In-Reply-To: References: <27FF55E7-4DA7-41B8-A132-F410B3FA89F4@oracle.com> Message-ID: I assume you're talking about lambda names now, and not recursion? If so, this works for lambdas assigned to locals but not to lambdas passed to methods. On Oct 12, 2012, at 3:06 PM, Kevin Bourrillion wrote: > Huh. Can it be that simple? This works for me if no one else sees a problem with it! > > > On Tue, Oct 9, 2012 at 10:30 AM, Dan Smith wrote: > The approach we settled on for names for recursive lambdas was to use the targeted variable name: > > IntOp fact = x -> { > if (x == 0) return 1; > else return x*fact.apply(x-1); > }; > > That also seems like a useful, unobtrusive way to give a lambda a name for debugging. If somebody cares about readable names for debugging, they'll probably also care about readable names in code, and the way you name something in code is assign it to a variable. > > Of course there will be cases where we'd need the name to be "fact$2" or something, but for a best-effort problem like debugging hints, that seems good enough. > > ?Dan > > On Oct 9, 2012, at 9:40 AM, Kevin Bourrillion wrote: > >> Okay, so the benefits of user-provided names seem to be >> >> - More readable toString and stack traces than the auto-provided name (lambda#8 or whatever) >> - A very small (as noted by Brian) potential to make serialization usable across code changes in a few more situations >> - It should apparently help hot-swapping to be usable in a few more situations >> >> Anything else? >> >> If we come up with some syntax for users to name individual lambda expressions, do we think these benefits are great enough that enough users will name their lambdas enough of the time to get real benefit? I'm unsure. Even though lambdas are way more concise than classes, this supreme terseness of lambda expressions is sort of intoxicating and I wonder if most users will get drunk on that and not want any extra characters that weren't strictly required. >> >> Likewise, to the extent that any of the advantages can also be realized by switching to a method reference, do we think enough users will actually be willing to make that switch? >> >> >> On Sun, Oct 7, 2012 at 11:44 AM, Andrey Breslav wrote: >> I would like to point out one thing that somehow keeps escaping our discussions of this matter. >> >> Although for some people serialization is the biggest concern here, for a lot more people a much bigger concern is hot-swapping, where name stability is very important as well. >> >> In my mind, this requires us to reconsider the arguments for having/not having stable names/signatures where we could have that. >> >> -- >> Andrey Breslav >> http://jetbrains.com >> Develop with pleasure! >> >> >> >> >> >> -- >> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com >> > > > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121012/9e4fb81a/attachment.html From brian.goetz at oracle.com Fri Oct 12 07:37:00 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 12 Oct 2012 15:37:00 +0100 Subject: Serialization opt-in syntax (summary) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> <507435BD.1000702@univ-mlv.fr> <50743C03.2040308@redhat.com> <50744A75.7070500@univ-mlv.fr> Message-ID: I keep going back to the rubric of "no worse than inner classes." In the case of an inner class that captures local integer variables x and y, if we reorder their references / declarations / rename them, serialized instances will have them backwards, but won't fail because the types will be right. This maps exactly to a failure mode that would happen with the obvious implementation of lambda serialization. On Oct 12, 2012, at 3:11 PM, Kevin Bourrillion wrote: > On Tue, Oct 9, 2012 at 9:01 AM, Remi Forax wrote: > > On 10/09/2012 05:50 PM, Kevin Bourrillion wrote: > Okay, this thread seems to have become about the stability issue again, despite not having it in the subject line, so I'm going to move some comments here that I made on another thread that didn't attract attention. > > I don't think the first question on our minds should be how stable or not stable serialization needs to be. I think the first question is: is it at least possible to promise that serialization of an instance that was created from a lambda expression will always either work correctly or cleanly fail -- never give a bogus result? > > If so, great; if not, the stakes are much higher here. > > If you have two lambdas in a code, serialize the first one in a file, remove the code that contains that lambda, > re-compile and deserialize, you can deserialize with the wrong lambda. > > Can, and should, we act to prevent that? Calculate a hash based on enough factors, include it in the serialized form and fail fast if the hash doesn't match? > > > Now, the serialization code check that the lambda are serialized and deserialized with the same SAM type, > so the two lambdas must be converted using the same SAM, so this is equivalent to changing the code > of a lambda between the time the lambda is serialized and the time the lambda is deserialized. > > I don't know if you consider that this is a bogus result or not, with classical serialization, > you can change the code of a class with no trouble because the serial UID is calculated using the shape > of the class not the bytecode instructions. > > R?mi > > > > > On Tue, Oct 9, 2012 at 8:00 AM, David M. Lloyd > wrote: > > On 10/09/2012 09:33 AM, Remi Forax wrote: > > On 10/09/2012 03:40 PM, David M. Lloyd wrote: > > On 10/09/2012 01:07 AM, Remi Forax wrote: > > We have several choices: > - use an annotation like @Serial, but currently > there is no way o > attach an annotation > to an expression, so this was rule out. > - use a cast to (Foo & Serializable) but the > solution to allow users > to use & to specify a type > is far from easy and require investigation and we > haven't time for > that. > > so if no one has a better idea, this means we need a > ad-hoc syntax to > specify that a lambda is serialize > (David, users want to serialize capturing lambda). > > > Users also want the compiler to magically do what they > mean, not what > they say... but in the end the best thing we can do for > users is make > the rules simple and predictable. > > > I agree, but I think that if we have a way to tag lambda as > serializable, it's a simple and clear rule. > > > I think we have rule out to soon the fact that we also > can use a > specific syntax, perhaps not x ~> x or > x -s> x (the snake arrow Josh had proposed) but a > specific syntax is a > ad-hoc solution too. > > > I don't think you are grasping how incredibly unstable it > will be to > serialize a capturing lambda, and the fact that we are > more concerned > about what (we are assuming) users (think they) want > versus what we > know will be very fragile is very worrisome to me. I am > certain that > if we allow it as-is, it *will* impact the overall > perception of > stability of Java EE, which (like it or not) relies > heavily upon > serialization (including collections). > > > serializing a lambda is as stable as serializing an anonymous > class, so > you're right that because we don't offer a way > to have a stable name, collections implementations will not be > able to > declare lambdas exactly like currently > there is no anonymous classes in the collection API, there are all > refactored as static inner classes to have a name. > > It seems that Kevin and Don, our API writers are Ok with that. > > > So you're saying "in order to be stable, lambdas must be > refactored to have a name". And you're saying "users can just do > this refactoring if they want stability". But I ask you, what is > the rationale for allowing an unstable option in the first place? > If you know users have to refactor for stability, why give them > the option to put a time-bomb in their code? It's fine if API > writers know better but users will *not*. > > It's pure cargo-cultism - we're just imitating something that > doesn't work for the sake of being the same, which is silly > wrong-headedness. If we can't do it right we simply shouldn't do it. > > > If we want to be able to support serializing capturing > lambdas, they > simply must have stable names, and their captured values > must also > have stable names; if we cannot do that then we simply > cannot support it! > > > No, a stable name + the SAM descriptor/implementation is > enough because > the captured values are like values stored in fields, > so being Serializable is enough to serialize them. > > > Until they are reordered in a user's simple code refactor of their > EJB, and then production code begins to fail in subtle ways. > > It's not enough to simply allow lambdas to be serializable. We > must also also ensure they are stable, otherwise we're making the > world a worse place for no good reason. "People want it" isn't > enough justification to do something we know is wrong. People > want lots of things that we're not going to do. What people > really want is their code to be stable. If superficial stability > were enough, we'd all be running PHP, right? > > -- - DML > > > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com > > > > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121012/ad31058d/attachment-0001.html From forax at univ-mlv.fr Fri Oct 12 07:54:35 2012 From: forax at univ-mlv.fr (=?utf-8?B?UmVtaSBGb3JheA==?=) Date: Fri, 12 Oct 2012 16:54:35 +0200 Subject: =?utf-8?B?UmU6IE5hbWVkIGxhbWJkYXMgKHdhcyBSZTogU2VyaWFsaXphdGlvbiBzdGFiaWxpdHkgYW5kIG5hbWluZyAoYW5kCXN5bnRheCkp?= Message-ID: <201210121454.q9CEsVUC014833@monge.univ-mlv.fr> We can use the name of the parameter of the method. The parameter name is stored in the bytecode by java 8 and available in local variable table (if the symbols are not striped) if the bytecode version is < 8 R?mi Sent from my Phone ----- Reply message ----- From: "Brian Goetz" To: "Kevin Bourrillion" Cc: Subject: Named lambdas (was Re: Serialization stability and naming (and syntax)) Date: Fri, Oct 12, 2012 16:33 I assume you're talking about lambda names now, and not recursion? If so, this works for lambdas assigned to locals but not to lambdas passed to methods. On Oct 12, 2012, at 3:06 PM, Kevin Bourrillion wrote:Huh. Can it be that simple? This works for me if no one else sees a problem with it! On Tue, Oct 9, 2012 at 10:30 AM, Dan Smith wrote: The approach we settled on for names for recursive lambdas was to use the targeted variable name: IntOp fact = x -> { if (x == 0) return 1; else return x*fact.apply(x-1);}; That also seems like a useful, unobtrusive way to give a lambda a name for debugging. If somebody cares about readable names for debugging, they'll probably also care about readable names in code, and the way you name something in code is assign it to a variable. Of course there will be cases where we'd need the name to be "fact$2" or something, but for a best-effort problem like debugging hints, that seems good enough. ?Dan On Oct 9, 2012, at 9:40 AM, Kevin Bourrillion wrote: Okay, so the benefits of user-provided names seem to be - More readable toString and stack traces than the auto-provided name (lambda#8 or whatever)- A very small (as noted by Brian) potential to make serialization usable across code changes in a few more situations - It should apparently help hot-swapping to be usable in a few more situations Anything else? If we come up with some syntax for users to name individual lambda expressions, do we think these benefits are great enough that enough users will name their lambdas enough of the time to get real benefit? I'm unsure. Even though lambdas are way more concise than classes, this supreme terseness of lambda expressions is sort of intoxicating and I wonder if most users will get drunk on that and not want any extra characters that weren't strictly required. Likewise, to the extent that any of the advantages can also be realized by switching to a method reference, do we think enough users will actually be willing to make that switch? On Sun, Oct 7, 2012 at 11:44 AM, Andrey Breslav wrote: I would like to point out one thing that somehow keeps escaping our discussions of this matter. Although for some people serialization is the biggest concern here, for a lot more people a much bigger concern is hot-swapping, where name stability is very important as well. In my mind, this requires us to reconsider the arguments for having/not having stable names/signatures where we could have that. -- Andrey Breslav http://jetbrains.com Develop with pleasure! -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121012/06d0cf71/attachment.html From david.lloyd at redhat.com Fri Oct 12 08:17:27 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 12 Oct 2012 10:17:27 -0500 Subject: Serialization opt-in syntax (summary) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> <507435BD.1000702@univ-mlv.fr> <50743C03.2040308@redhat.com> <50744A75.7070500@univ-mlv.fr> Message-ID: <50783487.90908@redhat.com> And I keep going back to "making the mistake once does not justify making it again"... it's better to just fail up front with NotSerializableException if the lambda is anonymous and/or capturing (of more than just the invocation target). On 10/12/2012 09:37 AM, Brian Goetz wrote: > I keep going back to the rubric of "no worse than inner classes." In > the case of an inner class that captures local integer variables x and > y, if we reorder their references / declarations / rename them, > serialized instances will have them backwards, but won't fail because > the types will be right. This maps exactly to a failure mode that would > happen with the obvious implementation of lambda serialization. > > > On Oct 12, 2012, at 3:11 PM, Kevin Bourrillion wrote: > >> On Tue, Oct 9, 2012 at 9:01 AM, Remi Forax > > wrote: >> >> On 10/09/2012 05:50 PM, Kevin Bourrillion wrote: >> >> Okay, this thread seems to have become about the stability >> issue again, despite not having it in the subject line, so I'm >> going to move some comments here that I made on another thread >> that didn't attract attention. >> >> I don't think the first question on our minds should be how >> stable or not stable serialization needs to be. I think the >> first question is: is it at least possible to promise that >> serialization of an instance that was created from a lambda >> expression will always either work correctly or cleanly fail >> -- never give a bogus result? >> >> If so, great; if not, the stakes are much higher here. >> >> >> If you have two lambdas in a code, serialize the first one in a >> file, remove the code that contains that lambda, >> re-compile and deserialize, you can deserialize with the wrong lambda. >> >> >> Can, and /should/, we act to prevent that? Calculate a hash based on >> enough factors, include it in the serialized form and fail fast if the >> hash doesn't match? >> >> >> Now, the serialization code check that the lambda are serialized >> and deserialized with the same SAM type, >> so the two lambdas must be converted using the same SAM, so this >> is equivalent to changing the code >> of a lambda between the time the lambda is serialized and the time >> the lambda is deserialized. >> >> I don't know if you consider that this is a bogus result or not, >> with classical serialization, >> you can change the code of a class with no trouble because the >> serial UID is calculated using the shape >> of the class not the bytecode instructions. >> >> R?mi >> >> >> >> >> On Tue, Oct 9, 2012 at 8:00 AM, David M. Lloyd >> >> > __>> wrote: >> >> On 10/09/2012 09:33 AM, Remi Forax wrote: >> >> On 10/09/2012 03:40 PM, David M. Lloyd wrote: >> >> On 10/09/2012 01:07 AM, Remi Forax wrote: >> >> We have several choices: >> - use an annotation like @Serial, but currently >> there is no way o >> attach an annotation >> to an expression, so this was rule out. >> - use a cast to (Foo & Serializable) but the >> solution to allow users >> to use & to specify a type >> is far from easy and require investigation >> and we >> haven't time for >> that. >> >> so if no one has a better idea, this means we >> need a >> ad-hoc syntax to >> specify that a lambda is serialize >> (David, users want to serialize capturing lambda). >> >> >> Users also want the compiler to magically do what they >> mean, not what >> they say... but in the end the best thing we can >> do for >> users is make >> the rules simple and predictable. >> >> >> I agree, but I think that if we have a way to tag >> lambda as >> serializable, it's a simple and clear rule. >> >> >> I think we have rule out to soon the fact that >> we also >> can use a >> specific syntax, perhaps not x ~> x or >> x -s> x (the snake arrow Josh had proposed) but a >> specific syntax is a >> ad-hoc solution too. >> >> >> I don't think you are grasping how incredibly >> unstable it >> will be to >> serialize a capturing lambda, and the fact that we are >> more concerned >> about what (we are assuming) users (think they) want >> versus what we >> know will be very fragile is very worrisome to me. >> I am >> certain that >> if we allow it as-is, it *will* impact the overall >> perception of >> stability of Java EE, which (like it or not) relies >> heavily upon >> serialization (including collections). >> >> >> serializing a lambda is as stable as serializing an >> anonymous >> class, so >> you're right that because we don't offer a way >> to have a stable name, collections implementations >> will not be >> able to >> declare lambdas exactly like currently >> there is no anonymous classes in the collection API, >> there are all >> refactored as static inner classes to have a name. >> >> It seems that Kevin and Don, our API writers are Ok >> with that. >> >> >> So you're saying "in order to be stable, lambdas must be >> refactored to have a name". And you're saying "users can >> just do >> this refactoring if they want stability". But I ask you, >> what is >> the rationale for allowing an unstable option in the first >> place? >> If you know users have to refactor for stability, why >> give them >> the option to put a time-bomb in their code? It's fine if API >> writers know better but users will *not*. >> >> It's pure cargo-cultism - we're just imitating something that >> doesn't work for the sake of being the same, which is silly >> wrong-headedness. If we can't do it right we simply >> shouldn't do it. >> >> >> If we want to be able to support serializing capturing >> lambdas, they >> simply must have stable names, and their captured >> values >> must also >> have stable names; if we cannot do that then we simply >> cannot support it! >> >> >> No, a stable name + the SAM descriptor/implementation is >> enough because >> the captured values are like values stored in fields, >> so being Serializable is enough to serialize them. >> >> >> Until they are reordered in a user's simple code refactor >> of their >> EJB, and then production code begins to fail in subtle ways. >> >> It's not enough to simply allow lambdas to be >> serializable. We >> must also also ensure they are stable, otherwise we're >> making the >> world a worse place for no good reason. "People want it" >> isn't >> enough justification to do something we know is wrong. People >> want lots of things that we're not going to do. What people >> really want is their code to be stable. If superficial >> stability >> were enough, we'd all be running PHP, right? >> >> -- - DML >> >> >> >> >> -- >> Kevin Bourrillion | Java Librarian | Google, Inc. >> |kevinb at google.com >> > >> >> >> >> >> >> -- >> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com >> >> > -- - DML From brian.goetz at oracle.com Fri Oct 12 08:36:08 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 12 Oct 2012 16:36:08 +0100 Subject: Named lambdas (was Re: Serialization stability and naming (and syntax)) In-Reply-To: <201210121454.q9CEsVUC014833@monge.univ-mlv.fr> References: <201210121454.q9CEsVUC014833@monge.univ-mlv.fr> Message-ID: In both cases we would still have to deal with ambiguity, which is worse in the method param case. Sent from my iPhone On Oct 12, 2012, at 3:54 PM, Remi Forax wrote: > We can use the name of the parameter of the method. The parameter name is stored in the bytecode by java 8 and available in local variable table (if the symbols are not striped) if the bytecode version is < 8 > > R?mi > > Sent from my Phone > > ----- Reply message ----- > From: "Brian Goetz" > To: "Kevin Bourrillion" > Cc: > Subject: Named lambdas (was Re: Serialization stability and naming (and syntax)) > Date: Fri, Oct 12, 2012 16:33 > > > I assume you're talking about lambda names now, and not recursion? > > If so, this works for lambdas assigned to locals but not to lambdas passed to methods. > > On Oct 12, 2012, at 3:06 PM, Kevin Bourrillion wrote: > >> Huh. Can it be that simple? This works for me if no one else sees a problem with it! >> >> >> On Tue, Oct 9, 2012 at 10:30 AM, Dan Smith wrote: >> The approach we settled on for names for recursive lambdas was to use the targeted variable name: >> >> IntOp fact = x -> { >> if (x == 0) return 1; >> else return x*fact.apply(x-1); >> }; >> >> That also seems like a useful, unobtrusive way to give a lambda a name for debugging. If somebody cares about readable names for debugging, they'll probably also care about readable names in code, and the way you name something in code is assign it to a variable. >> >> Of course there will be cases where we'd need the name to be "fact$2" or something, but for a best-effort problem like debugging hints, that seems good enough. >> >> ?Dan >> >> On Oct 9, 2012, at 9:40 AM, Kevin Bourrillion wrote: >> >>> Okay, so the benefits of user-provided names seem to be >>> >>> - More readable toString and stack traces than the auto-provided name (lambda#8 or whatever) >>> - A very small (as noted by Brian) potential to make serialization usable across code changes in a few more situations >>> - It should apparently help hot-swapping to be usable in a few more situations >>> >>> Anything else? >>> >>> If we come up with some syntax for users to name individual lambda expressions, do we think these benefits are great enough that enough users will name their lambdas enough of the time to get real benefit? I'm unsure. Even though lambdas are way more concise than classes, this supreme terseness of lambda expressions is sort of intoxicating and I wonder if most users will get drunk on that and not want any extra characters that weren't strictly required. >>> >>> Likewise, to the extent that any of the advantages can also be realized by switching to a method reference, do we think enough users will actually be willing to make that switch? >>> >>> >>> On Sun, Oct 7, 2012 at 11:44 AM, Andrey Breslav wrote: >>> I would like to point out one thing that somehow keeps escaping our discussions of this matter. >>> >>> Although for some people serialization is the biggest concern here, for a lot more people a much bigger concern is hot-swapping, where name stability is very important as well. >>> >>> In my mind, this requires us to reconsider the arguments for having/not having stable names/signatures where we could have that. >>> >>> -- >>> Andrey Breslav >>> http://jetbrains.com >>> Develop with pleasure! >>> >>> >>> >>> >>> >>> -- >>> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com >>> >> >> >> >> >> -- >> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121012/265f5f12/attachment-0001.html From kevinb at google.com Fri Oct 12 08:46:37 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Fri, 12 Oct 2012 08:46:37 -0700 Subject: Serialization opt-in syntax (summary) In-Reply-To: <50783487.90908@redhat.com> References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> <507435BD.1000702@univ-mlv.fr> <50743C03.2040308@redhat.com> <50744A75.7070500@univ-mlv.fr> <50783487.90908@redhat.com> Message-ID: > > On 10/12/2012 09:37 AM, Brian Goetz wrote: > > I keep going back to the rubric of "no worse than inner classes." >> > On Fri, Oct 12, 2012 at 8:17 AM, David M. Lloyd wrote: And I keep going back to "making the mistake once does not justify making > it again"... Ha. I completely see the sense in both of these mindsets. Posterity hugely prefers that we see it the second way; yet here we are in the present tense and we have to get something working and deliver it. Is that the conflict we're having? -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121012/c701c36b/attachment.html From brian.goetz at oracle.com Fri Oct 12 09:06:52 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 12 Oct 2012 17:06:52 +0100 Subject: Serialization opt-in syntax (summary) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> <507435BD.1000702@univ-mlv.fr> <50743C03.2040308@redhat.com> <50744A75.7070500@univ-mlv.fr> <50783487.90908@redhat.com> Message-ID: <3CFF5874-A601-42EA-9A24-CBB69F6ADEEF@oracle.com> I don't even agree that posterity would prefer it the other way, since there still are inner classes and many users have learned to deal with the frustrating interaction between inner classes and serialization. A more accurate statement is that posterity would have preferred we not make the mistakes of the past the first time, but absent a time machine, we're kind of stuck there. In any case, I don't think "lambdas cannot be serializable" is a realistic option at this point. Users will expect: SerializablePredicate p = x -> true to be serializable -- and entirely reasonably so. We made a commitment to SAM conversion a long time ago, and part of that is users should not have to reason about "how was this SAM constructed -- did it come from a lambda or a class?" Otherwise it is a leaky abstraction. Yes, serialization sucks -- and we're copying the suckage mode that users have spent 15 years getting used to. But that 15 years of user community experience matters -- users have learned how to deal with the limitations, and there is a lot of value in not asking users to learn new and different limitations (especially those that punish the users who learned to live within the old limitations.) The EG took a poll on this at the July meeting last year, and was unanimously in favor of the "weak serialization" target. David wasn't at that meeting, which is too bad, but I just don't see enough new evidence to reopen this issue now. However, we can and should spend our effort on "how can we make things as good as we can subject to the 'no worse than inner classes' rubric. I suggest we redirect our efforts towards that. Choosing a less-brittle translation strategy is a good place to start. On Oct 12, 2012, at 4:46 PM, Kevin Bourrillion wrote: > On 10/12/2012 09:37 AM, Brian Goetz wrote: > > I keep going back to the rubric of "no worse than inner classes." > > On Fri, Oct 12, 2012 at 8:17 AM, David M. Lloyd wrote: > > And I keep going back to "making the mistake once does not justify making it again"... > > Ha. I completely see the sense in both of these mindsets. > > Posterity hugely prefers that we see it the second way; yet here we are in the present tense and we have to get something working and deliver it. Is that the conflict we're having? > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121012/8cf27e9b/attachment.html From kevinb at google.com Fri Oct 12 09:27:45 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Fri, 12 Oct 2012 09:27:45 -0700 Subject: Named lambdas (was Re: Serialization stability and naming (and syntax)) In-Reply-To: References: <201210121454.q9CEsVUC014833@monge.univ-mlv.fr> Message-ID: On Fri, Oct 12, 2012 at 8:36 AM, Brian Goetz wrote: In both cases we would still have to deal with ambiguity, which is worse in > the method param case. > Well, nothing's perfect. This still seems like a reasonable approach and seems to cost the user nothing. > > Sent from my iPhone > > On Oct 12, 2012, at 3:54 PM, Remi Forax wrote: > > We can use the name of the parameter of the method. The parameter name is > stored in the bytecode by java 8 and available in local variable table (if > the symbols are not striped) if the bytecode version is < 8 > > R?mi > > Sent from my Phone > > ----- Reply message ----- > From: "Brian Goetz" > To: "Kevin Bourrillion" > Cc: > Subject: Named lambdas (was Re: Serialization stability and naming (and > syntax)) > Date: Fri, Oct 12, 2012 16:33 > > > I assume you're talking about lambda names now, and not recursion? > > If so, this works for lambdas assigned to locals but not to lambdas passed > to methods. > > On Oct 12, 2012, at 3:06 PM, Kevin Bourrillion wrote: > > Huh. Can it be that simple? This works for me if no one else sees a > problem with it! > > > On Tue, Oct 9, 2012 at 10:30 AM, Dan Smith wrote: > >> The approach we settled on for names for recursive lambdas was to use the >> targeted variable name: >> >> IntOp fact = x -> { >> if (x == 0) return 1; >> else return x*fact.apply(x-1); >> }; >> >> That also seems like a useful, unobtrusive way to give a lambda a name >> for debugging. If somebody cares about readable names for debugging, >> they'll probably also care about readable names in code, and the way you >> name something in code is assign it to a variable. >> >> Of course there will be cases where we'd need the name to be "fact$2" or >> something, but for a best-effort problem like debugging hints, that seems >> good enough. >> >> ?Dan >> >> On Oct 9, 2012, at 9:40 AM, Kevin Bourrillion wrote: >> >> Okay, so the benefits of user-provided names seem to be >> >> - More readable toString and stack traces than the auto-provided name >> (lambda#8 or whatever) >> - A very small (as noted by Brian) potential to make serialization usable >> across code changes in a few more situations >> - It should apparently help hot-swapping to be usable in a few more >> situations >> >> Anything else? >> >> If we come up with some syntax for users to name individual lambda >> expressions, do we think these benefits are great enough that enough users >> will name their lambdas enough of the time to get real benefit? I'm >> unsure. Even though lambdas are way more concise than classes, this >> supreme terseness of lambda expressions is sort of intoxicating and I >> wonder if most users will get drunk on that and not want any extra >> characters that weren't strictly required. >> >> Likewise, to the extent that any of the advantages can also be realized >> by switching to a method reference, do we think enough users will actually >> be willing to make that switch? >> >> >> On Sun, Oct 7, 2012 at 11:44 AM, Andrey Breslav < >> andrey.breslav at jetbrains.com> wrote: >> >>> I would like to point out one thing that somehow keeps escaping our >>> discussions of this matter. >>> >>> Although for some people serialization is the biggest concern here, for >>> a lot more people a much bigger concern is hot-swapping, where name >>> stability is very important as well. >>> >>> In my mind, this requires us to reconsider the arguments for having/not >>> having stable names/signatures where we could have that. >>> >>> -- >>> Andrey Breslav >>> http://jetbrains.com >>> Develop with pleasure! >>> >>> >>> >> >> >> -- >> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com >> >> >> > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > > > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121012/c822fd87/attachment-0001.html From sam at sampullara.com Fri Oct 12 09:31:38 2012 From: sam at sampullara.com (Sam Pullara) Date: Fri, 12 Oct 2012 09:31:38 -0700 Subject: Serialization opt-in syntax (summary) In-Reply-To: <3CFF5874-A601-42EA-9A24-CBB69F6ADEEF@oracle.com> References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> <507435BD.1000702@univ-mlv.fr> <50743C03.2040308@redhat.com> <50744A75.7070500@univ-mlv.fr> <50783487.90908@redhat.com> <3CFF5874-A601-42EA-9A24-CBB69F6ADEEF@oracle.com> Message-ID: Crazy idea. Can we just make it a method call that wraps up the lamba in a wrapper that can be serialized? We could add the static method to Serializable: Callable r = Serializable.wrap(() -> true); It may have to be a little magical (not unlike serialization) but at least it is obvious and doesn't introduce anything new. You could even include the name if you want to make them more robust: Callable r = Serializable.wrap("My True Callable", () -> true); Sam On Fri, Oct 12, 2012 at 9:06 AM, Brian Goetz wrote: > I don't even agree that posterity would prefer it the other way, since > there still are inner classes and many users have learned to deal with the > frustrating interaction between inner classes and serialization. A more > accurate statement is that posterity would have preferred we not make the > mistakes of the past the first time, but absent a time machine, we're kind > of stuck there. > > In any case, I don't think "lambdas cannot be serializable" is a realistic > option at this point. Users will expect: > > SerializablePredicate p = x -> true > > to be serializable -- and entirely reasonably so. We made a commitment to > SAM conversion a long time ago, and part of that is users should not have > to reason about "how was this SAM constructed -- did it come from a lambda > or a class?" Otherwise it is a leaky abstraction. Yes, serialization > sucks -- and we're copying the suckage mode that users have spent 15 years > getting used to. But that 15 years of user community experience matters -- > users have learned how to deal with the limitations, and there is a lot of > value in not asking users to learn new and different limitations > (especially those that punish the users who learned to live within the old > limitations.) > > The EG took a poll on this at the July meeting last year, and was > unanimously in favor of the "weak serialization" target. David wasn't at > that meeting, which is too bad, but I just don't see enough new evidence to > reopen this issue now. > > However, we can and should spend our effort on "how can we make things as > good as we can subject to the 'no worse than inner classes' rubric. I > suggest we redirect our efforts towards that. Choosing a less-brittle > translation strategy is a good place to start. > > On Oct 12, 2012, at 4:46 PM, Kevin Bourrillion wrote: > > On 10/12/2012 09:37 AM, Brian Goetz wrote: >> > > >> I keep going back to the rubric of "no worse than inner classes." >>> >> > On Fri, Oct 12, 2012 at 8:17 AM, David M. Lloyd > wrote: > > And I keep going back to "making the mistake once does not justify making >> it again"... > > > Ha. I completely see the sense in both of these mindsets. > > Posterity hugely prefers that we see it the second way; yet here we are in > the present tense and we have to get something working and deliver it. Is > that the conflict we're having? > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121012/3c2945b6/attachment.html From david.lloyd at redhat.com Fri Oct 12 09:32:07 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 12 Oct 2012 11:32:07 -0500 Subject: Serialization opt-in syntax (summary) In-Reply-To: <3CFF5874-A601-42EA-9A24-CBB69F6ADEEF@oracle.com> References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> <507435BD.1000702@univ-mlv.fr> <50743C03.2040308@redhat.com> <50744A75.7070500@univ-mlv.fr> <50783487.90908@redhat.com> <3CFF5874-A601-42EA-9A24-CBB69F6ADEEF@oracle.com> Message-ID: <50784607.70705@redhat.com> Users might also expect this to work: SerializablePredicate = Proxy.newProxyInstance( cl, new Class[] { SerializablePredicate.class }, new NonSerializableHandler()); But it doesn't, for exactly the same reasons in fact. On 10/12/2012 11:06 AM, Brian Goetz wrote: > I don't even agree that posterity would prefer it the other way, since > there still are inner classes and many users have learned to deal with > the frustrating interaction between inner classes and serialization. A > more accurate statement is that posterity would have preferred we not > make the mistakes of the past the first time, but absent a time machine, > we're kind of stuck there. > > In any case, I don't think "lambdas cannot be serializable" is a > realistic option at this point. Users will expect: > > SerializablePredicate p = x -> true > > to be serializable -- and entirely reasonably so. We made a commitment > to SAM conversion a long time ago, and part of that is users should not > have to reason about "how was this SAM constructed -- did it come from a > lambda or a class?" Otherwise it is a leaky abstraction. Yes, > serialization sucks -- and we're copying the suckage mode that users > have spent 15 years getting used to. But that 15 years of user > community experience matters -- users have learned how to deal with the > limitations, and there is a lot of value in not asking users to learn > new and different limitations (especially those that punish the users > who learned to live within the old limitations.) > > The EG took a poll on this at the July meeting last year, and was > unanimously in favor of the "weak serialization" target. David wasn't > at that meeting, which is too bad, but I just don't see enough new > evidence to reopen this issue now. > > However, we can and should spend our effort on "how can we make things > as good as we can subject to the 'no worse than inner classes' rubric. > I suggest we redirect our efforts towards that. Choosing a > less-brittle translation strategy is a good place to start. > > On Oct 12, 2012, at 4:46 PM, Kevin Bourrillion wrote: > >> On 10/12/2012 09:37 AM, Brian Goetz wrote: >> >> I keep going back to the rubric of "no worse than inner classes." >> >> >> On Fri, Oct 12, 2012 at 8:17 AM, David M. Lloyd >> > wrote: >> >> And I keep going back to "making the mistake once does not justify >> making it again"... >> >> >> Ha. I completely see the sense in both of these mindsets. >> >> Posterity hugely prefers that we see it the second way; yet here we >> are in the present tense and we have to get something working and >> deliver it. Is that the conflict we're having? >> >> -- >> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com >> >> > -- - DML From brian.goetz at oracle.com Fri Oct 12 11:17:15 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 12 Oct 2012 19:17:15 +0100 Subject: Serialization opt-in syntax (summary) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> <507435BD.1000702@univ-mlv.fr> <50743C03.2040308@redhat.com> <50744A75.7070500@univ-mlv.fr> <50783487.90908@redhat.com> <3CFF5874-A601-42EA-9A24-CBB69F6ADEEF@oracle.com> Message-ID: I believe this option was on the list on the issue tracker? Sent from my iPhone On Oct 12, 2012, at 5:31 PM, Sam Pullara wrote: > Crazy idea. Can we just make it a method call that wraps up the lamba in a wrapper that can be serialized? We could add the static method to Serializable: > > Callable r = Serializable.wrap(() -> true); > > It may have to be a little magical (not unlike serialization) but at least it is obvious and doesn't introduce anything new. You could even include the name if you want to make them more robust: > > Callable r = Serializable.wrap("My True Callable", () -> true); > > Sam > > On Fri, Oct 12, 2012 at 9:06 AM, Brian Goetz wrote: > I don't even agree that posterity would prefer it the other way, since there still are inner classes and many users have learned to deal with the frustrating interaction between inner classes and serialization. A more accurate statement is that posterity would have preferred we not make the mistakes of the past the first time, but absent a time machine, we're kind of stuck there. > > In any case, I don't think "lambdas cannot be serializable" is a realistic option at this point. Users will expect: > > SerializablePredicate p = x -> true > > to be serializable -- and entirely reasonably so. We made a commitment to SAM conversion a long time ago, and part of that is users should not have to reason about "how was this SAM constructed -- did it come from a lambda or a class?" Otherwise it is a leaky abstraction. Yes, serialization sucks -- and we're copying the suckage mode that users have spent 15 years getting used to. But that 15 years of user community experience matters -- users have learned how to deal with the limitations, and there is a lot of value in not asking users to learn new and different limitations (especially those that punish the users who learned to live within the old limitations.) > > The EG took a poll on this at the July meeting last year, and was unanimously in favor of the "weak serialization" target. David wasn't at that meeting, which is too bad, but I just don't see enough new evidence to reopen this issue now. > > However, we can and should spend our effort on "how can we make things as good as we can subject to the 'no worse than inner classes' rubric. I suggest we redirect our efforts towards that. Choosing a less-brittle translation strategy is a good place to start. > > On Oct 12, 2012, at 4:46 PM, Kevin Bourrillion wrote: > >> On 10/12/2012 09:37 AM, Brian Goetz wrote: >> >> I keep going back to the rubric of "no worse than inner classes." >> >> On Fri, Oct 12, 2012 at 8:17 AM, David M. Lloyd wrote: >> >> And I keep going back to "making the mistake once does not justify making it again"... >> >> Ha. I completely see the sense in both of these mindsets. >> >> Posterity hugely prefers that we see it the second way; yet here we are in the present tense and we have to get something working and deliver it. Is that the conflict we're having? >> >> -- >> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121012/ddf326de/attachment.html From spullara at gmail.com Fri Oct 12 12:13:10 2012 From: spullara at gmail.com (Sam Pullara) Date: Fri, 12 Oct 2012 12:13:10 -0700 Subject: Serialization opt-in syntax (summary) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> <507435BD.1000702@univ-mlv.fr> <50743C03.2040308@redhat.com> <50744A75.7070500@univ-mlv.fr> <50783487.90908@redhat.com> <3CFF5874-A601-42EA-9A24-CBB69F6ADEEF@oracle.com> Message-ID: <-1384913952142129941@unknownmsgid> Must have missed it. I think I would prefer something like this. Will update my comment. Sam All my photos are panoramas. On Oct 12, 2012, at 11:17 AM, Brian Goetz wrote: I believe this option was on the list on the issue tracker? Sent from my iPhone On Oct 12, 2012, at 5:31 PM, Sam Pullara wrote: Crazy idea. Can we just make it a method call that wraps up the lamba in a wrapper that can be serialized? We could add the static method to Serializable: Callable r = Serializable.wrap(() -> true); It may have to be a little magical (not unlike serialization) but at least it is obvious and doesn't introduce anything new. You could even include the name if you want to make them more robust: Callable r = Serializable.wrap("My True Callable", () -> true); Sam On Fri, Oct 12, 2012 at 9:06 AM, Brian Goetz wrote: > I don't even agree that posterity would prefer it the other way, since > there still are inner classes and many users have learned to deal with the > frustrating interaction between inner classes and serialization. A more > accurate statement is that posterity would have preferred we not make the > mistakes of the past the first time, but absent a time machine, we're kind > of stuck there. > > In any case, I don't think "lambdas cannot be serializable" is a realistic > option at this point. Users will expect: > > SerializablePredicate p = x -> true > > to be serializable -- and entirely reasonably so. We made a commitment to > SAM conversion a long time ago, and part of that is users should not have > to reason about "how was this SAM constructed -- did it come from a lambda > or a class?" Otherwise it is a leaky abstraction. Yes, serialization > sucks -- and we're copying the suckage mode that users have spent 15 years > getting used to. But that 15 years of user community experience matters -- > users have learned how to deal with the limitations, and there is a lot of > value in not asking users to learn new and different limitations > (especially those that punish the users who learned to live within the old > limitations.) > > The EG took a poll on this at the July meeting last year, and was > unanimously in favor of the "weak serialization" target. David wasn't at > that meeting, which is too bad, but I just don't see enough new evidence to > reopen this issue now. > > However, we can and should spend our effort on "how can we make things as > good as we can subject to the 'no worse than inner classes' rubric. I > suggest we redirect our efforts towards that. Choosing a less-brittle > translation strategy is a good place to start. > > On Oct 12, 2012, at 4:46 PM, Kevin Bourrillion wrote: > > On 10/12/2012 09:37 AM, Brian Goetz wrote: >> > > >> I keep going back to the rubric of "no worse than inner classes." >>> >> > On Fri, Oct 12, 2012 at 8:17 AM, David M. Lloyd > wrote: > > And I keep going back to "making the mistake once does not justify making >> it again"... > > > Ha. I completely see the sense in both of these mindsets. > > Posterity hugely prefers that we see it the second way; yet here we are in > the present tense and we have to get something working and deliver it. Is > that the conflict we're having? > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121012/e3d1f77b/attachment.html From sam at sampullara.com Mon Oct 15 09:06:40 2012 From: sam at sampullara.com (Sam Pullara) Date: Mon, 15 Oct 2012 09:06:40 -0700 Subject: Diamonds: cyclic inference error In-Reply-To: <507C22C0.9030309@oracle.com> References: <507C1BF5.8050900@oracle.com> <507C22C0.9030309@oracle.com> Message-ID: I'm disappointed this doesn't work by the spec. I've seen a few cases like this where <> and lambda don't really mix. Anything we can do about it so that statements like this one are properly inferred? Sam On Mon, Oct 15, 2012 at 7:50 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > On 15/10/12 15:21, Aleksey Shipilev wrote: > > Hi guys, and Maurizio specifically :) > > > > This is the test which fails to compile with current lambda/lambda: > > > > ------------- 8< ------------------------------------------------------- > > > > public class NoiseSampleTest { > > > > @Test > > public void testL() { > > Map> map = > > new ComputeTreeMap<>( > > (s) -> new ComputeTreeMap<>( > > (x) -> new Counter() > > ) > > ); > > > > Assert.assertEquals(1, map.get("foo").get("bar").inc()); > > Assert.assertEquals(2, map.get("foo").get("bar").inc()); > > } > > > > public static class ComputeTreeMap extends TreeMap { > > > > public ComputeTreeMap(Mapper map) { > > // do nothing > > } > > > > @Override > > public V get(Object key) { > > throw new UnsupportedOperationException(); > > } > > } > > > > public static class Counter { > > private int count = 0; > > public int inc() { > > return ++count; > > } > > } > > } > > > > -------------- 8< ---------------------------------------------------- > > > > javac says: > > com/oracle/lambda/NoiseSampleTest.java:[16,16] error: cannot infer type > > arguments for ComputeTreeMap<> > > [ERROR] cyclic inference - cannot infer target type for given > > lambda/method reference expression > > > > ...and if I write out the explicit type arguments within the diamond, > > the test compiles well. Is this a spec-ed behavior, or just a bug? > This is the spec'd behavior, yes. You are passing an implicit lambda to > a method where the target type contains inference variables (because of > diamond). Which means javac doesn't know what the lambda parameter types > should be inferred to. Javac would try to delay type-checking of the > lambda expression as much as possible (to see if other inference > constraints can be derived from remaining argument expression) - but in > this case there's no additional arguments. Either you specify the type > of the diamond, or you specify the explicit lambda parameter type. > > Maurizio > > > > -Aleksey. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121015/38994b59/attachment.html From maurizio.cimadamore at oracle.com Mon Oct 15 09:10:03 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 15 Oct 2012 17:10:03 +0100 Subject: Diamonds: cyclic inference error In-Reply-To: References: <507C1BF5.8050900@oracle.com> <507C22C0.9030309@oracle.com> Message-ID: <507C355B.9010001@oracle.com> On 15/10/12 17:06, Sam Pullara wrote: > I'm disappointed this doesn't work by the spec. I've seen a few cases > like this where <> and lambda don't really mix. Anything we can do > about it so that statements like this one are properly inferred? We are currently discussing more complete solutions, such as having a better inference strategy (which you can already experiment with using the flag -XDuseGraphInference), to better out-of-order method checking logic. Maurizio > > Sam > > On Mon, Oct 15, 2012 at 7:50 AM, Maurizio Cimadamore > > wrote: > > On 15/10/12 15:21, Aleksey Shipilev wrote: > > Hi guys, and Maurizio specifically :) > > > > This is the test which fails to compile with current lambda/lambda: > > > > ------------- 8< > ------------------------------------------------------- > > > > public class NoiseSampleTest { > > > > @Test > > public void testL() { > > Map> map = > > new ComputeTreeMap<>( > > (s) -> new ComputeTreeMap<>( > > (x) -> new Counter() > > ) > > ); > > > > Assert.assertEquals(1, map.get("foo").get("bar").inc()); > > Assert.assertEquals(2, map.get("foo").get("bar").inc()); > > } > > > > public static class ComputeTreeMap extends TreeMap { > > > > public ComputeTreeMap(Mapper map) { > > // do nothing > > } > > > > @Override > > public V get(Object key) { > > throw new UnsupportedOperationException(); > > } > > } > > > > public static class Counter { > > private int count = 0; > > public int inc() { > > return ++count; > > } > > } > > } > > > > -------------- 8< > ---------------------------------------------------- > > > > javac says: > > com/oracle/lambda/NoiseSampleTest.java:[16,16] error: cannot > infer type > > arguments for ComputeTreeMap<> > > [ERROR] cyclic inference - cannot infer target type for given > > lambda/method reference expression > > > > ...and if I write out the explicit type arguments within the > diamond, > > the test compiles well. Is this a spec-ed behavior, or just a bug? > This is the spec'd behavior, yes. You are passing an implicit > lambda to > a method where the target type contains inference variables > (because of > diamond). Which means javac doesn't know what the lambda parameter > types > should be inferred to. Javac would try to delay type-checking of the > lambda expression as much as possible (to see if other inference > constraints can be derived from remaining argument expression) - > but in > this case there's no additional arguments. Either you specify the type > of the diamond, or you specify the explicit lambda parameter type. > > Maurizio > > > > -Aleksey. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121015/93b6429d/attachment.html From daniel.smith at oracle.com Mon Oct 15 13:36:24 2012 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 15 Oct 2012 14:36:24 -0600 Subject: Named lambdas (was Re: Serialization stability and naming (and syntax)) In-Reply-To: References: <201210121454.q9CEsVUC014833@monge.univ-mlv.fr> Message-ID: <6E172DC8-BF66-4254-B955-178C6FECE589@oracle.com> Agreed that the method parameter name isn't very obvious or useful (plus, it introduces a cross-source dependency). But for the debugging use case, I'm not concerned about naming lambdas passed to methods at all. If you're debugging, this code: int monthlySalary = deductTaxes(annualSalary/12); payMe(monthlySalary); is more informative than this code: payMe(deductTaxes(annualSalary/12)); Whether you're watching the value of 'monthlySalary', or want to log it, or setting a breakpoint, or whatever, it's best to designate it as a "value of interest" by giving it a name, and you do this with a variable declaration. In other words, subexpressions (including lambdas as subexpressions) are meant for values that aren't of enough interest to merit giving them names. ?Dan On Oct 12, 2012, at 9:36 AM, Brian Goetz wrote: > In both cases we would still have to deal with ambiguity, which is worse in the method param case. > > Sent from my iPhone > > On Oct 12, 2012, at 3:54 PM, Remi Forax wrote: > >> We can use the name of the parameter of the method. The parameter name is stored in the bytecode by java 8 and available in local variable table (if the symbols are not striped) if the bytecode version is < 8 >> >> R?mi >> >> Sent from my Phone >> >> ----- Reply message ----- >> From: "Brian Goetz" >> To: "Kevin Bourrillion" >> Cc: >> Subject: Named lambdas (was Re: Serialization stability and naming (and syntax)) >> Date: Fri, Oct 12, 2012 16:33 >> >> >> I assume you're talking about lambda names now, and not recursion? >> >> If so, this works for lambdas assigned to locals but not to lambdas passed to methods. >> >> On Oct 12, 2012, at 3:06 PM, Kevin Bourrillion wrote: >> >>> Huh. Can it be that simple? This works for me if no one else sees a problem with it! >>> >>> >>> On Tue, Oct 9, 2012 at 10:30 AM, Dan Smith wrote: >>> The approach we settled on for names for recursive lambdas was to use the targeted variable name: >>> >>> IntOp fact = x -> { >>> if (x == 0) return 1; >>> else return x*fact.apply(x-1); >>> }; >>> >>> That also seems like a useful, unobtrusive way to give a lambda a name for debugging. If somebody cares about readable names for debugging, they'll probably also care about readable names in code, and the way you name something in code is assign it to a variable. >>> >>> Of course there will be cases where we'd need the name to be "fact$2" or something, but for a best-effort problem like debugging hints, that seems good enough. >>> >>> ?Dan >>> >>> On Oct 9, 2012, at 9:40 AM, Kevin Bourrillion wrote: >>> >>>> Okay, so the benefits of user-provided names seem to be >>>> >>>> - More readable toString and stack traces than the auto-provided name (lambda#8 or whatever) >>>> - A very small (as noted by Brian) potential to make serialization usable across code changes in a few more situations >>>> - It should apparently help hot-swapping to be usable in a few more situations >>>> >>>> Anything else? >>>> >>>> If we come up with some syntax for users to name individual lambda expressions, do we think these benefits are great enough that enough users will name their lambdas enough of the time to get real benefit? I'm unsure. Even though lambdas are way more concise than classes, this supreme terseness of lambda expressions is sort of intoxicating and I wonder if most users will get drunk on that and not want any extra characters that weren't strictly required. >>>> >>>> Likewise, to the extent that any of the advantages can also be realized by switching to a method reference, do we think enough users will actually be willing to make that switch? >>>> >>>> >>>> On Sun, Oct 7, 2012 at 11:44 AM, Andrey Breslav wrote: >>>> I would like to point out one thing that somehow keeps escaping our discussions of this matter. >>>> >>>> Although for some people serialization is the biggest concern here, for a lot more people a much bigger concern is hot-swapping, where name stability is very important as well. >>>> >>>> In my mind, this requires us to reconsider the arguments for having/not having stable names/signatures where we could have that. >>>> >>>> -- >>>> Andrey Breslav >>>> http://jetbrains.com >>>> Develop with pleasure! >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com >>>> >>> >>> >>> >>> >>> -- >>> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121015/d5c6a45f/attachment.html From forax at univ-mlv.fr Mon Oct 15 15:12:44 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 16 Oct 2012 00:12:44 +0200 Subject: Serialization opt-in syntax (summary) In-Reply-To: References: <5065F0C6.4000509@oracle.com> <50670199.8070805@univ-mlv.fr> <5073BF34.5000207@univ-mlv.fr> <5074293C.6000902@redhat.com> <507435BD.1000702@univ-mlv.fr> <50743C03.2040308@redhat.com> <50744A75.7070500@univ-mlv.fr> <50783487.90908@redhat.com> <3CFF5874-A601-42EA-9A24-CBB69F6ADEEF@oracle.com> Message-ID: <507C8A5C.2020000@univ-mlv.fr> On 10/12/2012 08:17 PM, Brian Goetz wrote: > I believe this option was on the list on the issue tracker? > > Sent from my iPhone How do you want to implement that ? Patch the compiler and the spec to emit an invokedynamic when wrap() is called ? R?mi > > On Oct 12, 2012, at 5:31 PM, Sam Pullara > wrote: > >> Crazy idea. Can we just make it a method call that wraps up the lamba >> in a wrapper that can be serialized? We could add the static method >> to Serializable: >> >> Callable r = Serializable.wrap(() -> true); >> >> It may have to be a little magical (not unlike serialization) but at >> least it is obvious and doesn't introduce anything new. You could >> even include the name if you want to make them more robust: >> >> Callable r = Serializable.wrap("My True Callable", () -> true); >> >> Sam >> >> On Fri, Oct 12, 2012 at 9:06 AM, Brian Goetz > > wrote: >> >> I don't even agree that posterity would prefer it the other way, >> since there still are inner classes and many users have learned >> to deal with the frustrating interaction between inner classes >> and serialization. A more accurate statement is that posterity >> would have preferred we not make the mistakes of the past the >> first time, but absent a time machine, we're kind of stuck there. >> >> In any case, I don't think "lambdas cannot be serializable" is a >> realistic option at this point. Users will expect: >> >> SerializablePredicate p = x -> true >> >> to be serializable -- and entirely reasonably so. We made a >> commitment to SAM conversion a long time ago, and part of that is >> users should not have to reason about "how was this SAM >> constructed -- did it come from a lambda or a class?" Otherwise >> it is a leaky abstraction. Yes, serialization sucks -- and we're >> copying the suckage mode that users have spent 15 years getting >> used to. But that 15 years of user community experience matters >> -- users have learned how to deal with the limitations, and there >> is a lot of value in not asking users to learn new and different >> limitations (especially those that punish the users who learned >> to live within the old limitations.) >> >> The EG took a poll on this at the July meeting last year, and was >> unanimously in favor of the "weak serialization" target. David >> wasn't at that meeting, which is too bad, but I just don't see >> enough new evidence to reopen this issue now. >> >> However, we can and should spend our effort on "how can we make >> things as good as we can subject to the 'no worse than inner >> classes' rubric. I suggest we redirect our efforts towards that. >> Choosing a less-brittle translation strategy is a good place to >> start. >> >> On Oct 12, 2012, at 4:46 PM, Kevin Bourrillion wrote: >> >>> On 10/12/2012 09:37 AM, Brian Goetz wrote: >>> >>> I keep going back to the rubric of "no worse than inner >>> classes." >>> >>> >>> On Fri, Oct 12, 2012 at 8:17 AM, David M. Lloyd >>> > wrote: >>> >>> And I keep going back to "making the mistake once does not >>> justify making it again"... >>> >>> >>> Ha. I completely see the sense in both of these mindsets. >>> >>> Posterity hugely prefers that we see it the second way; yet here >>> we are in the present tense and we have to get something working >>> and deliver it. Is that the conflict we're having? >>> >>> -- >>> Kevin Bourrillion | Java Librarian | Google, >>> Inc. |kevinb at google.com >>> >> >> From brian.goetz at oracle.com Sun Oct 21 06:45:50 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 21 Oct 2012 09:45:50 -0400 Subject: [jsr-335-eg] Default method survey results In-Reply-To: <5036A278.9050609@univ-mlv.fr> References: <5026DC3E.7050506@oracle.com> <5036A278.9050609@univ-mlv.fr> Message-ID: <5083FC8E.8080808@oracle.com> On 8/23/2012 5:36 PM, R?mi Forax wrote: > I think it > will be better to not use "default" as keyword name to avoid confusion > with default access visibility rules. > What about "alternative", "second", "else", "defender" ? And one obvious one we forgot (which was the one we started with!): extension void foo() { ... } From andrey.breslav at jetbrains.com Sun Oct 21 06:54:32 2012 From: andrey.breslav at jetbrains.com (Andrey Breslav) Date: Sun, 21 Oct 2012 17:54:32 +0400 Subject: [jsr-335-eg] Default method survey results In-Reply-To: <5083FC8E.8080808@oracle.com> References: <5026DC3E.7050506@oracle.com> <5036A278.9050609@univ-mlv.fr> <5083FC8E.8080808@oracle.com> Message-ID: <9C2CC817-FDCE-4CAA-9BDC-A58A5C97FE22@jetbrains.com> > On 8/23/2012 5:36 PM, R?mi Forax wrote: >> I think it >> will be better to not use "default" as keyword name to avoid confusion >> with default access visibility rules. >> What about "alternative", "second", "else", "defender" ? > > And one obvious one we forgot (which was the one we started with!): > > extension void foo() { ? } It think this one is very misleading. Those who knew the term before, would think this is not what it actually is. Those who didn't know the term before will be OK until they come across the same word in the different context. Let's avoid this confusion. It is almost as bad as saying that Java 8 has traits. -- Andrey Breslav http://jetbrains.com Develop with pleasure! From brian.goetz at oracle.com Sun Oct 21 07:03:26 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 21 Oct 2012 10:03:26 -0400 Subject: [jsr-335-eg] Default method survey results In-Reply-To: <9C2CC817-FDCE-4CAA-9BDC-A58A5C97FE22@jetbrains.com> References: <5026DC3E.7050506@oracle.com> <5036A278.9050609@univ-mlv.fr> <5083FC8E.8080808@oracle.com> <9C2CC817-FDCE-4CAA-9BDC-A58A5C97FE22@jetbrains.com> Message-ID: <508400AE.5000006@oracle.com> >> And one obvious one we forgot (which was the one we started with!): >> >> extension void foo() { ? } > > It think this one is very misleading. Those who knew the term before, would think this is not what it actually is. > Those who didn't know the term before will be OK until they come across the same word in the different context. > Let's avoid this confusion. I get your point, but just because C# happened to come up with something they decided to call extension methods a few years ago, doesn't mean that extension methods must be inherently use-site or static or otherwise like C#'s interpretation. The core concept of after-the-fact extension is what counts; the mechanism (monkey-patching vs accretion) and the specific characteristics (static vs virtual) differ, but these are details -- if C# had virtual extension methods, they still would probably call them extension methods. > It is almost as bad as saying that Java 8 has traits. Fortress had stateless traits; these were just as much real traits as Scala's stateful traits. People who know one language don't notice; people who know more are used to the same concept (e.g., class) meaning slightly different things in different languages. Other opinions? For all its faults, is "default" better than "extension"? From forax at univ-mlv.fr Sun Oct 21 11:43:39 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 21 Oct 2012 20:43:39 +0200 Subject: [jsr-335-eg] Default method survey results In-Reply-To: <508400AE.5000006@oracle.com> References: <5026DC3E.7050506@oracle.com> <5036A278.9050609@univ-mlv.fr> <5083FC8E.8080808@oracle.com> <9C2CC817-FDCE-4CAA-9BDC-A58A5C97FE22@jetbrains.com> <508400AE.5000006@oracle.com> Message-ID: <5084425B.2060709@univ-mlv.fr> On 10/21/2012 04:03 PM, Brian Goetz wrote: >>> And one obvious one we forgot (which was the one we started with!): >>> >>> extension void foo() { ? } >> >> It think this one is very misleading. Those who knew the term before, >> would think this is not what it actually is. >> Those who didn't know the term before will be OK until they come >> across the same word in the different context. >> Let's avoid this confusion. > > I get your point, but just because C# happened to come up with > something they decided to call extension methods a few years ago, > doesn't mean that extension methods must be inherently use-site or > static or otherwise like C#'s interpretation. The core concept of > after-the-fact extension is what counts; the mechanism > (monkey-patching vs accretion) and the specific characteristics > (static vs virtual) differ, but these are details -- if C# had virtual > extension methods, they still would probably call them extension methods. Eclipse codebase coins the term extension interface for implementing virtual extension methods (or delegate methods BTW) before C# introduced its extension methods mechanism. Also Java enum are not C enum but provide the very same concept even if the implementation is different. > >> It is almost as bad as saying that Java 8 has traits. > > Fortress had stateless traits; these were just as much real traits as > Scala's stateful traits. People who know one language don't notice; > people who know more are used to the same concept (e.g., class) > meaning slightly different things in different languages. Right, Java 'traits' are more traits than Scala one because the common definition of traits say they are stateless. > > Other opinions? For all its faults, is "default" better than > "extension"? > I prefer 'extension' because for once Java will not reuse a keyword for another meaning, default is already used to specifying default value of an annotation elements. R?mi From brian.goetz at oracle.com Mon Oct 22 09:18:44 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 22 Oct 2012 12:18:44 -0400 Subject: Announcement: converting JSR-335 to JCP 2.8 Message-ID: <508571E4.8070804@oracle.com> JSR-335 was originally submitted in November 2010, under the rules of JCP 2.7. When JCP 2.8 (JSR 348) was approved in October 2011 [1], Oracle publicly committed to convert all in-flight JSRs led by Oracle to JCP 2.8. To satisfy the transparency requirements of JCP 2.8 for Java SE JSRs we had to update the OpenJDK Terms of Use, which required spending lots of quality time with attorneys. That was finally done this past July [2]. JCP 2.8 also requires us to have a public issue tracker, but the OpenJDK JIRA system isn't available yet [3][4]. I've therefore set up an issue tracker on java.net [5]; we may migrate issues from that system to the OpenJDK system when the latter becomes available, depending on timing. To convert an existing JSR to JCP 2.8, requires answering a set of questions posed by the JCP PMO [6]. Appended below are our answers to those questions. All members of the JSR-335 EG have agreed to the change to JCP 2.8, having indicated their consent on the lambda-spec-experts list. Answers to JCP 2.8 conversion questions for JSR 337 (http://jcp.org/en/resources/change_jcp_version) What is the specific URL for the document archive? http://openjdk.java.net/projects/lambda What is the specific URL for the Issue Tracker? http://java.net/jira/browse/JSR_335 What is the specific URL for the EG communication archive? http://mail.openjdk.java.net/pipermail/lambda-spec-experts/ http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/ What is the description of your communications channel/how the public should provide feedback? We have set up "comments" aliases: lambda-libs-spec-comments at openjdk.java.net (libraries) lambda-spec-comments at openjdk.java.net (language) The archives of these are public. How will you consult with the Expert Group of your JSR on new Expert Group nominations? I will ask if anyone has anything to say for or against an incoming nomination. How will you provide details of the Expert Group nominations for your JSR to the public? Details will be provided on the publicly-readable EG list. [1] https://blogs.oracle.com/pcurran/entry/no_more_smoke_filled_rooms [2] http://openjdk.java.net/legal/tou/ [3] http://mail.openjdk.java.net/pipermail/announce/2012-March/000120.html [4] https://blogs.oracle.com/darcy/entry/moving_monarchs_dragons [5] http://java.net/jira/browse/JSR_335 [6] http://jcp.org/en/resources/change_jcp_version