From srikanth_sankaran at in.ibm.com Fri Mar 1 09:47:33 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Fri, 1 Mar 2013 23:17:33 +0530 Subject: Part G - Concerns. In-Reply-To: References: <51117DC2.9080108@univ-mlv.fr> <702F711B-D89E-4F94-9111-5EA9411BD42B@oracle.com> <0B3A2563-14C8-4B63-BED4-14DBFFD049F8@oracle.com> <9D360112-4A58-4D4F-8878-B1F670D07743@oracle.com> Message-ID: Good morning. We have heard three responses to the concerns raised about the unfinished state of Part G: Taking the liberty of summarizing/paraphrasing, here they are: (1) Maurizio pointed us to the source code for javac as a means of understanding the gaps. This option unfortunately is not available to Eclipse developers. (2) Dan replied saying that the unfinished sections are being actively worked on and a new version that much more complete will be available soon. (3) Brian responded saying, yes, parts are unfinished, but what exists in the specification should allow an implementation to undertake/schedule a good amount of work as it is. Thanks for the responses. We are proceeding with Parts F (significant progress made already - at the moment, haven't found gaps in the specification here) and Part G (if/when we hit a hard wall, we will raise specific concerns) To state the obvious, we do expect that a finished/nearly finished version is made available early enough that we can review, raise issues/concerns, understand the implementation ramifications and be able to discuss them at the EG well ahead of the public review. For our part, we promise to treat the review of this part as top priority once a finished version becomes available. Thank you, Srikanth. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20130301/4969e853/attachment.html From daniel.smith at oracle.com Fri Mar 1 10:51:56 2013 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 1 Mar 2013 11:51:56 -0700 Subject: JSR 335 Lambda Specification, 0.6.2 Message-ID: <5DD2850A-F043-4460-B3AA-097D73B40825@oracle.com> An updated specification can be found here: http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.2/ Other links Diff: http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.2-diff.html One-page HTML: http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.2.html Downloadable zip: http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.2.zip This fills in many of the missing pieces in Part G, Type Inference. Full change log, from the document: > Functional Interfaces: Renamed the term functional interface type to just function type, to avoid the assumption that intersection types are excluded from this set. Defined the descriptor of a raw functional interface type. Minor fixes in examples to reflect actual compiler behavior. Adjusted the definition of return-type substitutability to reflect actual compiler behavior. > > Lambda Expressions: Small change to the scoping rules of local classes to avoid confusion. > > Method References: Added a number of well-formedness checks for method references (some new, some previously covered by the compatibility definition). Adjusted terminology so that "method references" refers generally to both "constructor references" and "array creation references". > > Poly Expressions: Incorporated above terminology changes. Added section 15.29, which is just a renumbering of 15.28. > > Typing and Evaluation: Added a lambda compatibility rule that errors do not occur in the lambda body. Made the check for static-ness of a referenced method a post-compatibility error. Removed mention of "synthetic" classes and methods, to clarify that the ACC_SYNTHETIC flag is not mandated. Unified the presentation of "compile-time declarations"/runtime behavior for standard method references, constructor references, and array creation references?the latter two are based on "notional methods" that represent class instance creation or array creation. Moved the error check for exceptions in lambda bodies to 11.2.3. > > Overload Resolution: Changed definition of "potentially compatible" for method references to exclude cases in which there are no method declarations of the desired arity. Defined provisionally-applicable methods to never be more specific rather than always more specific (the outcome should be the same, though). Unified the presentation of "more specific" for fixed-arity and variable-arity methods. > > Type Inference: Specified reduction for subtyping and equality constraints. Specified incorporation. Specified resolution. Updated reduction rules for lambdas and method references to track changes in "Typing and Evaluation." Adjusted terminology so that "bound" refers to all of "proper bounds", "dependencies", and "delayed constraint formulas". Made tweaks to the notation for constraint formulas and bounds. > > Default Methods: Removed support for an explicit package access modifier. Refined the definition of overriding to more accurately represent the intended behavior when the overriding method is inherited (mostly to account for package-access methods). > > Java Virtual Machine: Changed the representation of methods declared in interfaces and passed to invokespecial/invokestatic from a Methodref to an InterfaceMethodref. Rolled back changes that were intended to support Methodref structures that point to methods declared in interfaces. ?Dan From daniel.smith at oracle.com Fri Mar 1 13:07:56 2013 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 1 Mar 2013 14:07:56 -0700 Subject: Java 7 -> Java8 code breakage scenarios In-Reply-To: References: <452ED23A-4228-4A2C-A1AA-0C323CE3485E@oracle.com> <51251BDA.8050305@oracle.com> <51253C96.4030109@oracle.com> <2E447BAC-0344-4579-AA3F-27BC62FBB049@oracle.com> Message-ID: I think we might be maintaining a full list somewhere; I'll investigate. I think you've pretty much covered the main issues. Off the top of my head: - API changes via default methods can cause compile-time clashes; not a new problem (same can happen with new methods in classes), but default methods encourage API changes. - Inference changes may cause a recompiled expression to have a different type, triggering downstream errors or overload resolution changes. This includes diamond class instance creation and method invocation. We're generally more accommodating of different target types, which means this might most often manifest itself as an ambiguity error or a "better" overload resolution choice. - There are some VM changes that will lead to different behavior where there's currently an Error thrown (not observable under consistent compilation from Java source). ?Dan On Feb 27, 2013, at 10:41 AM, Srikanth S Adayapalam wrote: > Is there a list of scenarios documented somewhere that enumerates the > situations under which a valid Java 7 program will either (a) cease to > be a valid Java 8 program (b) or will exhibit a different behavior ? > > Looks like default methods clash can cause (a) and the (unlikely) usage > of diamond inference usage in method arguments can cause (b). > > I would be curious to see what other cases exist. > > TIA, > Srikanth. From brian.goetz at oracle.com Sun Mar 3 12:11:45 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 03 Mar 2013 15:11:45 -0500 Subject: JSR 335 Lambda Specification, 0.6.2 In-Reply-To: <5DD2850A-F043-4460-B3AA-097D73B40825@oracle.com> References: <5DD2850A-F043-4460-B3AA-097D73B40825@oracle.com> Message-ID: <5133AE81.70600@oracle.com> A few quick q's: > Diff: > http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.2-diff.html Diff against which version? 0.6.1? >> Functional Interfaces: Renamed the term functional interface type >> to just function type If we were to add structural function types in Java 10 or later, would this terminology become a problem? >> Default Methods: Removed support for an explicit package access >> modifier. Refined the definition of overriding to more accurately >> represent the intended behavior when the overriding method is >> inherited (mostly to account for package-access methods). Did we ever circle back to compare the inheritance rules in the spec with the FD model? I recall that there were definitely gaps in the super-call handling of FD -- are there any other known gaps for which we should at least call out differences, if not update FD itself? From forax at univ-mlv.fr Sun Mar 3 23:43:13 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 04 Mar 2013 08:43:13 +0100 Subject: JSR 335 Lambda Specification, 0.6.2 In-Reply-To: <5133AE81.70600@oracle.com> References: <5DD2850A-F043-4460-B3AA-097D73B40825@oracle.com> <5133AE81.70600@oracle.com> Message-ID: <51345091.4030601@univ-mlv.fr> On 03/03/2013 09:11 PM, Brian Goetz wrote: > A few quick q's: > > > Diff: >> http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.2-diff.html > > Diff against which version? 0.6.1? > >>> Functional Interfaces: Renamed the term functional interface type >>> to just function type > > If we were to add structural function types in Java 10 or later, would > this terminology become a problem? yes, it may become a problem. R?mi From daniel.smith at oracle.com Mon Mar 4 10:52:55 2013 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 4 Mar 2013 11:52:55 -0700 Subject: JSR 335 Lambda Specification, 0.6.2 In-Reply-To: <5133AE81.70600@oracle.com> References: <5DD2850A-F043-4460-B3AA-097D73B40825@oracle.com> <5133AE81.70600@oracle.com> Message-ID: <9C122CD5-066D-4A99-AFE9-0D11F5549719@oracle.com> On Mar 3, 2013, at 1:11 PM, Brian Goetz wrote: > A few quick q's: > > > Diff: >> http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.2-diff.html > > Diff against which version? 0.6.1? Yes, 0.6.1. >>> Functional Interfaces: Renamed the term functional interface type >>> to just function type > > If we were to add structural function types in Java 10 or later, would this terminology become a problem? I'm open to alternative suggestions. The previous attempt, "functional interface type," didn't work, because the term needs to include some intersection types; generally, "foo interface type" is interpreted as "an interface with property foo, possibly parameterized or raw" -- so I was fighting against that intuition. "Function descriptor" should also be part of this discussion -- it's inspired by the VM's use of "descriptor" to refer to the parameter and return types of a method, but it's a very specialized concept (for example, a VM "descriptor" is always erased), and I'm not sure it's wise to try to repurpose it here. "Signature" probably doesn't work -- that refers to parameter types only (well, and type parameters) in JLS, and the generic equivalent of a descriptor+throws clause in the VM (oy). Since a "function descriptor" is a kind of "type of a method" (JLS 8.2), it might make sense to use "function type" or "functional method type" here? Some possible combinations of terms the might work: - "Function type" is the general term for types that can be targeted by lambdas. Among these are functional interface types, intersections involving function types, and [insert name here] (structural function types). Separately, "function descriptor" can be renamed however is preferred. - "Function type" is a structural function type. A lambda can target a [insert name here], which may be a function type, a functional interface type, or an intersection involving a [insert name again]. Separately, "function descriptor" can be renamed however is preferred. - "Function type" consists of the parameters, return, etc., of a method. Functional interfaces "have" a function type (other interfaces and classes do not). Syntax supports expressing certain function types directly. Lambdas can target any type that "has a" function type, including functional interface types, intersections involving types that have a function type, and function types themselves. >>> Default Methods: Removed support for an explicit package access >>> modifier. Refined the definition of overriding to more accurately >>> represent the intended behavior when the overriding method is >>> inherited (mostly to account for package-access methods). > > Did we ever circle back to compare the inheritance rules in the spec with the FD model? I recall that there were definitely gaps in the super-call handling of FD -- are there any other known gaps for which we should at least call out differences, if not update FD itself? (The changes I made here are strictly related to overriding by inheritance and package access. So, outside of the scope of FD, I believe. The goal was to preserve JLS 7 semantics while re-expressing and clarifying how overriding is defined.) If I remember correctly, what was missing from FD was - Acknowledgement that sometimes a superinterface is reached through a superclass - Accounting for the possibility that, for a super call, an interface method may be overridden by a class method - Treatment of plain 'super.m' when it refers to an interface method I still have some notes to revisit some of this, since we weren't sure how to apply the restrictions on super calls to interface methods when there is a superclass involved. ?Dan From brian.goetz at oracle.com Mon Mar 4 11:32:00 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 04 Mar 2013 14:32:00 -0500 Subject: JSR 335 Lambda Specification, 0.6.2 In-Reply-To: <9C122CD5-066D-4A99-AFE9-0D11F5549719@oracle.com> References: <5DD2850A-F043-4460-B3AA-097D73B40825@oracle.com> <5133AE81.70600@oracle.com> <9C122CD5-066D-4A99-AFE9-0D11F5549719@oracle.com> Message-ID: <5134F6B0.7000103@oracle.com> > Some possible combinations of terms the might work: > > - "Function type" is the general term for types that can be targeted > by lambdas. Among these are functional interface types, > intersections involving function types, and [insert name here] > (structural function types). Separately, "function descriptor" can > be renamed however is preferred. > > - "Function type" is a structural function type. A lambda can target > a [insert name here], which may be a function type, a functional > interface type, or an intersection involving a [insert name again]. > Separately, "function descriptor" can be renamed however is > preferred. > > - "Function type" consists of the parameters, return, etc., of a > method. Functional interfaces "have" a function type (other > interfaces and classes do not). Syntax supports expressing certain > function types directly. Lambdas can target any type that "has a" > function type, including functional interface types, intersections > involving types that have a function type, and function types > themselves. The last seems the best choice? It is basically an "abstract superterm" for function types, of which functional interfaces, certain intersections, and in the future, structural function types will be instances. Then we can leave the current functional interface term intact? From daniel.smith at oracle.com Tue Mar 5 11:19:56 2013 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 5 Mar 2013 12:19:56 -0700 Subject: JSR 335 Lambda Specification, 0.6.2 In-Reply-To: <5134F6B0.7000103@oracle.com> References: <5DD2850A-F043-4460-B3AA-097D73B40825@oracle.com> <5133AE81.70600@oracle.com> <9C122CD5-066D-4A99-AFE9-0D11F5549719@oracle.com> <5134F6B0.7000103@oracle.com> Message-ID: On Mar 4, 2013, at 12:32 PM, Brian Goetz wrote: >> Some possible combinations of terms the might work: >> >> - "Function type" is the general term for types that can be targeted >> by lambdas. Among these are functional interface types, >> intersections involving function types, and [insert name here] >> (structural function types). Separately, "function descriptor" can >> be renamed however is preferred. >> >> - "Function type" is a structural function type. A lambda can target >> a [insert name here], which may be a function type, a functional >> interface type, or an intersection involving a [insert name again]. >> Separately, "function descriptor" can be renamed however is >> preferred. >> >> - "Function type" consists of the parameters, return, etc., of a >> method. Functional interfaces "have" a function type (other >> interfaces and classes do not). Syntax supports expressing certain >> function types directly. Lambdas can target any type that "has a" >> function type, including functional interface types, intersections >> involving types that have a function type, and function types >> themselves. > > The last seems the best choice? It is basically an "abstract superterm" for function types, of which functional interfaces, certain intersections, and in the future, structural function types will be instances. You're describing the first one: FunctionType: one of Functional interface type Intersection [Insert name here] = "structural function type" The second one looks like: [Insert name here]: one of Functional interface type Intersection Function type The third one looks like: A type that "has a" function type: one of Functional interface type Intersection Function type (i.e., the "function type of T" relation is reflexive) > Then we can leave the current functional interface term intact? The 0.6.1 presentation was to use "functional interface type" as the top-level thing. That was an abuse of the convention, and didn't work very well. All of these alternatives instead use "functional interface type" as it should naturally be interpreted: a functional interface, or parameterized/raw version of one. Where the knobs are: - What do we call the top-level thing? - What do we call a structural function type (anticipating that someday we might want to call it something)? - We do we call the thing currently referred to as the "function descriptor"? ?Dan From brian.goetz at oracle.com Mon Mar 11 11:49:49 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 11 Mar 2013 14:49:49 -0400 Subject: Fwd: hg: lambda/lambda/langtools: Enhancement: more stable serialized lambda names In-Reply-To: References: <20130207193045.C0DCC478E7@hg.openjdk.java.net> <511401E2.6070802@oracle.com> Message-ID: <513E274D.90202@oracle.com> Fixed as suggested. On 3/8/2013 10:32 AM, Daniel Heidinga wrote: > "Method names are further constrained so that, with the exception of the > special method names and (?2.9), they must not contain the > (Unicode code points corresponding to the) ASCII characters '<' or '>'." > -- JVMS 4.2.2 Unqualified Names > > There are two special cases that this naming system falls down on: > static initializers and constructors. The names & will > need to be changed when forming the 'lambda$mmm$kkkk$nnn' method name. > I like the following remapping: -> 'static' & -> 'new'. > > ========== BadLambdaName.java ========== > import java.io.Serializable; > import java.util.concurrent.Callable; > > public class BadLambdaName { > public static Callable staticPublicLambda; > Callable constructorLambda; > > static { > staticPublicLambda = (Callable & Serializable) () -> { return > "staticPublicLambda"; }; > } > > public BadLambdaName() { > constructorLambda = (Callable & Serializable) () -> { return > "constructorLambda"; }; > } > > > public static void main(String[] args) { > throw new Error("Class should not have verified"); > } > } > =================================== > > Generates the following illegal names: > private static java.lang.String lambda$$39797$0() throws > java.lang.Exception; > private static java.lang.String lambda$$39797$0() throws > java.lang.Exception; > > --Dan > > Inactive hide details for Brian Goetz ---02/07/2013 02:36:56 PM---This > is now implemented. The more complex convention is onlyBrian Goetz > ---02/07/2013 02:36:56 PM---This is now implemented. The more complex > convention is only used for serializable lambdas. > > > From: > > > Brian Goetz > > To: > > > "lambda-spec-experts at openjdk.java.net" > > > Date: > > > 02/07/2013 02:36 PM > > Subject: > > > Fwd: hg: lambda/lambda/langtools: Enhancement: more stable serialized > lambda names > > Sent by: > > > lambda-spec-experts-bounces at openjdk.java.net > > ------------------------------------------------------------------------ > > > > This is now implemented. The more complex convention is only used for > serializable lambdas. > > > -------- Original Message -------- > Subject: hg: lambda/lambda/langtools: Enhancement: more stable > serialized lambda names > Date: Thu, 07 Feb 2013 19:30:41 +0000 > From: maurizio.cimadamore at oracle.com > To: lambda-dev at openjdk.java.net > > Changeset: 7bffb45844fb > Author: mcimadamore > Date: 2013-02-07 19:30 +0000 > URL: > http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7bffb45844fb > > Enhancement: more stable serialized lambda names > > Serializable lambdas are desugared to methods where name follows > following pattern: > > lambda$mmm$kkkk$nnn > > where mmm is the method name and kkk is the hashcode of the method > signature, and nnn is a sequentially assigned number. That way, > dependencies on lambdas from other methods will be minimized. > > ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java > > > > > > From srikanth_sankaran at in.ibm.com Tue Mar 19 19:10:04 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Tue, 19 Mar 2013 22:10:04 -0400 Subject: Lingering old syntax In-Reply-To: References: <51117DC2.9080108@univ-mlv.fr> <702F711B-D89E-4F94-9111-5EA9411BD42B@oracle.com> <0B3A2563-14C8-4B63-BED4-14DBFFD049F8@oracle.com> <9D360112-4A58-4D4F-8878-B1F670D07743@oracle.com> Message-ID: jsr335-0.6.2 - H15.12.1 The "Discussion and motivation" box contains an example with outdated syntax ("default" at wrong position): interface Superinterface { void foo() default { System.out.println ("Hi"); } } Thanks! Srikanth. From daniel.smith at oracle.com Tue Mar 19 10:37:49 2013 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 19 Mar 2013 11:37:49 -0600 Subject: Lingering old syntax In-Reply-To: References: <51117DC2.9080108@univ-mlv.fr> <702F711B-D89E-4F94-9111-5EA9411BD42B@oracle.com> <0B3A2563-14C8-4B63-BED4-14DBFFD049F8@oracle.com> <9D360112-4A58-4D4F-8878-B1F670D07743@oracle.com> Message-ID: <2CACD064-E82C-4B94-A9B2-3B04BF3C7C77@oracle.com> Thanks, fixed. ?Dan On Mar 19, 2013, at 8:10 PM, Srikanth S Adayapalam wrote: > jsr335-0.6.2 - H15.12.1 > > The "Discussion and motivation" box contains an example with outdated > syntax ("default" at wrong position): > interface Superinterface { void foo() default { System.out.println > ("Hi"); } } > > Thanks! > Srikanth. > From stephan.herrmann at berlin.de Thu Mar 21 10:48:17 2013 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Thu, 21 Mar 2013 18:48:17 +0100 Subject: JSR 335 Lambda Specification, 0.6.2 In-Reply-To: <9C122CD5-066D-4A99-AFE9-0D11F5549719@oracle.com> References: <5DD2850A-F043-4460-B3AA-097D73B40825@oracle.com> <5133AE81.70600@oracle.com> <9C122CD5-066D-4A99-AFE9-0D11F5549719@oracle.com> Message-ID: <514B47E1.3030507@berlin.de> > This fills in many of the missing pieces in Part G, Type Inference. Let me start by saying that this version of the spec is a big step towards dispelling my previous concerns. After implementing most of Part G in the Eclipse compiler I can confirm that the inference works well as specified, but some concerns remain. Let me illustrate the status by some test figures: I'm using one particular chapter of our test suite that is likely to trigger interesting inference issues. Total number of tests: 1493 Regressions when using new type inference: 159 Of these 159 regressions the majority (111) can be directly ascribed to the following TODOs in the spec, section 18.2.3: "To do: define the parameterization of a class C for a type T; define the most specific array supertype of a type T." Could you give an ETA for a fix to these TODOs? In this case an informal sketch would already be quite helpful. Additionally, I could use a minor clarification on the following items from 18.4.: " * If ?i has one or more proper lower bounds, L1, ..., Lk, then Ti = lub(L1, ..., Lk). * Otherwise, where ?i has proper upper bounds U1, ..., Uk, Ti = glb(U1, ..., Uk)." These items don't explicitly specify how mixed proper and improper bounds should be handled. I assume for this part to apply, *all* bounds of the given kind must be proper bounds, right? I first interpreted this as a filter on the set of bounds, but that seems to yield bogus results. regards, Stephan From daniel.smith at oracle.com Fri Mar 22 15:59:38 2013 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 22 Mar 2013 16:59:38 -0600 Subject: JSR 335 Lambda Specification, 0.6.2 In-Reply-To: <514B47E1.3030507@berlin.de> References: <5DD2850A-F043-4460-B3AA-097D73B40825@oracle.com> <5133AE81.70600@oracle.com> <9C122CD5-066D-4A99-AFE9-0D11F5549719@oracle.com> <514B47E1.3030507@berlin.de> Message-ID: <2EAEDC51-B0B5-4F00-8052-088FF78CCDC4@oracle.com> On Mar 21, 2013, at 11:48 AM, Stephan Herrmann wrote: > > This fills in many of the missing pieces in Part G, Type Inference. > > Let me start by saying that this version of the spec is a big step > towards dispelling my previous concerns. After implementing most > of Part G in the Eclipse compiler I can confirm that the inference > works well as specified, but some concerns remain. Glad to have another implementation, and to hear that the initial effort was not too bumpy. > Let me illustrate the status by some test figures: > I'm using one particular chapter of our test suite that is likely > to trigger interesting inference issues. > Total number of tests: 1493 > Regressions when using new type inference: 159 > > Of these 159 regressions the majority (111) can be directly > ascribed to the following TODOs in the spec, section 18.2.3: > > "To do: define the parameterization of a class C for a type T; > define the most specific array supertype of a type T." > > Could you give an ETA for a fix to these TODOs? In this case > an informal sketch would already be quite helpful. This is a long-standing problem with JLS. See, for example, from JLS 7 15.12.2.7: "If F has the form G<..., Yk-1, U, Yk+1, ...>, where U is a type expression that involves Tj, then if A has a supertype of the formG<..., Xk-1, V, Xk+1, ...> where V is a type expression, this algorithm is applied recursively to the constraint V = U." The phrase "has a supertype" doesn't bother to explain how this supertype is derived. Add wildcards to the mix, and it's a bit of a mess. In practice, this has typically been handled by capturing A and recurring on its supertype, but that can lead to some unsound results, where new capture variables end up as inference variable bounds. The goal here is to come up with a well-defined, sound alternative. But in the mean time, whatever you were doing for Java 7 should continue to work as an approximation, and I wouldn't expect any regressions. Pretty much the same comment for the array supertype, although in that case I don't think there are any really interesting problems to tackle. The Java 7 spec just doesn't do a very good job with things like intersection types, variables with variable bounds, etc. > Additionally, I could use a minor clarification on the following > items from 18.4.: > > " > * If ?i has one or more proper lower bounds, L1, ..., Lk, then Ti = lub(L1, ..., Lk). > * Otherwise, where ?i has proper upper bounds U1, ..., Uk, Ti = glb(U1, ..., Uk)." > > These items don't explicitly specify how mixed proper and improper > bounds should be handled. I assume for this part to apply, *all* > bounds of the given kind must be proper bounds, right? > I first interpreted this as a filter on the set of bounds, but > that seems to yield bogus results. It should be a filter. The subset of bounds that are proper bounds are used, and the rest are ignored. Then you test (via incorporation) whether this choice actually satisfies all the bounds, and if it does, great. If not, you proceed to the next step, which performs a capture-like operation to create a type variable representing the solution. Keep in mind that the order in which variables are resolved should have the effect of turning dependencies (alpha <: Foo) into proper bounds (alpha <: Foo) before you get to this point. The only time that doesn't work is when there are circular dependencies (alpha <: Foo, beta <: Bar -- or just alpha <: Foo). This area -- what if there are inference variables in the bounds? -- has been a mess in JLS and javac, with various attempts to patch it. So I wouldn't be surprised if Eclipse's current behavior is pretty ad hoc. ?Dan