From jesper.oqvist at cs.lth.se  Thu May  5 08:06:57 2011
From: jesper.oqvist at cs.lth.se (=?ISO-8859-1?Q?Jesper_=D6qvist?=)
Date: Thu, 05 May 2011 17:06:57 +0200
Subject: Diamond and Generic Methods
Message-ID: <4DC2BD11.4000902@cs.lth.se>

So, after searching the archives and scouring the JSR334 v0.875 draft, I 
have a question about Diamond. While the specification draft does not 
explicitly disallow it, it seems weird that this works (Java7 developer 
preview b139):

class C {
<T> void identity(T a) { return a; }
   void m() {
     identity(new java.util.ArrayList<>());
   }
}

Since there is a distinction between raw types and parameterized types 
with inferred type arguments (in the discussion part of the Diamond 
section in JSR334), it would be interesting to know what type is 
instantiated in the above example.

/Jesper


From maurizio.cimadamore at oracle.com  Thu May  5 08:18:19 2011
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 05 May 2011 16:18:19 +0100
Subject: Diamond and Generic Methods
In-Reply-To: <4DC2BD11.4000902@cs.lth.se>
References: <4DC2BD11.4000902@cs.lth.se>
Message-ID: <4DC2BFBB.3010707@oracle.com>

On 05/05/11 16:06, Jesper ?qvist wrote:
> So, after searching the archives and scouring the JSR334 v0.875 draft, I
> have a question about Diamond. While the specification draft does not
> explicitly disallow it, it seems weird that this works (Java7 developer
> preview b139):
>
> class C {
> <T>  void identity(T a) { return a; }
>     void m() {
>       identity(new java.util.ArrayList<>());
>     }
> }
>
> Since there is a distinction between raw types and parameterized types
> with inferred type arguments (in the discussion part of the Diamond
> section in JSR334), it would be interesting to know what type is
> instantiated in the above example.
Hi
The above code is equivalent to the following:

class C {
static<Z>  ArrayList<Z>  makeArrayList() { return new ArrayList<Z>(); }

<T>  void identity(T a) { return a; }
    void m() {
      identity(makeArrayList());
    }
}

In both cases, an ArrayList<Object> is created - note that, because of 
the restrictions in Java method type-inference, the information on 
formal argument type is not used to infer a better type. In this 
particular case it might not seem a big problem, but in the following 
case you  get a compile-time error:

class C {
static<Z>  ArrayList<Z>  makeArrayList() { return new ArrayList<Z>(); }

<T>  T identity(T a) { return a; }
    void m() {
      //error - ArrayList<Object>  found - expected ArrayList<String>
      ArrayList<String>  s = identity(makeArrayList());
    }
}


Maurizio

> /Jesper
>



From pbenedict at apache.org  Thu May  5 08:34:53 2011
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 5 May 2011 10:34:53 -0500
Subject: Diamond and Generic Methods
In-Reply-To: <4DC2BFBB.3010707@oracle.com>
References: <4DC2BD11.4000902@cs.lth.se>
	<4DC2BFBB.3010707@oracle.com>
Message-ID: <BANLkTini=TOrk8zE7uK4o_tc80QR5Ap6Gg@mail.gmail.com>

That's interesting. Because inference is supposed to be a help to
explicit parametrization....

This would be obviously rejected by the compiler:
identity(new java.util.ArrayList<T>());

Yet, as the compiler knows, the inference says T is Object so use Object.

While totally understandable, I also think that will be a learning
curve for some people. Java 5 taught lots of people that you can't
instantiate using <T> but the new Java 7 code can give the appearance
you suddenly can.

Paul

On Thu, May 5, 2011 at 10:18 AM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> On 05/05/11 16:06, Jesper ?qvist wrote:
>> So, after searching the archives and scouring the JSR334 v0.875 draft, I
>> have a question about Diamond. While the specification draft does not
>> explicitly disallow it, it seems weird that this works (Java7 developer
>> preview b139):
>>
>> class C {
>> <T> ?void identity(T a) { return a; }
>> ? ? void m() {
>> ? ? ? identity(new java.util.ArrayList<>());
>> ? ? }
>> }
>>
>> Since there is a distinction between raw types and parameterized types
>> with inferred type arguments (in the discussion part of the Diamond
>> section in JSR334), it would be interesting to know what type is
>> instantiated in the above example.
> Hi
> The above code is equivalent to the following:
>
> class C {
> static<Z> ?ArrayList<Z> ?makeArrayList() { return new ArrayList<Z>(); }
>
> <T> ?void identity(T a) { return a; }
> ? ?void m() {
> ? ? ?identity(makeArrayList());
> ? ?}
> }
>
> In both cases, an ArrayList<Object> is created - note that, because of
> the restrictions in Java method type-inference, the information on
> formal argument type is not used to infer a better type. In this
> particular case it might not seem a big problem, but in the following
> case you ?get a compile-time error:
>
> class C {
> static<Z> ?ArrayList<Z> ?makeArrayList() { return new ArrayList<Z>(); }
>
> <T> ?T identity(T a) { return a; }
> ? ?void m() {
> ? ? ?//error - ArrayList<Object> ?found - expected ArrayList<String>
> ? ? ?ArrayList<String> ?s = identity(makeArrayList());
> ? ?}
> }
>
>
> Maurizio
>
>> /Jesper
>>
>
>
>


From Ulf.Zibis at gmx.de  Thu May  5 08:42:26 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 05 May 2011 17:42:26 +0200
Subject: Diamond and Generic Methods
In-Reply-To: <4DC2BD11.4000902@cs.lth.se>
References: <4DC2BD11.4000902@cs.lth.se>
Message-ID: <4DC2C562.4000503@gmx.de>

Am 05.05.2011 17:06, schrieb Jesper ?qvist:
> So, after searching the archives and scouring the JSR334 v0.875 draft, I
> have a question about Diamond. While the specification draft does not
> explicitly disallow it, it seems weird that this works (Java7 developer
> preview b139):
>
> class C {
> <T>  void identity(T a) { return a; }

Hm, is it correct, that a void method can return a value ?

-Ulf

>     void m() {
>       identity(new java.util.ArrayList<>());
>     }
> }
>
> Since there is a distinction between raw types and parameterized types
> with inferred type arguments (in the discussion part of the Diamond
> section in JSR334), it would be interesting to know what type is
> instantiated in the above example.
>
> /Jesper
>
>


From jesper.oqvist at cs.lth.se  Thu May  5 09:31:15 2011
From: jesper.oqvist at cs.lth.se (=?ISO-8859-1?Q?Jesper_=D6qvist?=)
Date: Thu, 05 May 2011 18:31:15 +0200
Subject: Diamond and Generic Methods
In-Reply-To: <4DC2C562.4000503@gmx.de>
References: <4DC2BD11.4000902@cs.lth.se> <4DC2C562.4000503@gmx.de>
Message-ID: <4DC2D0D3.2010108@cs.lth.se>

On 2011-05-05 17:42, Ulf Zibis wrote:
> Am 05.05.2011 17:06, schrieb Jesper ?qvist:
>> So, after searching the archives and scouring the JSR334 v0.875 draft, I
>> have a question about Diamond. While the specification draft does not
>> explicitly disallow it, it seems weird that this works (Java7 developer
>> preview b139):
>>
>> class C {
>> <T>  void identity(T a) { return a; }
>
> Hm, is it correct, that a void method can return a value ?
>
> -Ulf

Well d'oh!
In my test case I had the equivalent of

<T> T identity(T a) { return a; }

I cleaned it up to make it as concise as possible to post it here on the 
mailing list and replaced that T for a void by mistake.

/Jesper

>
>>     void m() {
>>       identity(new java.util.ArrayList<>());
>>     }
>> }
>>
>> Since there is a distinction between raw types and parameterized types
>> with inferred type arguments (in the discussion part of the Diamond
>> section in JSR334), it would be interesting to know what type is
>> instantiated in the above example.
>>
>> /Jesper
>>
>>



From daniel.smith at oracle.com  Thu May  5 12:04:00 2011
From: daniel.smith at oracle.com (Dan Smith)
Date: Thu, 5 May 2011 12:04:00 -0700
Subject: Diamond and Generic Methods
In-Reply-To: <BANLkTini=TOrk8zE7uK4o_tc80QR5Ap6Gg@mail.gmail.com>
References: <4DC2BD11.4000902@cs.lth.se> <4DC2BFBB.3010707@oracle.com>
	<BANLkTini=TOrk8zE7uK4o_tc80QR5Ap6Gg@mail.gmail.com>
Message-ID: <38C681BF-E849-4B10-9480-42DC14CE24A5@oracle.com>

Paul,

I'm not quite sure what your concern is.  But, whatever it is, it is orthogonal to diamond.  As Maurizio's example demonstrates, any instance creation expression using diamond ('new Foo<>') can be re-expressed as an invocation of a generic method ('makeFoo()').  Inference in both cases behaves the same.

Taking a stab at it, I think you're saying inference chooses 'T' as the type argument for 'new ArrayList<>' (or has "the appearance" of choosing 'T').  This is incorrect.  Inference chooses 'Object' as the type argument.

?Dan

On May 5, 2011, at 8:34 AM, Paul Benedict wrote:

