From jan.lahoda at oracle.com  Tue Oct  8 12:32:51 2013
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 08 Oct 2013 21:32:51 +0200
Subject: Enabling/disabling asserts in interface default methods
Message-ID: <52545DE3.4030604@oracle.com>

(Noted by Jon Gibbons and discussed with Alex Buckley.)

JLS for Java SE 7, 14.10 (The assert Statement) is talking about 
top-level classes:

   An assert statement that is executed after its class has completed
   initialization is enabled if and only if the host system has
   determined that the top level class that lexically contains the
   assert statement enables assertions.

Looking at JSR335-0.6.3, there appears to be no update to this. As 
interface methods may contain code now, they may also contain the assert 
statement. So it might be good to update the spec to also cover 
interfaces in addition to classes.

Jan

From jon.rafkind at hp.com  Tue Oct 29 12:11:07 2013
From: jon.rafkind at hp.com (Rafkind, Jon)
Date: Tue, 29 Oct 2013 19:11:07 +0000
Subject: clarification of 18.2.3
Message-ID: <C39D17F71FB39E488EA35B99FB027447126BA829@G9W0743.americas.hpqcorp.net>

Section 18.2.3 Subtyping Constraints of jsr 335 says

A constraint formula of the form ?S <: T? is reduced as follows:
  ...
  If T is a non-parameterized class or interface type, C, then the constraint reduces to true if S is a parameterization of C, or if C is a superclass or superinterface of T, and false otherwise.

1. What is the point of introducing a new metavariable C? It seems that C == T
2. I assume the point of this rule is to handle the case where a type has T does not have type parameters even though its class declaration has them:

List<a1> <: List

Where a1 is some inference variable. In this case, any parameterization of List is a subtype of List. Is that right?

3. The last clause seems vacuous. 'if C is a superclass/superinterface of T' but C == T, so assuming superclass/superinterface means a proper super then C can never be its own super type. Also this leaves S out. Is it a typo, and it should instead read as

'or if C is a superclass or superinterface of S ...'

Which would handle the case of

List<a1> <: Collection




From daniel.smith at oracle.com  Tue Oct 29 13:36:19 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 29 Oct 2013 14:36:19 -0600
Subject: clarification of 18.2.3
In-Reply-To: <C39D17F71FB39E488EA35B99FB027447126BA829@G9W0743.americas.hpqcorp.net>
References: <C39D17F71FB39E488EA35B99FB027447126BA829@G9W0743.americas.hpqcorp.net>
Message-ID: <BCB8952A-6470-4C83-AB5B-8658E8391884@oracle.com>

On Oct 29, 2013, at 1:11 PM, "Rafkind, Jon" <jon.rafkind at hp.com> wrote:

> Section 18.2.3 Subtyping Constraints of jsr 335 says
> 
> A constraint formula of the form ?S <: T? is reduced as follows:
>  ...
>  If T is a non-parameterized class or interface type, C, then the constraint reduces to true if S is a parameterization of C, or if C is a superclass or superinterface of T, and false otherwise.
> 
> 1. What is the point of introducing a new metavariable C? It seems that C == T

Just a stylistic thing to distinguish general types from classes.  But you're probably right that it would be better to avoid the extra variable.

> 2. I assume the point of this rule is to handle the case where a type has T does not have type parameters even though its class declaration has them:
> 
> List<a1> <: List
> 
> Where a1 is some inference variable. In this case, any parameterization of List is a subtype of List. Is that right?

Yes.

> 3. The last clause seems vacuous. 'if C is a superclass/superinterface of T' but C == T, so assuming superclass/superinterface means a proper super then C can never be its own super type. Also this leaves S out. Is it a typo, and it should instead read as
> 
> 'or if C is a superclass or superinterface of S ...'
> 
> Which would handle the case of
> 
> List<a1> <: Collection

Yes, it's a typo.  Thanks for noting it.

?Dan