> That's interesting. Because inference is supposed to be a help to
> explicit parametrization....
> 
> This would be obviously rejected by the compiler:
> identity(new java.util.ArrayList<T>());
> 
> Yet, as the compiler knows, the inference says T is Object so use Object.
> 
> While totally understandable, I also think that will be a learning
> curve for some people. Java 5 taught lots of people that you can't
> instantiate using <T> but the new Java 7 code can give the appearance
> you suddenly can.
> 
> Paul
> 
> On Thu, May 5, 2011 at 10:18 AM, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> On 05/05/11 16:06, Jesper ?qvist wrote:
>>> So, after searching the archives and scouring the JSR334 v0.875 draft, I
>>> have a question about Diamond. While the specification draft does not
>>> explicitly disallow it, it seems weird that this works (Java7 developer
>>> preview b139):
>>> 
>>> class C {
>>> <T>  void identity(T a) { return a; }
>>>     void m() {
>>>       identity(new java.util.ArrayList<>());
>>>     }
>>> }
>>> 
>>> Since there is a distinction between raw types and parameterized types
>>> with inferred type arguments (in the discussion part of the Diamond
>>> section in JSR334), it would be interesting to know what type is
>>> instantiated in the above example.
>> Hi
>> The above code is equivalent to the following:
>> 
>> class C {
>> static<Z>  ArrayList<Z>  makeArrayList() { return new ArrayList<Z>(); }
>> 
>> <T>  void identity(T a) { return a; }
>>    void m() {
>>      identity(makeArrayList());
>>    }
>> }
>> 
>> In both cases, an ArrayList<Object> is created - note that, because of
>> the restrictions in Java method type-inference, the information on
>> formal argument type is not used to infer a better type. In this
>> particular case it might not seem a big problem, but in the following
>> case you  get a compile-time error:
>> 
>> class C {
>> static<Z>  ArrayList<Z>  makeArrayList() { return new ArrayList<Z>(); }
>> 
>> <T>  T identity(T a) { return a; }
>>    void m() {
>>      //error - ArrayList<Object>  found - expected ArrayList<String>
>>      ArrayList<String>  s = identity(makeArrayList());
>>    }
>> }
>> 
>> 
>> Maurizio
>> 
>>> /Jesper
>>> 
>> 
>> 
>> 
> 



From pbenedict at apache.org  Thu May  5 12:08:22 2011
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 5 May 2011 14:08:22 -0500
Subject: Diamond and Generic Methods
In-Reply-To: <38C681BF-E849-4B10-9480-42DC14CE24A5@oracle.com>
References: <4DC2BD11.4000902@cs.lth.se> <4DC2BFBB.3010707@oracle.com>
	<BANLkTini=TOrk8zE7uK4o_tc80QR5Ap6Gg@mail.gmail.com>
	<38C681BF-E849-4B10-9480-42DC14CE24A5@oracle.com>
Message-ID: <BANLkTimrLWvkggK-ciGd10npWU0uhpFJbg@mail.gmail.com>

On Thu, May 5, 2011 at 2:04 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> Taking a stab at it, I think you're saying inference chooses 'T' as the type argument for 'new ArrayList<>' (or has "the appearance" of choosing 'T').

I think you understand my concern for the most part. I was just
expressing my opinion that I think most people would read this:

identity(new java.util.ArrayList<>());

..as a shorthand for..

identity(new java.util.ArrayList<T>());

... and not make the mental leap that they are really doing:

identity(new java.util.ArrayList<Object>());

Diamond's inference is being sold as a shortcut.. so we may find out
it exposes mental shortcuts too :-)

Paul


From maurizio.cimadamore at oracle.com  Thu May  5 12:28:39 2011
From: maurizio.cimadamore at oracle.com (maurizio cimadamore)
Date: Thu, 05 May 2011 20:28:39 +0100
Subject: Diamond and Generic Methods
In-Reply-To: <BANLkTimrLWvkggK-ciGd10npWU0uhpFJbg@mail.gmail.com>
References: <4DC2BD11.4000902@cs.lth.se>
	<4DC2BFBB.3010707@oracle.com>	<BANLkTini=TOrk8zE7uK4o_tc80QR5Ap6Gg@mail.gmail.com>	<38C681BF-E849-4B10-9480-42DC14CE24A5@oracle.com>
	<BANLkTimrLWvkggK-ciGd10npWU0uhpFJbg@mail.gmail.com>
Message-ID: <4DC2FA67.1020701@oracle.com>

On 05/05/2011 20:08, Paul Benedict wrote:
> On Thu, May 5, 2011 at 2:04 PM, Dan Smith<daniel.smith at oracle.com>  wrote:
>> Taking a stab at it, I think you're saying inference chooses 'T' as the type argument for 'new ArrayList<>' (or has "the appearance" of choosing 'T').
> I think you understand my concern for the most part. I was just
> expressing my opinion that I think most people would read this:
>
> identity(new java.util.ArrayList<>());
>
> ..as a shorthand for..
>
> identity(new java.util.ArrayList<T>());
Uhm, not sure I get what you are saying, T is not even in scope at that 
point!

Maurizio
> ... and not make the mental leap that they are really doing:
>
> identity(new java.util.ArrayList<Object>());
>
> Diamond's inference is being sold as a shortcut.. so we may find out
> it exposes mental shortcuts too :-)
>
> Paul
>



From joe.darcy at oracle.com  Fri May  6 15:50:00 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Fri, 06 May 2011 15:50:00 -0700
Subject: Specification update: diamond and explicit generic constructor
	argument no longer supported
Message-ID: <4DC47B18.2020102@oracle.com>

Hello.

To address an issue in the specification, the JSR 334 expert group has 
decided to ban the combination of diamond together with explicit 
constructor type arguments. For background, a constructor can have two 
sets of type arguments. In a parameterized class, constructors can have 
type arguments corresponding to the class's type parameters. This is the 
common case and the type arguments appear to the right of the class name 
and "new" as in "new ArrayList<String>()". In addition, if a constructor 
declares its very own type parameters (which can be done whether or not 
the enclosing class is parameterized), then those type arguments appear 
between the "new" token and the class name as in "new <Integer> 
ConstructorWithTypeParameter(Integer.valueOf(42))".

As with generic methods, the type arguments of generic constructors are 
usually inferred and not explicitly passed. However, generic 
constructors are much less common than generic methods.

After the specification change, using diamond to infer the class type 
parameters but explicitly passing the constructor type parameters is 
forbidden. However, the other three combinations of explicitly passing 
type arguments versus inferring them are supported, as shown in the 
table below.

class Foo<T extends Number> {
      <S extends T> Foo(S s) {super();}
}

Class      C'tor        Supported   Example
Explicit   Explicit     Yes         new <Integer> Foo<Number>(null);
Explicit   Inferred     Yes        new Foo<>(null);
Inferred   Explicit     No         new <Integer> Foo<>(null); // compile 
error
Inferred   Inferred    Yes        new Foo<>(null);

The substitution that was used to formally describe the semantics of 
diamond did not fully propagate constraints if there was a typing 
relationship between the type parameters of the constructor and the type 
parameters of the class. Lifting the imposed restriction on the banned 
combination of explicit and inferred type arguments can be revisited in 
future work in the context of broader type inference getting added to 
the Java language.

Since generic constructors are so uncommon, adding this restriction 
about combining them with diamond should have little effect to most 
programs. For example, none of the uses of diamond in the JDK had to be 
updated as a result of this change. A changeset implementing this 
specification change has been pushed [1] and will appear in subsequent 
promoted builds of JDK 7.

-Joe

[1] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4caf17560ae0


From joe.darcy at oracle.com  Fri May  6 15:54:06 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 06 May 2011 15:54:06 -0700
Subject: IDE support for Project Coin
In-Reply-To: <4DB0DDA2.2090107@oracle.com>
References: <4DB0DDA2.2090107@oracle.com>
Message-ID: <4DC47C0E.9040200@oracle.com>

Additional information on planned Eclipse support for JDK 7:
http://thecoderlounge.blogspot.com/2011/05/eclipse-jdt-and-java-7.html

-Joe

Joe Darcy wrote:
> FYI, all of NetBeans, IntelliJ, and Eclipse have some level of support 
> in progress for Project Coin's language features.
>
> The recently released NetBeans 7.0 [1]  has support for all the Coin 
> features.  As explained in its release notes [2], beyond just 
> recognizing the features in the editor NetBeans 7.0 provides 
> auto-completion to diamond and gives hints to apply the new features to 
> existing code.
>
> As previously announced for IntelliJ IDEA [3], the builds of IDEA 10.5 
> EAP (early access program) [4] provide similar quickfix support.
>
> Finally, an Eclipse branch [5] is hosting their efforts to support 
> Project Coin.
>
> As JSR 334 is not quite done yet [6], I'd expect the IDEs to be updated 
> after JSR 334 is completed to account for any specification changes made 
> in the interim.
>
> Happy hacking,
>
> -Joe
>
> [1] http://netbeans.org/community/releases/70/
> [2] http://wiki.netbeans.org/NewAndNoteworthyNB70#JDK7_support
> [3] 
> http://blogs.jetbrains.com/idea/2011/02/announcing-intellij-idea-105-with-full-java-7-support/
> [4] http://confluence.jetbrains.net/display/IDEADEV/IDEA+10.5+EAP
> [5] http://wiki.eclipse.org/JDT_Core/Java7
> [6] http://blogs.sun.com/darcy/entry/project_coin_jsr_334_pr
>
>
>   



From neal at gafter.com  Fri May  6 16:10:54 2011
From: neal at gafter.com (Neal Gafter)
Date: Fri, 6 May 2011 16:10:54 -0700
Subject: Specification update: diamond and explicit generic constructor
	argument no longer supported
In-Reply-To: <4DC47B18.2020102@oracle.com>
References: <4DC47B18.2020102@oracle.com>
Message-ID: <BANLkTim8ySzHhWBN1oHKC_q9GqyjmEzgeA@mail.gmail.com>

I've never seen a generic constructor outside of test code, so it is
hard to imagine anyone finding this restriction burdensome.

On Fri, May 6, 2011 at 3:50 PM,  <joe.darcy at oracle.com> wrote:
> Hello.
>
> To address an issue in the specification, the JSR 334 expert group has
> decided to ban the combination of diamond together with explicit
> constructor type arguments. For background, a constructor can have two
> sets of type arguments. In a parameterized class, constructors can have
> type arguments corresponding to the class's type parameters. This is the
> common case and the type arguments appear to the right of the class name
> and "new" as in "new ArrayList<String>()". In addition, if a constructor
> declares its very own type parameters (which can be done whether or not
> the enclosing class is parameterized), then those type arguments appear
> between the "new" token and the class name as in "new <Integer>
> ConstructorWithTypeParameter(Integer.valueOf(42))".
>
> As with generic methods, the type arguments of generic constructors are
> usually inferred and not explicitly passed. However, generic
> constructors are much less common than generic methods.
>
> After the specification change, using diamond to infer the class type
> parameters but explicitly passing the constructor type parameters is
> forbidden. However, the other three combinations of explicitly passing
> type arguments versus inferring them are supported, as shown in the
> table below.
>
> class Foo<T extends Number> {
> ? ? ?<S extends T> Foo(S s) {super();}
> }
>
> Class ? ? ?C'tor ? ? ? ?Supported ? Example
> Explicit ? Explicit ? ? Yes ? ? ? ? new <Integer> Foo<Number>(null);
> Explicit ? Inferred ? ? Yes ? ? ? ?new Foo<>(null);
> Inferred ? Explicit ? ? No ? ? ? ? new <Integer> Foo<>(null); // compile
> error
> Inferred ? Inferred ? ?Yes ? ? ? ?new Foo<>(null);
>
> The substitution that was used to formally describe the semantics of
> diamond did not fully propagate constraints if there was a typing
> relationship between the type parameters of the constructor and the type
> parameters of the class. Lifting the imposed restriction on the banned
> combination of explicit and inferred type arguments can be revisited in
> future work in the context of broader type inference getting added to
> the Java language.
>
> Since generic constructors are so uncommon, adding this restriction
> about combining them with diamond should have little effect to most
> programs. For example, none of the uses of diamond in the JDK had to be
> updated as a result of this change. A changeset implementing this
> specification change has been pushed [1] and will appear in subsequent
> promoted builds of JDK 7.
>
> -Joe
>
> [1] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4caf17560ae0
>
>


From forax at univ-mlv.fr  Fri May  6 16:17:51 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 07 May 2011 01:17:51 +0200
Subject: Specification update: diamond and explicit generic constructor
	argument no longer supported
In-Reply-To: <BANLkTim8ySzHhWBN1oHKC_q9GqyjmEzgeA@mail.gmail.com>
References: <4DC47B18.2020102@oracle.com>
	<BANLkTim8ySzHhWBN1oHKC_q9GqyjmEzgeA@mail.gmail.com>
Message-ID: <4DC4819F.3050801@univ-mlv.fr>

On 05/07/2011 01:10 AM, Neal Gafter wrote:
> I've never seen a generic constructor outside of test code, so it is
> hard to imagine anyone finding this restriction burdensome.

I have used one once, it wanted to use a parametrized class
that inherits from Exception, because it was not possible,
I, at least, check that the two arguments of the constructor were coherent.

R?mi

> On Fri, May 6, 2011 at 3:50 PM,<joe.darcy at oracle.com>  wrote:
>> Hello.
>>
>> To address an issue in the specification, the JSR 334 expert group has
>> decided to ban the combination of diamond together with explicit
>> constructor type arguments. For background, a constructor can have two
>> sets of type arguments. In a parameterized class, constructors can have
>> type arguments corresponding to the class's type parameters. This is the
>> common case and the type arguments appear to the right of the class name
>> and "new" as in "new ArrayList<String>()". In addition, if a constructor
>> declares its very own type parameters (which can be done whether or not
>> the enclosing class is parameterized), then those type arguments appear
>> between the "new" token and the class name as in "new<Integer>
>> ConstructorWithTypeParameter(Integer.valueOf(42))".
>>
>> As with generic methods, the type arguments of generic constructors are
>> usually inferred and not explicitly passed. However, generic
>> constructors are much less common than generic methods.
>>
>> After the specification change, using diamond to infer the class type
>> parameters but explicitly passing the constructor type parameters is
>> forbidden. However, the other three combinations of explicitly passing
>> type arguments versus inferring them are supported, as shown in the
>> table below.
>>
>> class Foo<T extends Number>  {
>>       <S extends T>  Foo(S s) {super();}
>> }
>>
>> Class      C'tor        Supported   Example
>> Explicit   Explicit     Yes         new<Integer>  Foo<Number>(null);
>> Explicit   Inferred     Yes        new Foo<>(null);
>> Inferred   Explicit     No         new<Integer>  Foo<>(null); // compile
>> error
>> Inferred   Inferred    Yes        new Foo<>(null);
>>
>> The substitution that was used to formally describe the semantics of
>> diamond did not fully propagate constraints if there was a typing
>> relationship between the type parameters of the constructor and the type
>> parameters of the class. Lifting the imposed restriction on the banned
>> combination of explicit and inferred type arguments can be revisited in
>> future work in the context of broader type inference getting added to
>> the Java language.
>>
>> Since generic constructors are so uncommon, adding this restriction
>> about combining them with diamond should have little effect to most
>> programs. For example, none of the uses of diamond in the JDK had to be
>> updated as a result of this change. A changeset implementing this
>> specification change has been pushed [1] and will appear in subsequent
>> promoted builds of JDK 7.
>>
>> -Joe
>>
>> [1] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4caf17560ae0
>>
>>



From howard.lovatt at gmail.com  Fri May  6 16:30:24 2011
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Sat, 7 May 2011 09:30:24 +1000
Subject: Specification update: diamond and explicit generic constructor
	argument no longer supported
In-Reply-To: <4DC47B18.2020102@oracle.com>
References: <4DC47B18.2020102@oracle.com>
Message-ID: <BANLkTins=ft8r=jFvf4=Wgqn+GuHrp4+_w@mail.gmail.com>

I can't see this restriction as a problem, I have never seen one used.

In you table I think you have a minor typo, did you mean

Explicit   Inferred     Yes        new Foo<Number>(null);

instead of

Explicit   Inferred     Yes        new Foo<>(null);

 -- Howard.

On 7 May 2011 08:50, <joe.darcy at oracle.com> wrote:

> Hello.
>
> To address an issue in the specification, the JSR 334 expert group has
> decided to ban the combination of diamond together with explicit
> constructor type arguments. For background, a constructor can have two
> sets of type arguments. In a parameterized class, constructors can have
> type arguments corresponding to the class's type parameters. This is the
> common case and the type arguments appear to the right of the class name
> and "new" as in "new ArrayList<String>()". In addition, if a constructor
> declares its very own type parameters (which can be done whether or not
> the enclosing class is parameterized), then those type arguments appear
> between the "new" token and the class name as in "new <Integer>
> ConstructorWithTypeParameter(Integer.valueOf(42))".
>
> As with generic methods, the type arguments of generic constructors are
> usually inferred and not explicitly passed. However, generic
> constructors are much less common than generic methods.
>
> After the specification change, using diamond to infer the class type
> parameters but explicitly passing the constructor type parameters is
> forbidden. However, the other three combinations of explicitly passing
> type arguments versus inferring them are supported, as shown in the
> table below.
>
> class Foo<T extends Number> {
>      <S extends T> Foo(S s) {super();}
> }
>
> Class      C'tor        Supported   Example
> Explicit   Explicit     Yes         new <Integer> Foo<Number>(null);
> Explicit   Inferred     Yes        new Foo<>(null);
> Inferred   Explicit     No         new <Integer> Foo<>(null); // compile
> error
> Inferred   Inferred    Yes        new Foo<>(null);
>
> The substitution that was used to formally describe the semantics of
> diamond did not fully propagate constraints if there was a typing
> relationship between the type parameters of the constructor and the type
> parameters of the class. Lifting the imposed restriction on the banned
> combination of explicit and inferred type arguments can be revisited in
> future work in the context of broader type inference getting added to
> the Java language.
>
> Since generic constructors are so uncommon, adding this restriction
> about combining them with diamond should have little effect to most
> programs. For example, none of the uses of diamond in the JDK had to be
> updated as a result of this change. A changeset implementing this
> specification change has been pushed [1] and will appear in subsequent
> promoted builds of JDK 7.
>
> -Joe
>
> [1] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4caf17560ae0
>
>


-- 
  -- Howard.


From joe.darcy at oracle.com  Fri May  6 16:37:15 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 06 May 2011 16:37:15 -0700
Subject: Specification update: diamond and explicit generic constructor
	argument no longer supported
In-Reply-To: <BANLkTins=ft8r=jFvf4=Wgqn+GuHrp4+_w@mail.gmail.com>
References: <4DC47B18.2020102@oracle.com>
	<BANLkTins=ft8r=jFvf4=Wgqn+GuHrp4+_w@mail.gmail.com>
Message-ID: <4DC4862B.2010804@oracle.com>

Howard Lovatt wrote:
> I can't see this restriction as a problem, I have never seen one used.
>
> In you table I think you have a minor typo, did you mean
>
> Explicit   Inferred     Yes        new Foo<Number>(null);
>
> instead of
>
> Explicit   Inferred     Yes        new Foo<>(null);

Yes; thanks for the correction.

-Joe



From brucechapman at paradise.net.nz  Mon May  9 01:16:13 2011
From: brucechapman at paradise.net.nz (Bruce Chapman)
Date: Mon, 09 May 2011 20:16:13 +1200
Subject: Specification update: diamond and explicit generic constructor
	argument no longer supported
In-Reply-To: <4DC4819F.3050801@univ-mlv.fr>
References: <4DC47B18.2020102@oracle.com>
	<BANLkTim8ySzHhWBN1oHKC_q9GqyjmEzgeA@mail.gmail.com>
	<4DC4819F.3050801@univ-mlv.fr>
Message-ID: <4DC7A2CD.4060708@paradise.net.nz>

On 7/05/2011 11:17 a.m., R?mi Forax wrote:
> On 05/07/2011 01:10 AM, Neal Gafter wrote:
>> I've never seen a generic constructor outside of test code, so it is
>> hard to imagine anyone finding this restriction burdensome.
> I have used one once, it wanted to use a parametrized class
> that inherits from Exception, because it was not possible,
> I, at least, check that the two arguments of the constructor were coherent.
>
> R?mi
>
So I would suppose that inference would work fine in that case, and you 
don't need to use an explicit type argument.

Bruce
>> On Fri, May 6, 2011 at 3:50 PM,<joe.darcy at oracle.com>   wrote:
>>> Hello.
>>>
>>> To address an issue in the specification, the JSR 334 expert group has
>>> decided to ban the combination of diamond together with explicit
>>> constructor type arguments. For background, a constructor can have two
>>> sets of type arguments. In a parameterized class, constructors can have
>>> type arguments corresponding to the class's type parameters. This is the
>>> common case and the type arguments appear to the right of the class name
>>> and "new" as in "new ArrayList<String>()". In addition, if a constructor
>>> declares its very own type parameters (which can be done whether or not
>>> the enclosing class is parameterized), then those type arguments appear
>>> between the "new" token and the class name as in "new<Integer>
>>> ConstructorWithTypeParameter(Integer.valueOf(42))".
>>>
>>> As with generic methods, the type arguments of generic constructors are
>>> usually inferred and not explicitly passed. However, generic
>>> constructors are much less common than generic methods.
>>>
>>> After the specification change, using diamond to infer the class type
>>> parameters but explicitly passing the constructor type parameters is
>>> forbidden. However, the other three combinations of explicitly passing
>>> type arguments versus inferring them are supported, as shown in the
>>> table below.
>>>
>>> class Foo<T extends Number>   {
>>>        <S extends T>   Foo(S s) {super();}
>>> }
>>>
>>> Class      C'tor        Supported   Example
>>> Explicit   Explicit     Yes         new<Integer>   Foo<Number>(null);
>>> Explicit   Inferred     Yes        new Foo<>(null);
>>> Inferred   Explicit     No         new<Integer>   Foo<>(null); // compile
>>> error
>>> Inferred   Inferred    Yes        new Foo<>(null);
>>>
>>> The substitution that was used to formally describe the semantics of
>>> diamond did not fully propagate constraints if there was a typing
>>> relationship between the type parameters of the constructor and the type
>>> parameters of the class. Lifting the imposed restriction on the banned
>>> combination of explicit and inferred type arguments can be revisited in
>>> future work in the context of broader type inference getting added to
>>> the Java language.
>>>
>>> Since generic constructors are so uncommon, adding this restriction
>>> about combining them with diamond should have little effect to most
>>> programs. For example, none of the uses of diamond in the JDK had to be
>>> updated as a result of this change. A changeset implementing this
>>> specification change has been pushed [1] and will appear in subsequent
>>> promoted builds of JDK 7.
>>>
>>> -Joe
>>>
>>> [1] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4caf17560ae0
>>>
>>>
>
>



From Anna.Kozlova at jetbrains.com  Tue May 17 09:16:43 2011
From: Anna.Kozlova at jetbrains.com (Anna Kozlova)
Date: Tue, 17 May 2011 18:16:43 +0200
Subject: Specification update: diamond and explicit generic constructor
	argument no longer supported
In-Reply-To: <4DC47B18.2020102@oracle.com>
References: <4DC47B18.2020102@oracle.com>
Message-ID: <07da01cc14ad$d00e0820$702a1860$@Kozlova@jetbrains.com>

Hello,

may be here is not the best place to ask, but I am not sure whether the
following was an intentional change or a bug?

{code}
  Object o = new <String>Object();
{code}

Compiles in build 142 but didn't in jdk6 builds. 

The same question but this time with diamond operator: what if constructor
doesn't have type parameters but they are still passed?
{code}
  class Foo<T> {
      Foo(T t) {super();}
  }  
{code}

Usage:
{code}
  new <Integer> Foo<>("");
{code}
How compilation should fail?

Thank you
Anna Kozlova
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!" 


-----Original Message-----
From: coin-dev-bounces at openjdk.java.net
[mailto:coin-dev-bounces at openjdk.java.net] On Behalf Of joe.darcy at oracle.com
Sent: Saturday, May 07, 2011 12:50 AM
To: coin-dev at openjdk.java.net
Subject: Specification update: diamond and explicit generic constructor
argument no longer supported

Hello.

To address an issue in the specification, the JSR 334 expert group has 
decided to ban the combination of diamond together with explicit 
constructor type arguments. For background, a constructor can have two 
sets of type arguments. In a parameterized class, constructors can have 
type arguments corresponding to the class's type parameters. This is the 
common case and the type arguments appear to the right of the class name 
and "new" as in "new ArrayList<String>()". In addition, if a constructor 
declares its very own type parameters (which can be done whether or not 
the enclosing class is parameterized), then those type arguments appear 
between the "new" token and the class name as in "new <Integer> 
ConstructorWithTypeParameter(Integer.valueOf(42))".

As with generic methods, the type arguments of generic constructors are 
usually inferred and not explicitly passed. However, generic 
constructors are much less common than generic methods.

After the specification change, using diamond to infer the class type 
parameters but explicitly passing the constructor type parameters is 
forbidden. However, the other three combinations of explicitly passing 
type arguments versus inferring them are supported, as shown in the 
table below.

class Foo<T extends Number> {
      <S extends T> Foo(S s) {super();}
}

Class      C'tor        Supported   Example
Explicit   Explicit     Yes         new <Integer> Foo<Number>(null);
Explicit   Inferred     Yes        new Foo<>(null);
Inferred   Explicit     No         new <Integer> Foo<>(null); // compile 
error
Inferred   Inferred    Yes        new Foo<>(null);

The substitution that was used to formally describe the semantics of 
diamond did not fully propagate constraints if there was a typing 
relationship between the type parameters of the constructor and the type 
parameters of the class. Lifting the imposed restriction on the banned 
combination of explicit and inferred type arguments can be revisited in 
future work in the context of broader type inference getting added to 
the Java language.

Since generic constructors are so uncommon, adding this restriction 
about combining them with diamond should have little effect to most 
programs. For example, none of the uses of diamond in the JDK had to be 
updated as a result of this change. A changeset implementing this 
specification change has been pushed [1] and will appear in subsequent 
promoted builds of JDK 7.

-Joe

[1] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4caf17560ae0


!DSPAM:35,4dc47a19236162090119686!



From maurizio.cimadamore at oracle.com  Tue May 17 09:35:44 2011
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 17 May 2011 17:35:44 +0100
Subject: Specification update: diamond and explicit generic constructor
	argument no longer supported
In-Reply-To: <07da01cc14ad$d00e0820$702a1860$@Kozlova@jetbrains.com>
References: <4DC47B18.2020102@oracle.com>
	<07da01cc14ad$d00e0820$702a1860$@Kozlova@jetbrains.com>
Message-ID: <4DD2A3E0.10402@oracle.com>

On 17/05/11 17:16, Anna Kozlova wrote:
> Hello,
>
> may be here is not the best place to ask, but I am not sure whether the
> following was an intentional change or a bug?
>
> {code}
>    Object o = new<String>Object();
> {code}

> Compiles in build 142 but didn't in jdk6 builds.
This is a deliberate change in javac in order to bring the compiler in 
sync with the spec [1]
> The same question but this time with diamond operator: what if constructor
> doesn't have type parameters but they are still passed?
> {code}
>    class Foo<T>  {
>        Foo(T t) {super();}
>    }
> {code}
>
> Usage:
> {code}
>    new<Integer>  Foo<>("");
> {code}
> How compilation should fail?
>
The combination of explicit constructor type-arguments and diamond 
operator has been banned - the above code is not valid [2]

Thanks
Maurizio

[1] - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5081782
[2] - 
http://blogs.oracle.com/darcy/entry/project_coin_diamond_generic_constructors 

> Thank you
> Anna Kozlova
> JetBrains Inc.
> http://www.jetbrains.com
> "Develop with pleasure!"
>
>
> -----Original Message-----
> From: coin-dev-bounces at openjdk.java.net
> [mailto:coin-dev-bounces at openjdk.java.net] On Behalf Of joe.darcy at oracle.com
> Sent: Saturday, May 07, 2011 12:50 AM
> To: coin-dev at openjdk.java.net
> Subject: Specification update: diamond and explicit generic constructor
> argument no longer supported
>
> Hello.
>
> To address an issue in the specification, the JSR 334 expert group has
> decided to ban the combination of diamond together with explicit
> constructor type arguments. For background, a constructor can have two
> sets of type arguments. In a parameterized class, constructors can have
> type arguments corresponding to the class's type parameters. This is the
> common case and the type arguments appear to the right of the class name
> and "new" as in "new ArrayList<String>()". In addition, if a constructor
> declares its very own type parameters (which can be done whether or not
> the enclosing class is parameterized), then those type arguments appear
> between the "new" token and the class name as in "new<Integer>
> ConstructorWithTypeParameter(Integer.valueOf(42))".
>
> As with generic methods, the type arguments of generic constructors are
> usually inferred and not explicitly passed. However, generic
> constructors are much less common than generic methods.
>
> After the specification change, using diamond to infer the class type
> parameters but explicitly passing the constructor type parameters is
> forbidden. However, the other three combinations of explicitly passing
> type arguments versus inferring them are supported, as shown in the
> table below.
>
> class Foo<T extends Number>  {
>        <S extends T>  Foo(S s) {super();}
> }
>
> Class      C'tor        Supported   Example
> Explicit   Explicit     Yes         new<Integer>  Foo<Number>(null);
> Explicit   Inferred     Yes        new Foo<>(null);
> Inferred   Explicit     No         new<Integer>  Foo<>(null); // compile
> error
> Inferred   Inferred    Yes        new Foo<>(null);
>
> The substitution that was used to formally describe the semantics of
> diamond did not fully propagate constraints if there was a typing
> relationship between the type parameters of the constructor and the type
> parameters of the class. Lifting the imposed restriction on the banned
> combination of explicit and inferred type arguments can be revisited in
> future work in the context of broader type inference getting added to
> the Java language.
>
> Since generic constructors are so uncommon, adding this restriction
> about combining them with diamond should have little effect to most
> programs. For example, none of the uses of diamond in the JDK had to be
> updated as a result of this change. A changeset implementing this
> specification change has been pushed [1] and will appear in subsequent
> promoted builds of JDK 7.
>
> -Joe
>
> [1] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4caf17560ae0
>
>
> !DSPAM:35,4dc47a19236162090119686!
>
>



From jjb at google.com  Tue May 17 15:50:51 2011
From: jjb at google.com (Joshua Bloch)
Date: Tue, 17 May 2011 15:50:51 -0700
Subject: Specification update: diamond and explicit generic constructor
	argument no longer supported
In-Reply-To: <4DD2A3E0.10402@oracle.com>
References: <4DC47B18.2020102@oracle.com>
	<4DD2A3E0.10402@oracle.com>
Message-ID: <BANLkTinWSE6TV4ZMqfcLDZ0sDjxcUgVGnA@mail.gmail.com>

Maurizio,

Whoa, are you telling us that you folks intentionally made this legal?

*    Object o = new<String>Object();*

This code makes no sense!  Why should it be legal to pass a type parameter
to a method or constructor that doesn't take one?  I dearly hope that I am
missing something.

    What am I missing?

    Josh

On Tue, May 17, 2011 at 9:35 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> On 17/05/11 17:16, Anna Kozlova wrote:
> > Hello,
> >
> > may be here is not the best place to ask, but I am not sure whether the
> > following was an intentional change or a bug?
> >
> > {code}
> >    Object o = new<String>Object();
> > {code}
>
> > Compiles in build 142 but didn't in jdk6 builds.
> This is a deliberate change in javac in order to bring the compiler in
> sync with the spec [1]
> > The same question but this time with diamond operator: what if
> constructor
> > doesn't have type parameters but they are still passed?
> > {code}
> >    class Foo<T>  {
> >        Foo(T t) {super();}
> >    }
> > {code}
> >
> > Usage:
> > {code}
> >    new<Integer>  Foo<>("");
> > {code}
> > How compilation should fail?
> >
> The combination of explicit constructor type-arguments and diamond
> operator has been banned - the above code is not valid [2]
>
> Thanks
> Maurizio
>
> [1] - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5081782
> [2] -
>
> http://blogs.oracle.com/darcy/entry/project_coin_diamond_generic_constructors
>
> > Thank you
> > Anna Kozlova
> > JetBrains Inc.
> > http://www.jetbrains.com
> > "Develop with pleasure!"
> >
> >
> > -----Original Message-----
> > From: coin-dev-bounces at openjdk.java.net
> > [mailto:coin-dev-bounces at openjdk.java.net] On Behalf Of
> joe.darcy at oracle.com
> > Sent: Saturday, May 07, 2011 12:50 AM
> > To: coin-dev at openjdk.java.net
> > Subject: Specification update: diamond and explicit generic constructor
> > argument no longer supported
> >
> > Hello.
> >
> > To address an issue in the specification, the JSR 334 expert group has
> > decided to ban the combination of diamond together with explicit
> > constructor type arguments. For background, a constructor can have two
> > sets of type arguments. In a parameterized class, constructors can have
> > type arguments corresponding to the class's type parameters. This is the
> > common case and the type arguments appear to the right of the class name
> > and "new" as in "new ArrayList<String>()". In addition, if a constructor
> > declares its very own type parameters (which can be done whether or not
> > the enclosing class is parameterized), then those type arguments appear
> > between the "new" token and the class name as in "new<Integer>
> > ConstructorWithTypeParameter(Integer.valueOf(42))".
> >
> > As with generic methods, the type arguments of generic constructors are
> > usually inferred and not explicitly passed. However, generic
> > constructors are much less common than generic methods.
> >
> > After the specification change, using diamond to infer the class type
> > parameters but explicitly passing the constructor type parameters is
> > forbidden. However, the other three combinations of explicitly passing
> > type arguments versus inferring them are supported, as shown in the
> > table below.
> >
> > class Foo<T extends Number>  {
> >        <S extends T>  Foo(S s) {super();}
> > }
> >
> > Class      C'tor        Supported   Example
> > Explicit   Explicit     Yes         new<Integer>  Foo<Number>(null);
> > Explicit   Inferred     Yes        new Foo<>(null);
> > Inferred   Explicit     No         new<Integer>  Foo<>(null); // compile
> > error
> > Inferred   Inferred    Yes        new Foo<>(null);
> >
> > The substitution that was used to formally describe the semantics of
> > diamond did not fully propagate constraints if there was a typing
> > relationship between the type parameters of the constructor and the type
> > parameters of the class. Lifting the imposed restriction on the banned
> > combination of explicit and inferred type arguments can be revisited in
> > future work in the context of broader type inference getting added to
> > the Java language.
> >
> > Since generic constructors are so uncommon, adding this restriction
> > about combining them with diamond should have little effect to most
> > programs. For example, none of the uses of diamond in the JDK had to be
> > updated as a result of this change. A changeset implementing this
> > specification change has been pushed [1] and will appear in subsequent
> > promoted builds of JDK 7.
> >
> > -Joe
> >
> > [1] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4caf17560ae0
> >
> >
> > !DSPAM:35,4dc47a19236162090119686!
> >
> >
>
>
>


From daniel.smith at oracle.com  Tue May 17 17:48:54 2011
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 17 May 2011 17:48:54 -0700
Subject: Specification update: diamond and explicit generic constructor
	argument no longer supported
In-Reply-To: <BANLkTinWSE6TV4ZMqfcLDZ0sDjxcUgVGnA@mail.gmail.com>
References: <4DC47B18.2020102@oracle.com> <4DD2A3E0.10402@oracle.com>
	<BANLkTinWSE6TV4ZMqfcLDZ0sDjxcUgVGnA@mail.gmail.com>
Message-ID: <FD411C1F-8B95-494D-A6B7-8EC91DD4E232@oracle.com>

This is a rule, called out in specifically in the JLS with some extended discussion, that javac was failing to conform to.  The change was to conform to the spec.

From JLS 3, 15.12.2.1:

> The clause above implies that a non-generic method may be potentially applicable to an invocation that supplies explicit type parameters. Indeed, it may turn out to be applicable. In such a case, the type parameters will simply be ignored.
> This rule stems from issues of compatibility and principles of substitutability. Since interfaces or superclasses may be generified independently of their subtypes, we may override a generic method with a non-generic one. However, the overriding (non-generic) method must be applicable to calls to the generic method, including calls that explicitly pass type parameters. Otherwise the subtype would not be substitutable for its generified supertype.

I'm not sure I believe that "the overriding (non-generic) method must be applicable to calls to the generic method"?I'm pretty sure this invariant is already violated in a number of ways elsewhere?but that was the rationale for the decision that was made when this was designed.

Resolution for constructors works "using the same rules as for method invocations" (15.9.3).  While clearly one could argue that the substitutability concerns above don't apply to constructors (nor to static or private methods...), the approach taken by the JLS was to consistently allow type arguments where none are needed.

?Dan


On May 17, 2011, at 3:50 PM, Joshua Bloch wrote:

> Maurizio,
> 
> Whoa, are you telling us that you folks intentionally made this legal?
> 
> *    Object o = new<String>Object();*
> 
> This code makes no sense!  Why should it be legal to pass a type parameter
> to a method or constructor that doesn't take one?  I dearly hope that I am
> missing something.
> 
>    What am I missing?
> 
>    Josh
> 
> On Tue, May 17, 2011 at 9:35 AM, Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
> 
>> On 17/05/11 17:16, Anna Kozlova wrote:
>>> Hello,
>>> 
>>> may be here is not the best place to ask, but I am not sure whether the
>>> following was an intentional change or a bug?
>>> 
>>> {code}
>>>   Object o = new<String>Object();
>>> {code}
>> 
>>> Compiles in build 142 but didn't in jdk6 builds.
>> This is a deliberate change in javac in order to bring the compiler in
>> sync with the spec [1]
>>> The same question but this time with diamond operator: what if
>> constructor
>>> doesn't have type parameters but they are still passed?
>>> {code}
>>>   class Foo<T>  {
>>>       Foo(T t) {super();}
>>>   }
>>> {code}
>>> 
>>> Usage:
>>> {code}
>>>   new<Integer>  Foo<>("");
>>> {code}
>>> How compilation should fail?
>>> 
>> The combination of explicit constructor type-arguments and diamond
>> operator has been banned - the above code is not valid [2]
>> 
>> Thanks
>> Maurizio
>> 
>> [1] - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5081782
>> [2] -
>> 
>> http://blogs.oracle.com/darcy/entry/project_coin_diamond_generic_constructors
>> 
>>> Thank you
>>> Anna Kozlova
>>> JetBrains Inc.
>>> http://www.jetbrains.com
>>> "Develop with pleasure!"
>>> 
>>> 
>>> -----Original Message-----
>>> From: coin-dev-bounces at openjdk.java.net
>>> [mailto:coin-dev-bounces at openjdk.java.net] On Behalf Of
>> joe.darcy at oracle.com
>>> Sent: Saturday, May 07, 2011 12:50 AM
>>> To: coin-dev at openjdk.java.net
>>> Subject: Specification update: diamond and explicit generic constructor
>>> argument no longer supported
>>> 
>>> Hello.
>>> 
>>> To address an issue in the specification, the JSR 334 expert group has
>>> decided to ban the combination of diamond together with explicit
>>> constructor type arguments. For background, a constructor can have two
>>> sets of type arguments. In a parameterized class, constructors can have
>>> type arguments corresponding to the class's type parameters. This is the
>>> common case and the type arguments appear to the right of the class name
>>> and "new" as in "new ArrayList<String>()". In addition, if a constructor
>>> declares its very own type parameters (which can be done whether or not
>>> the enclosing class is parameterized), then those type arguments appear
>>> between the "new" token and the class name as in "new<Integer>
>>> ConstructorWithTypeParameter(Integer.valueOf(42))".
>>> 
>>> As with generic methods, the type arguments of generic constructors are
>>> usually inferred and not explicitly passed. However, generic
>>> constructors are much less common than generic methods.
>>> 
>>> After the specification change, using diamond to infer the class type
>>> parameters but explicitly passing the constructor type parameters is
>>> forbidden. However, the other three combinations of explicitly passing
>>> type arguments versus inferring them are supported, as shown in the
>>> table below.
>>> 
>>> class Foo<T extends Number>  {
>>>       <S extends T>  Foo(S s) {super();}
>>> }
>>> 
>>> Class      C'tor        Supported   Example
>>> Explicit   Explicit     Yes         new<Integer>  Foo<Number>(null);
>>> Explicit   Inferred     Yes        new Foo<>(null);
>>> Inferred   Explicit     No         new<Integer>  Foo<>(null); // compile
>>> error
>>> Inferred   Inferred    Yes        new Foo<>(null);
>>> 
>>> The substitution that was used to formally describe the semantics of
>>> diamond did not fully propagate constraints if there was a typing
>>> relationship between the type parameters of the constructor and the type
>>> parameters of the class. Lifting the imposed restriction on the banned
>>> combination of explicit and inferred type arguments can be revisited in
>>> future work in the context of broader type inference getting added to
>>> the Java language.
>>> 
>>> Since generic constructors are so uncommon, adding this restriction
>>> about combining them with diamond should have little effect to most
>>> programs. For example, none of the uses of diamond in the JDK had to be
>>> updated as a result of this change. A changeset implementing this
>>> specification change has been pushed [1] and will appear in subsequent
>>> promoted builds of JDK 7.
>>> 
>>> -Joe
>>> 
>>> [1] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4caf17560ae0
>>> 
>>> 
>>> !DSPAM:35,4dc47a19236162090119686!
>>> 
>>> 
>> 
>> 
>> 
> 



From tronicek at fit.cvut.cz  Tue May 17 23:04:57 2011
From: tronicek at fit.cvut.cz (=?utf-8?B?IlpkZW7Em2sgVHJvbsOtxI1layI=?=)
Date: Wed, 18 May 2011 08:04:57 +0200
Subject: Specification update: diamond and explicit generic constructor
	argument no longer supported
In-Reply-To: <FD411C1F-8B95-494D-A6B7-8EC91DD4E232@oracle.com>
References: <4DC47B18.2020102@oracle.com> <4DD2A3E0.10402@oracle.com>
	<BANLkTinWSE6TV4ZMqfcLDZ0sDjxcUgVGnA@mail.gmail.com>
	<FD411C1F-8B95-494D-A6B7-8EC91DD4E232@oracle.com>
Message-ID: <90ece3244999f39accf866bb75597e23.squirrel@imap.fit.cvut.cz>

Ok, it makes sense to allow type parameter when calling a non-generified
method as "a concession to compatibility". But it does not make sense to
allow the same for constructors.
The argument "to be consistent" is false because it is illogical exception
from the language rules and each such exception should be justified by
strong motivation. You should not regard it as a new language rule because
the only motivation here is compatibility.

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague


Dan Smith napsal(a):
> This is a rule, called out in specifically in the JLS with some extended
> discussion, that javac was failing to conform to.  The change was to
> conform to the spec.
>
>>From JLS 3, 15.12.2.1:
>
>> The clause above implies that a non-generic method may be potentially
>> applicable to an invocation that supplies explicit type parameters.
>> Indeed, it may turn out to be applicable. In such a case, the type
>> parameters will simply be ignored.
>> This rule stems from issues of compatibility and principles of
>> substitutability. Since interfaces or superclasses may be generified
>> independently of their subtypes, we may override a generic method with a
>> non-generic one. However, the overriding (non-generic) method must be
>> applicable to calls to the generic method, including calls that
>> explicitly pass type parameters. Otherwise the subtype would not be
>> substitutable for its generified supertype.
>
> I'm not sure I believe that "the overriding (non-generic) method must be
> applicable to calls to the generic method"?I'm pretty sure this invariant
> is already violated in a number of ways elsewhere?but that was the
> rationale for the decision that was made when this was designed.
>
> Resolution for constructors works "using the same rules as for method
> invocations" (15.9.3).  While clearly one could argue that the
> substitutability concerns above don't apply to constructors (nor to static
> or private methods...), the approach taken by the JLS was to consistently
> allow type arguments where none are needed.
>
> ?Dan
>
>
> On May 17, 2011, at 3:50 PM, Joshua Bloch wrote:
>
>> Maurizio,
>>
>> Whoa, are you telling us that you folks intentionally made this legal?
>>
>> *    Object o = new<String>Object();*
>>
>> This code makes no sense!  Why should it be legal to pass a type
>> parameter
>> to a method or constructor that doesn't take one?  I dearly hope that I
>> am
>> missing something.
>>
>>    What am I missing?
>>
>>    Josh
>>
>> On Tue, May 17, 2011 at 9:35 AM, Maurizio Cimadamore <
>> maurizio.cimadamore at oracle.com> wrote:
>>
>>> On 17/05/11 17:16, Anna Kozlova wrote:
>>>> Hello,
>>>>
>>>> may be here is not the best place to ask, but I am not sure whether
>>>> the
>>>> following was an intentional change or a bug?
>>>>
>>>> {code}
>>>>   Object o = new<String>Object();
>>>> {code}
>>>
>>>> Compiles in build 142 but didn't in jdk6 builds.
>>> This is a deliberate change in javac in order to bring the compiler in
>>> sync with the spec [1]
>>>> The same question but this time with diamond operator: what if
>>> constructor
>>>> doesn't have type parameters but they are still passed?
>>>> {code}
>>>>   class Foo<T>  {
>>>>       Foo(T t) {super();}
>>>>   }
>>>> {code}
>>>>
>>>> Usage:
>>>> {code}
>>>>   new<Integer>  Foo<>("");
>>>> {code}
>>>> How compilation should fail?
>>>>
>>> The combination of explicit constructor type-arguments and diamond
>>> operator has been banned - the above code is not valid [2]
>>>
>>> Thanks
>>> Maurizio
>>>
>>> [1] - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5081782
>>> [2] -
>>>
>>> http://blogs.oracle.com/darcy/entry/project_coin_diamond_generic_constructors
>>>
>>>> Thank you
>>>> Anna Kozlova
>>>> JetBrains Inc.
>>>> http://www.jetbrains.com
>>>> "Develop with pleasure!"
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: coin-dev-bounces at openjdk.java.net
>>>> [mailto:coin-dev-bounces at openjdk.java.net] On Behalf Of
>>> joe.darcy at oracle.com
>>>> Sent: Saturday, May 07, 2011 12:50 AM
>>>> To: coin-dev at openjdk.java.net
>>>> Subject: Specification update: diamond and explicit generic
>>>> constructor
>>>> argument no longer supported
>>>>
>>>> Hello.
>>>>
>>>> To address an issue in the specification, the JSR 334 expert group has
>>>> decided to ban the combination of diamond together with explicit
>>>> constructor type arguments. For background, a constructor can have two
>>>> sets of type arguments. In a parameterized class, constructors can
>>>> have
>>>> type arguments corresponding to the class's type parameters. This is
>>>> the
>>>> common case and the type arguments appear to the right of the class
>>>> name
>>>> and "new" as in "new ArrayList<String>()". In addition, if a
>>>> constructor
>>>> declares its very own type parameters (which can be done whether or
>>>> not
>>>> the enclosing class is parameterized), then those type arguments
>>>> appear
>>>> between the "new" token and the class name as in "new<Integer>
>>>> ConstructorWithTypeParameter(Integer.valueOf(42))".
>>>>
>>>> As with generic methods, the type arguments of generic constructors
>>>> are
>>>> usually inferred and not explicitly passed. However, generic
>>>> constructors are much less common than generic methods.
>>>>
>>>> After the specification change, using diamond to infer the class type
>>>> parameters but explicitly passing the constructor type parameters is
>>>> forbidden. However, the other three combinations of explicitly passing
>>>> type arguments versus inferring them are supported, as shown in the
>>>> table below.
>>>>
>>>> class Foo<T extends Number>  {
>>>>       <S extends T>  Foo(S s) {super();}
>>>> }
>>>>
>>>> Class      C'tor        Supported   Example
>>>> Explicit   Explicit     Yes         new<Integer>  Foo<Number>(null);
>>>> Explicit   Inferred     Yes        new Foo<>(null);
>>>> Inferred   Explicit     No         new<Integer>  Foo<>(null); //
>>>> compile
>>>> error
>>>> Inferred   Inferred    Yes        new Foo<>(null);
>>>>
>>>> The substitution that was used to formally describe the semantics of
>>>> diamond did not fully propagate constraints if there was a typing
>>>> relationship between the type parameters of the constructor and the
>>>> type
>>>> parameters of the class. Lifting the imposed restriction on the banned
>>>> combination of explicit and inferred type arguments can be revisited
>>>> in
>>>> future work in the context of broader type inference getting added to
>>>> the Java language.
>>>>
>>>> Since generic constructors are so uncommon, adding this restriction
>>>> about combining them with diamond should have little effect to most
>>>> programs. For example, none of the uses of diamond in the JDK had to
>>>> be
>>>> updated as a result of this change. A changeset implementing this
>>>> specification change has been pushed [1] and will appear in subsequent
>>>> promoted builds of JDK 7.
>>>>
>>>> -Joe
>>>>
>>>> [1] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4caf17560ae0
>>>>
>>>>
>>>> !DSPAM:35,4dc47a19236162090119686!
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>



From joe.darcy at oracle.com  Tue May 24 11:04:15 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 24 May 2011 11:04:15 -0700
Subject: Documentation of Project Coin features as implemented in JDK 7 b143
Message-ID: <4DDBF31F.9060701@oracle.com>

Hello.

As a follow-up to the Project Coin documentation posted for the JDK 7 
developer preview [1] and with work on JDK 7 officially ramping down 
[2], I've posted documentation on the semantics of the Project Coin 
features as implemented in JDK 7 b143 at:

http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.9375.html

-Joe

[1] http://mail.openjdk.java.net/pipermail/coin-dev/2011-March/003124.html
[2] http://mail.openjdk.java.net/pipermail/jdk7-dev/2011-May/002124.html


From cld71 at hotmail.com  Sun May 29 01:41:29 2011
From: cld71 at hotmail.com (a d)
Date: Sun, 29 May 2011 04:41:29 -0400
Subject: switch for Object
Message-ID: <SNT108-W33138A4247BCFB96B251B1A2780@phx.gbl>


Dear Coin-Developers,

  Recently I have been looking at proposed Java language changes in Java 7.0.
One of the areas that is being changed that I can't stop thinking about is the switch for String, and was wondering why just for String?
Why not add a switch for all Objects that implement java.lang.Comparable<T> or java.util.Comparator<T> to make easier to use the switch operator?

Thanks...
 		 	   		  

From andriy.gerasika at gmail.com  Sun May 29 04:01:01 2011
From: andriy.gerasika at gmail.com (Andriy Gerasika)
Date: Sun, 29 May 2011 14:01:01 +0300
Subject: switch for Object
In-Reply-To: <SNT108-W33138A4247BCFB96B251B1A2780@phx.gbl>
References: <SNT108-W33138A4247BCFB96B251B1A2780@phx.gbl>
Message-ID: <4DE2276D.2050605@gmail.com>

On 05/29/2011 11:41 AM, a d wrote:
> One of the areas that is being changed that I can't stop thinking about is the switch for String, and was wondering why just for String?
> Why not add a switch for all Objects that implement java.lang.Comparable<T>  or java.util.Comparator<T>  to make easier to use the switch operator?

How will it make code easier to read?


From Ulf.Zibis at gmx.de  Sun May 29 05:04:50 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 29 May 2011 14:04:50 +0200
Subject: switch for Object
In-Reply-To: <4DE2276D.2050605@gmail.com>
References: <SNT108-W33138A4247BCFB96B251B1A2780@phx.gbl>
	<4DE2276D.2050605@gmail.com>
Message-ID: <4DE23662.8040700@gmx.de>

Hi Andriy and Anonymous (isn't it a little inpolite?),

see "Extend switch .. case statement for all types and simple expressions (update)" in this thread. 
Starting points:
- 31.03.2009 - 00:13 CET
- 28.05.2009 - 16:40 CET

-Ulf


Am 29.05.2011 13:01, schrieb Andriy Gerasika:
> On 05/29/2011 11:41 AM, a d wrote:
>> One of the areas that is being changed that I can't stop thinking about is the switch for String, and was wondering why just for String?
>> Why not add a switch for all Objects that implement java.lang.Comparable<T>   or java.util.Comparator<T>   to make easier to use the switch operator?
> How will it make code easier to read?
>
>


From andriy.gerasika at gmail.com  Sun May 29 06:20:44 2011
From: andriy.gerasika at gmail.com (Andriy Gerasika)
Date: Sun, 29 May 2011 16:20:44 +0300
Subject: switch for Object
In-Reply-To: <4DE23662.8040700@gmx.de>
References: <SNT108-W33138A4247BCFB96B251B1A2780@phx.gbl>	<4DE2276D.2050605@gmail.com>
	<4DE23662.8040700@gmx.de>
Message-ID: <4DE2482C.1050803@gmail.com>

On 05/29/2011 03:04 PM, Ulf Zibis wrote:
> see "Extend switch .. case statement for all types and simple expressions (update)" in this thread.
> Starting points:
> - 31.03.2009 - 00:13 CET
> - 28.05.2009 - 16:40 CET

sorry.

Can someone post a link to archives in Thunderbird or Outlook format? I 
know about pipermail archives, but find that somewhat hard to read.


From Ulf.Zibis at gmx.de  Sun May 29 06:47:12 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 29 May 2011 15:47:12 +0200
Subject: switch for Object
In-Reply-To: <4DE2482C.1050803@gmail.com>
References: <SNT108-W33138A4247BCFB96B251B1A2780@phx.gbl>	<4DE2276D.2050605@gmail.com>	<4DE23662.8040700@gmx.de>
	<4DE2482C.1050803@gmail.com>
Message-ID: <4DE24E60.6070406@gmx.de>

maybe here:
http://markmail.org/search/?q=list%3Anet.java.openjdk
http://dir.gmane.org/index.php?prefix=gmane.comp.java.openjdk

-Ulf


Am 29.05.2011 15:20, schrieb Andriy Gerasika:
> On 05/29/2011 03:04 PM, Ulf Zibis wrote:
>> see "Extend switch .. case statement for all types and simple expressions (update)" in this thread.
>> Starting points:
>> - 31.03.2009 - 00:13 CET
>> - 28.05.2009 - 16:40 CET
> sorry.
>
> Can someone post a link to archives in Thunderbird or Outlook format? I
> know about pipermail archives, but find that somewhat hard to read.
>
>


From neal at gafter.com  Mon May 30 09:44:14 2011
From: neal at gafter.com (Neal Gafter)
Date: Mon, 30 May 2011 09:44:14 -0700
Subject: switch for Object
In-Reply-To: <SNT108-W33138A4247BCFB96B251B1A2780@phx.gbl>
References: <SNT108-W33138A4247BCFB96B251B1A2780@phx.gbl>
Message-ID: <BANLkTikrpTQm95c4f+C6mspghPr6n-0LAw@mail.gmail.com>

On Sun, May 29, 2011 at 1:41 AM, a d <cld71 at hotmail.com> wrote:

>  Recently I have been looking at proposed Java language changes in Java
> 7.0.
> One of the areas that is being changed that I can't stop thinking about is
> the switch for String, and was wondering why just for String?
> Why not add a switch for all Objects that implement java.lang.Comparable<T>
> or java.util.Comparator<T> to make easier to use the switch operator?
>

The frist reason that comes to mind is that String is the only object type
that can be a compile-time constant.


From neal at gafter.com  Tue May 31 08:28:05 2011
From: neal at gafter.com (Neal Gafter)
Date: Tue, 31 May 2011 08:28:05 -0700
Subject: FYI, JSR 334 is now in public review
In-Reply-To: <4D8BB1E1.6000309@oracle.com>
References: <4D8BB1E1.6000309@oracle.com>
Message-ID: <BANLkTinP-KK=7UmCHjJk1mOxRB-W8XPHvQ@mail.gmail.com>

I repeat my offer to provide detailed feedback once Oracle has fulfilled its
promise to make the expert group discussion publicly readable.

On Thu, Mar 24, 2011 at 2:04 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello.
>
> FYI, JSR 334 is now in public review and the public review draft of the
> specification, v0.875, can be downloaded from:
> http://jcp.org/aboutJava/communityprocess/pr/jsr334/index.html
>
> -Joe
>
>


From gerard.davison at oracle.com  Tue May 31 08:36:42 2011
From: gerard.davison at oracle.com (Gerard Davison)
Date: Tue, 31 May 2011 16:36:42 +0100
Subject: Annotation Composition
Message-ID: <4DE50B0A.7060905@oracle.com>


A long while ago I wrote up a proposal for adding support for composite 
annotations, this came from my experience of using SOAP and REST web 
services. I never got around to posting it on this list, but I wondered 
if it might be worth considering for a later cycle and this seemed to be 
the right place to post it.

(A prettier version is on my blog at 
http://kingsfleet.blogspot.com/2010/04/composite-annotations.html)

PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0

AUTHOR(S): Gerard Davison

OVERVIEW

Provide a two sentence or shorter description of these five aspects of 
the feature:

FEATURE SUMMARY: Should be suitable as a summary in a language tutorial.

Add the ability to compose existing annotations as meta annotations to 
be able to easily create stereotypes for common combinations.

MAJOR ADVANTAGE: What makes the proposal a favorable change?

Libraries can provide common "stereotype" made up of sensible default 
combinations of annotations.

MAJOR BENEFIT: Why is the platform better if the proposal is adopted?

Potentially shallower learning curve for annotation based frameworks.

MAJOR DISADVANTAGE: There is always a cost.

It is possible that by hiding configuration behind stereotypes that the 
code becomes harder to diagnose. This can be ameliorated to some extent 
with tool support and suitable naming conventions.

ALTERNATIVES: Can the benefits and advantages be had some way without a 
language change?

Yes, it is possible for each and every framework to introduce there own 
Composite marker annotation and processor. For example spring has 
something quite similar in there meta annotations:

http://blog.springsource.com/2009/05/06/spring-framework-30-m3-released/

Each implementation would be different then as not as easily accessible 
as a language feature would be.

EXAMPLES Show us the code!

SIMPLE EXAMPLE: Show the simplest possible program utilizing the new 
feature.

<http://kingsfleet.blogspot.com/2010/04/composite-annotations.html#><http://kingsfleet.blogspot.com/2010/04/composite-annotations.html#>

   1. package java.lang.annotation;
   2.
   3. @Retention(SOURCE)
   4. @Target(ANNOTATION_TYPE)
   5. public at interface Composite
   6. {
   7. }
   8.
   9.
  10. package x;
  11.
  12. @Composite
  13. @SuppressWarnings({"unchecked"})
  14. @Target(METHOD)
  15. public at interface SuppressUnchecked
  16. {
  17. }
  18.
  19. package y;
  20.
  21. publicclass ExampleService
  22. {
  23. @SupressUnchecked
  24. publicvoid methodWithOddCast()
  25.     {
  26.         ...
  27.     }
  28. }

ADVANCED EXAMPLE: Show advanced usage(s) of the feature.

<http://kingsfleet.blogspot.com/2010/04/composite-annotations.html#><http://kingsfleet.blogspot.com/2010/04/composite-annotations.html#>

   1. @Composite
   2. @WebService
   3. @Binding(SOAPBinding.SOAP_12_BINDING)
   4. @Addressing
   5. @Target(CLASS)
   6. public at interface SOAP12AddressingWebService
   7. {
   8. }
   9.
  10. @SOAP12AddressingWebService
  11. publicclass ExampleService
  12. {
  13.     ...
  14. }

DETAILS SPECIFICATION: Describe how the proposal affects the grammar, 
type system, and meaning of expressions and statements in the Java 
Programming Language as well as any other known impacts.

The lexical grammar is unchanged. The type system is unchanged. The 
annotation type section is modified (JLS ?.?) so that an annotation can 
be applied to composite annotation if that annotation is tagged with 
@Composite and the target and retention matches that of the composite 
annotation. This prevents all annotations having to be modified with the 
ANNOTATION_TYPE modifier.

COMPILATION: How would the feature be compiled to class files?

This feature modifies the process which is used to gather the annotation 
properties. In general the rule is that values directly applied to class 
will override values provided by composite annotations. So the process 
for building the values for a particular class should be:

   1. For each annotation attached to the class that isn't marked as
      @Composite store the values for this class. Once defined the value
      will not change.
   2. For each annotation attached to the class in source order that is
      marked as @Composite apply any values that have not been
      previously defined. Recursively apply the values for any attached
      composite annotations.

The compilation should fail if there is a loop of @Composite 
annotations. (QUERY should we allow multi-level or is one turtle enough.)

For a client reading the class using the reflective API it should appear 
as if the annotations provided by the composite annotations were applied 
to the class directly. (QUERY should the composite annotations be erased 
at runtime?)

TESTING: How can the feature be tested?

It should be a matter of generating various simple cases with differing 
levels of composite annotations. Corner cases should be provided with 
inconsistent target or retention policies.

LIBRARY SUPPORT: Are any supporting libraries needed for the feature?

REFLECTIVE APIS: Do any of the various and sundry reflection APIs need 
to be updated? This list of reflective APIs includes but is not limited 
to core reflection (java.lang.Class and java.lang.reflect.*), 
javax.lang.model.*, the doclet API, and JPDA.

As the annotations are unwound at compile time this won't affect any 
reflective API that works from a class file. It is going to pose a 
question of what is the correct thing to do when looking at a source 
file. (QUERY not sure what the best thing is to do)

OTHER CHANGES: Do any other parts of the platform need be updated too? 
Possibilities include but are not limited to JNI, serialization, and 
output of the javadoc tool.

Yes, the javadoc tool should show both the composite and the applied 
annotations in some way.

MIGRATION: Sketch how a code base could be converted, manually or 
automatically, to use the new feature.

Roll up some application to use stereotypes as applicable.

COMPATIBILITY BREAKING CHANGES: Are any previously valid programs now 
invalid? If so, list one.

All existing programs remain valid.

EXISTING PROGRAMS: How do source and class files of earlier platform 
versions interact with the feature? Can any new overloadings occur? Can 
any new overriding occur?

The semantics of existing class files and legal source files and are 
unchanged by this feature.

REFERENCES EXISTING BUGS: Please include a list of any existing Sun bug 
ids related to this proposal.

None

URL FOR PROTOTYPE (optional):

No prototype at this time.




From stuart.marks at oracle.com  Tue May 31 11:28:42 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 31 May 2011 11:28:42 -0700
Subject: switch for Object
In-Reply-To: <4DE2482C.1050803@gmail.com>
References: <SNT108-W33138A4247BCFB96B251B1A2780@phx.gbl>	<4DE2276D.2050605@gmail.com>	<4DE23662.8040700@gmx.de>
	<4DE2482C.1050803@gmail.com>
Message-ID: <4DE5335A.2040101@oracle.com>

On 5/29/11 6:20 AM, Andriy Gerasika wrote:
> On 05/29/2011 03:04 PM, Ulf Zibis wrote:
>> see "Extend switch .. case statement for all types and simple expressions (update)" in this thread.
>> Starting points:
>> - 31.03.2009 - 00:13 CET
>> - 28.05.2009 - 16:40 CET
>
> sorry.
>
> Can someone post a link to archives in Thunderbird or Outlook format? I
> know about pipermail archives, but find that somewhat hard to read.

[this is really about dealing with mail archives]

The coin-dev archives are here:

http://mail.openjdk.java.net/pipermail/coin-dev/

To get the mail archives into Thunderbird, do the following:

1. Download archives using the "Text" links in the rightmost column. These 
files are in "mbox" format which Thunderbird understands.

2. Using filesystem operations (e.g. a shell or your favorite file manager) 
move these files into the "Mail/Local Folders" area of your Thunderbird profile 
hierarchy.

3. Quit and restart Thunderbird. (I haven't found a way to get Tbird to 
recognize new files automatically.) Each downloaded file will appear as a new 
folder of messages within your Local Folders area in Tbird. From here, you can 
drag messages to one big archive folder, sort, search, read in threaded mode, etc.

Using this technique I was very quickly able to find the messages Ulf referred to.

I don't know anything about Outlook.

s'marks


From andriy.gerasika at gmail.com  Tue May 31 12:22:50 2011
From: andriy.gerasika at gmail.com (Andriy Gerasika)
Date: Tue, 31 May 2011 22:22:50 +0300
Subject: switch for Object
In-Reply-To: <4DE5335A.2040101@oracle.com>
References: <SNT108-W33138A4247BCFB96B251B1A2780@phx.gbl>	<4DE2276D.2050605@gmail.com>	<4DE23662.8040700@gmx.de>
	<4DE2482C.1050803@gmail.com> <4DE5335A.2040101@oracle.com>
Message-ID: <4DE5400A.6090601@gmail.com>

On 05/31/2011 09:28 PM, Stuart Marks wrote:

> [this is really about dealing with mail archives]
>
> The coin-dev archives are here:
>
> http://mail.openjdk.java.net/pipermail/coin-dev/
>
> To get the mail archives into Thunderbird, do the following:
>

thanks, I have already composed small Java program that does that 
automatically :)
p.s.
gmane is missing coin-dev anyways


From Ulf.Zibis at gmx.de  Tue May 31 14:38:56 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 31 May 2011 23:38:56 +0200
Subject: switch for Object
In-Reply-To: <4DE5400A.6090601@gmail.com>
References: <SNT108-W33138A4247BCFB96B251B1A2780@phx.gbl>	<4DE2276D.2050605@gmail.com>	<4DE23662.8040700@gmx.de>	<4DE2482C.1050803@gmail.com>
	<4DE5335A.2040101@oracle.com> <4DE5400A.6090601@gmail.com>
Message-ID: <4DE55FF0.4040306@gmx.de>

Am 31.05.2011 21:22, schrieb Andriy Gerasika:
> On 05/31/2011 09:28 PM, Stuart Marks wrote:
>
>> [this is really about dealing with mail archives]
>>
>> The coin-dev archives are here:
>>
>> http://mail.openjdk.java.net/pipermail/coin-dev/
>>
>> To get the mail archives into Thunderbird, do the following:
>>
> thanks, I have already composed small Java program that does that
> automatically :)
Great, can you share it here?

> p.s.
> gmane is missing coin-dev anyways
Unfortunately yes, same on Markmail.

-Ulf



From andriy.gerasika at gmail.com  Tue May 31 15:50:52 2011
From: andriy.gerasika at gmail.com (Andriy Gerasika)
Date: Wed, 01 Jun 2011 01:50:52 +0300
Subject: switch for Object
In-Reply-To: <4DE55FF0.4040306@gmx.de>
References: <SNT108-W33138A4247BCFB96B251B1A2780@phx.gbl>	<4DE2276D.2050605@gmail.com>	<4DE23662.8040700@gmx.de>	<4DE2482C.1050803@gmail.com>	<4DE5335A.2040101@oracle.com>
	<4DE5400A.6090601@gmail.com> <4DE55FF0.4040306@gmx.de>
Message-ID: <4DE570CC.2040501@gmail.com>

On 06/01/2011 12:38 AM, Ulf Zibis wrote:
>> thanks, I have already composed small Java program that does that
>> automatically :)
> Great, can you share it here?
>

Source code can be found on 
http://www.gerixsoft.com/sites/gerixsoft.com/files/import-mailman.zip

Usage is:
args[0] is the URL, i.e. http://mail.openjdk.java.net/pipermail/coin-dev/
args[1] is file name of future Thunderbird folder, i.e. coin-dev-archive

The program requires Saxon 9 HE and TagSoup JARs (free) to run -- see 
readme files in ./lib/saxon & ./lib/tagsoup folders