From joe.darcy at oracle.com  Tue Oct  4 17:52:42 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 04 Oct 2011 17:52:42 -0700
Subject: Update on Coin futures from JavaOne
Message-ID: <4E8BAA5A.2020207@oracle.com>

Hello.

Earlier today, I presented my JavaOne session on "The Heads and Tails of 
Project Coin." [1]  The talk included some retrospectives from 
developing the Coin features which I hope to write up in more detail in 
the near future.

Turning toward the future, the talk also spent a little time discussing 
possible language changes coming in JDK 8. First, planning for JDK 8 is 
on-going and the feature list is subject to change; the JEP process [2] 
will be used to help define the roadmap going forward. With those 
caveats, small language changes we're considering proposing for JDK 8 
include:

    Refinements to JDK 7 Coin features
        try-with-resources on an effective final variable
        removing restrictions on usage of diamond
        @SafeVarargs on private methods
    Collection literals(?)
    Repeating Annotations(?)
    Method and constructor parameter names at runtime(?)

Personally, I would welcome programming with collection literals. 
Repeating annotations and the ability to retrieve the names of 
method/constructors at runtime are both long-standing requests from our 
colleagues in EE.

However, with the broad scope of language and platform changes coming 
into JDK 8 courtesy Lambda and Jigsaw, all these smaller language 
changes have to be made somewhat opportunistically. For that reason, for 
JDK 8 we are *not* planning on having another open call for proposals as 
was done for Project Coin in JDK 7.

-Joe

[1] http://blogs.oracle.com/darcy/entry/project_coin_javaone2011
[2] http://openjdk.java.net/jeps/0


From sebastian.sickelmann at gmx.de  Tue Oct  4 20:01:52 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 05 Oct 2011 05:01:52 +0200
Subject: Fwd: Fwd: Re: A facility for getting the current method's name
Message-ID: <4E8BC8A0.9050509@gmx.de>

Hi Behrang Seaadzadeh,

maybe you should move with this request to coin-dev at openjdk.java.net.

See http://mail.openjdk.java.net/pipermail/coin-dev/2011-October/003355.html
and the last considered small change to the java language.

-- Sebastian
-------- Original-Nachricht --------
Betreff: 	Re: A facility for getting the current method's name
Datum: 	Sat, 01 Oct 2011 07:35:51 +0200
Von: 	Sebastian Sickelmann <sebastian.sickelmann at gmx.de>
An: 	jdk8-dev at openjdk.java.net



Am 01.10.2011 03:49, schrieb Behrang Saeedzadeh:
>  Hi Krystal,
>
>  On Tue, Sep 27, 2011 at 8:35 PM, Krystal Mok<rednaxelafx at gmail.com>   wrote:
>>  Hi Behrang,
>>  This reminds me of how people were looking for a "current class literal",
>>  something like this:
>>  public class Foo {
>>     public static void main(String[] args) {
>>       // don't want to hard code "Foo.class" here
>>       String name = Foo.class.getName();
>>     }
>>  }
>>  and now that JDK7 is out, they've got a new toy that gives them exactly
>>  that:
>>  java.lang.invoke.MethodHandles.lookup().lookupClass()
>  This is very similar to what I am looking for. What I need is
>  something like this:
>
>  java.lang.invoke.MethodHandles.lookup().lookupMethod();
Is there a reason why you want it to be an operation/evaluation at runtime?
Because i don't see this at runtime. Am i missing something?
>>  It's not mean't to be fast when used like this, though.
>>  The same with what you're looking for, but you've already got backtrace
>>  which gives you the correct semantics, just not fast enough, right?
>  Yes, AFAICT, it should be possible to get the current method's name
>  without having to construct the (expensive) stack trace. I personally
>  avoid suchlike operations ATM only because they're expensive.
>
>  By the way, now that we're into it, it would be great if we have a
>  standardized byte code enhancement library (e.g. ASM). I know, I know!
>  I am asking for too much! :D
>
>  Cheers,
>  Behrang
>
>>  On Mon, Sep 26, 2011 at 7:31 PM, Behrang Saeedzadeh<behrangsa at gmail.com>
>>  wrote:
>>>  Sean, Mario,
>>>
>>>  I am looking for something like JavaScript's arguments.callee.name or
>>>  Ruby's __method__. AFAIK, accessing the current method's name is a
>>>  very cheap operation in JS and Ruby while creating a stack trace is a
>>>  moderately expensive operation in Java.
>>  They don't seem to be expensive in JavaScript or Ruby because those
>>  languages didn't have fast implementations. Once they do (as the current JS
>>  engines and JRuby/Rubinius), this kind of reflective operations will show
>>  their cost.
>>  Regards,
>>  Kris Mok




From brucechapman at paradise.net.nz  Wed Oct  5 00:57:20 2011
From: brucechapman at paradise.net.nz (Bruce Chapman)
Date: Wed, 05 Oct 2011 20:57:20 +1300
Subject: Update on Coin futures from JavaOne
In-Reply-To: <4E8BAA5A.2020207@oracle.com>
References: <4E8BAA5A.2020207@oracle.com>
Message-ID: <4E8C0DE0.1020403@paradise.net.nz>

Joe,

Is the omission of byte literals (or alternatively unsigned literals, or 
unsigned bytes) deliberate, or is there still intention to address this 
somehow?

Secondly, is the JEP process the way to propose further small language 
enhancements?

Bruce

On 5/10/2011 1:52 p.m., Joe Darcy wrote:
> Hello.
>
> Earlier today, I presented my JavaOne session on "The Heads and Tails of
> Project Coin." [1]  The talk included some retrospectives from
> developing the Coin features which I hope to write up in more detail in
> the near future.
>
> Turning toward the future, the talk also spent a little time discussing
> possible language changes coming in JDK 8. First, planning for JDK 8 is
> on-going and the feature list is subject to change; the JEP process [2]
> will be used to help define the roadmap going forward. With those
> caveats, small language changes we're considering proposing for JDK 8
> include:
>
>      Refinements to JDK 7 Coin features
>          try-with-resources on an effective final variable
>          removing restrictions on usage of diamond
>          @SafeVarargs on private methods
>      Collection literals(?)
>      Repeating Annotations(?)
>      Method and constructor parameter names at runtime(?)
>
> Personally, I would welcome programming with collection literals.
> Repeating annotations and the ability to retrieve the names of
> method/constructors at runtime are both long-standing requests from our
> colleagues in EE.
>
> However, with the broad scope of language and platform changes coming
> into JDK 8 courtesy Lambda and Jigsaw, all these smaller language
> changes have to be made somewhat opportunistically. For that reason, for
> JDK 8 we are *not* planning on having another open call for proposals as
> was done for Project Coin in JDK 7.
>
> -Joe
>
> [1] http://blogs.oracle.com/darcy/entry/project_coin_javaone2011
> [2] http://openjdk.java.net/jeps/0
>
>



From loic.descotte at gmail.com  Wed Oct  5 08:15:41 2011
From: loic.descotte at gmail.com (Loic Descotte)
Date: Wed, 5 Oct 2011 17:15:41 +0200
Subject: JDK 8 and properties
Message-ID: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>

Hi all,

I was wondering if coin 2 (in JDK 8) would possibly include a "properties"
feature, to avoid writing getters and setters for all fields in our classes.

When we have large classes with a lot of fields, getters/setters make the
code very hard to read. If a field is returned with something else that a
simple "get", we risk to miss it be cause it's hidden among the others
getters and setters.

C# properties or the one introduced with Kotlin language would be great!

After lambda project, I think it would be the only little thing missing to
java 8 to become really great and more pleasant to use.

Do you have any status about such a feature?

Thanks

Loic

Ps : excuse me if it's not the right mailing list for this kind of question


From serafin.sedano at abiquo.com  Wed Oct  5 08:22:52 2011
From: serafin.sedano at abiquo.com (Serafin Sedano)
Date: Wed, 5 Oct 2011 17:22:52 +0200
Subject: JDK 8 and properties
In-Reply-To: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
Message-ID: <CA+uJM+=WxGSndwRW_BFuT9hGfyo076y-0aBgqHBffMqUayCoMA@mail.gmail.com>

Hi,

I totally agree with the need for such a feature.

In ruby there is the attr_accessor that eases the reading of a class.

Regards.

Seraf?n.

2011/10/5 Loic Descotte <loic.descotte at gmail.com>

> Hi all,
>
> I was wondering if coin 2 (in JDK 8) would possibly include a "properties"
> feature, to avoid writing getters and setters for all fields in our
> classes.
>
> When we have large classes with a lot of fields, getters/setters make the
> code very hard to read. If a field is returned with something else that a
> simple "get", we risk to miss it be cause it's hidden among the others
> getters and setters.
>
> C# properties or the one introduced with Kotlin language would be great!
>
> After lambda project, I think it would be the only little thing missing to
> java 8 to become really great and more pleasant to use.
>
> Do you have any status about such a feature?
>
> Thanks
>
> Loic
>
> Ps : excuse me if it's not the right mailing list for this kind of question
>
>


From mthornton at optrak.com  Wed Oct  5 08:26:02 2011
From: mthornton at optrak.com (Mark Thornton)
Date: Wed, 05 Oct 2011 16:26:02 +0100
Subject: JDK 8 and properties
In-Reply-To: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
Message-ID: <4E8C770A.3000206@optrak.com>

On 05/10/11 16:15, Loic Descotte wrote:
> Hi all,
>
> I was wondering if coin 2 (in JDK 8) would possibly include a "properties"
> feature, to avoid writing getters and setters for all fields in our classes.
>
>
The second answer (from Alex Miller) probably still applies

http://stackoverflow.com/questions/710266/why-will-there-be-no-native-properties-in-java-7

Mark Thornton




From loic.descotte at gmail.com  Wed Oct  5 09:05:26 2011
From: loic.descotte at gmail.com (Loic Descotte)
Date: Wed, 5 Oct 2011 18:05:26 +0200
Subject: JDK 8 and properties
In-Reply-To: <4E8C770A.3000206@optrak.com>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
	<4E8C770A.3000206@optrak.com>
Message-ID: <CAJSAXGnT949vc4c7Kum4g6CLE0dJcbmcO9XXqxidZzQ6Gz=KNg@mail.gmail.com>

About Alex Miller answer,

The consensus was not there at the beggining for lambdas, but it worked
(even if it was hard, I admit)

For the second point, I work on server side but properties are important to
me :)
And a lot of people I know feel the same.

On Wed, Oct 5, 2011 at 5:26 PM, Mark Thornton <mthornton at optrak.com> wrote:

> On 05/10/11 16:15, Loic Descotte wrote:
> > Hi all,
> >
> > I was wondering if coin 2 (in JDK 8) would possibly include a
> "properties"
> > feature, to avoid writing getters and setters for all fields in our
> classes.
> >
> >
> The second answer (from Alex Miller) probably still applies
>
>
> http://stackoverflow.com/questions/710266/why-will-there-be-no-native-properties-in-java-7
>
> Mark Thornton
>
>
>
>


-- 
Lo?c Descotte
4 rue Joseph Fourier
38000 Grenoble

06 23 23 36 80


From forax at univ-mlv.fr  Wed Oct  5 09:10:38 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 05 Oct 2011 18:10:38 +0200
Subject: JDK 8 and properties
In-Reply-To: <4E8C770A.3000206@optrak.com>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
	<4E8C770A.3000206@optrak.com>
Message-ID: <4E8C817E.3080301@univ-mlv.fr>

On 10/05/2011 05:26 PM, Mark Thornton wrote:
> On 05/10/11 16:15, Loic Descotte wrote:
>> Hi all,
>>
>> I was wondering if coin 2 (in JDK 8) would possibly include a "properties"
>> feature, to avoid writing getters and setters for all fields in our classes.
>>
>>
> The second answer (from Alex Miller) probably still applies
>
> http://stackoverflow.com/questions/710266/why-will-there-be-no-native-properties-in-java-7
>
> Mark Thornton

I agree but if we are able to provide lambdas in Java 8,
properties should be a piece of cake :)

Properties are too big to be just a coin feature and should be a JSR
(or a JEP, I don't know exactly what a JEP is)
so there will be no properties for Java 8, perhaps for Java 9.

 From the technical point of view, properties may be implemented more easily
now because we can use invokedynamic.

R?mi



From pbenedict at apache.org  Wed Oct  5 09:11:05 2011
From: pbenedict at apache.org (Paul Benedict)
Date: Wed, 5 Oct 2011 11:11:05 -0500
Subject: JDK 8 and properties
In-Reply-To: <CAJSAXGnT949vc4c7Kum4g6CLE0dJcbmcO9XXqxidZzQ6Gz=KNg@mail.gmail.com>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
	<4E8C770A.3000206@optrak.com>
	<CAJSAXGnT949vc4c7Kum4g6CLE0dJcbmcO9XXqxidZzQ6Gz=KNg@mail.gmail.com>
Message-ID: <CABLGb9x6700smZcjzBr+NnjUyeHZuwGC01q4iR0Sh-FEVZvgfw@mail.gmail.com>

Here's my opinion... Properties brings its own issues. Part of Java's
success is the readability of the language. If the dot notation is
used for properties, readability diminishes because it is no longer
apparent whether field access or method access is occuring.

someObject.x = 1; // method call or field access?

If another syntax is used, then I think it almost defeats the purpose
of the proposal in the first place; it also begs the question how is
that any "better" than simply calling the getter/setter directly.

Paul


On Wed, Oct 5, 2011 at 11:05 AM, Loic Descotte <loic.descotte at gmail.com> wrote:
> About Alex Miller answer,
>
> The consensus was not there at the beggining for lambdas, but it worked
> (even if it was hard, I admit)
>
> For the second point, I work on server side but properties are important to
> me :)
> And a lot of people I know feel the same.
>
> On Wed, Oct 5, 2011 at 5:26 PM, Mark Thornton <mthornton at optrak.com> wrote:
>
>> On 05/10/11 16:15, Loic Descotte wrote:
>> > Hi all,
>> >
>> > I was wondering if coin 2 (in JDK 8) would possibly include a
>> "properties"
>> > feature, to avoid writing getters and setters for all fields in our
>> classes.
>> >
>> >
>> The second answer (from Alex Miller) probably still applies
>>
>>
>> http://stackoverflow.com/questions/710266/why-will-there-be-no-native-properties-in-java-7
>>
>> Mark Thornton
>>
>>
>>
>>
>
>
> --
> Lo?c Descotte
> 4 rue Joseph Fourier
> 38000 Grenoble
>
> 06 23 23 36 80
>
>


From rich.midwinter at gmail.com  Wed Oct  5 09:29:12 2011
From: rich.midwinter at gmail.com (Rich Midwinter)
Date: Wed, 5 Oct 2011 17:29:12 +0100
Subject: JDK 8 and properties
In-Reply-To: <CABLGb9x6700smZcjzBr+NnjUyeHZuwGC01q4iR0Sh-FEVZvgfw@mail.gmail.com>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
	<4E8C770A.3000206@optrak.com>
	<CAJSAXGnT949vc4c7Kum4g6CLE0dJcbmcO9XXqxidZzQ6Gz=KNg@mail.gmail.com>
	<CABLGb9x6700smZcjzBr+NnjUyeHZuwGC01q4iR0Sh-FEVZvgfw@mail.gmail.com>
Message-ID: <CALKB1SV-32KrCJSogiZjUqm5PcQqjabozS541+_tKEkhkH80ow@mail.gmail.com>

You wouldn't need dot notation just to have generated getters/setters
though. http://projectlombok.org/features/GetterSetter.html

Personally, I have no need for dot notation but do use lombok's @Data
frequently (even as a mostly server side guy). I'd have a slight preference
for having a similar solution ship with Java.

Rich.


On 5 October 2011 17:11, Paul Benedict <pbenedict at apache.org> wrote:

> Here's my opinion... Properties brings its own issues. Part of Java's
> success is the readability of the language. If the dot notation is
> used for properties, readability diminishes because it is no longer
> apparent whether field access or method access is occuring.
>
> someObject.x = 1; // method call or field access?
>
> If another syntax is used, then I think it almost defeats the purpose
> of the proposal in the first place; it also begs the question how is
> that any "better" than simply calling the getter/setter directly.
>
> Paul
>
>
> On Wed, Oct 5, 2011 at 11:05 AM, Loic Descotte <loic.descotte at gmail.com>
> wrote:
> > About Alex Miller answer,
> >
> > The consensus was not there at the beggining for lambdas, but it worked
> > (even if it was hard, I admit)
> >
> > For the second point, I work on server side but properties are important
> to
> > me :)
> > And a lot of people I know feel the same.
> >
> > On Wed, Oct 5, 2011 at 5:26 PM, Mark Thornton <mthornton at optrak.com>
> wrote:
> >
> >> On 05/10/11 16:15, Loic Descotte wrote:
> >> > Hi all,
> >> >
> >> > I was wondering if coin 2 (in JDK 8) would possibly include a
> >> "properties"
> >> > feature, to avoid writing getters and setters for all fields in our
> >> classes.
> >> >
> >> >
> >> The second answer (from Alex Miller) probably still applies
> >>
> >>
> >>
> http://stackoverflow.com/questions/710266/why-will-there-be-no-native-properties-in-java-7
> >>
> >> Mark Thornton
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Lo?c Descotte
> > 4 rue Joseph Fourier
> > 38000 Grenoble
> >
> > 06 23 23 36 80
> >
> >
>
>


From isidore at setgame.com  Wed Oct  5 09:40:37 2011
From: isidore at setgame.com (Llewellyn Falco)
Date: Wed, 5 Oct 2011 09:40:37 -0700
Subject: JDK 8 and properties
In-Reply-To: <CALKB1SV-32KrCJSogiZjUqm5PcQqjabozS541+_tKEkhkH80ow@mail.gmail.com>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
	<4E8C770A.3000206@optrak.com>
	<CAJSAXGnT949vc4c7Kum4g6CLE0dJcbmcO9XXqxidZzQ6Gz=KNg@mail.gmail.com>
	<CABLGb9x6700smZcjzBr+NnjUyeHZuwGC01q4iR0Sh-FEVZvgfw@mail.gmail.com>
	<CALKB1SV-32KrCJSogiZjUqm5PcQqjabozS541+_tKEkhkH80ow@mail.gmail.com>
Message-ID: <CAD_OyrGGFmUUsYoa3A6hDnJtDzBTBp7PjN8dfZuyErtHwys_6A@mail.gmail.com>

As long as we are not introducing suggestions ;-)

I'd really like autoboxing to work in arrays and generics

List<int> means List<Integer>


I'd also really like to have a base class to Collection and Arrays


From loic.descotte at gmail.com  Wed Oct  5 09:45:29 2011
From: loic.descotte at gmail.com (Loic Descotte)
Date: Wed, 5 Oct 2011 18:45:29 +0200
Subject: JDK 8 and properties
In-Reply-To: <CALKB1SV-32KrCJSogiZjUqm5PcQqjabozS541+_tKEkhkH80ow@mail.gmail.com>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
	<4E8C770A.3000206@optrak.com>
	<CAJSAXGnT949vc4c7Kum4g6CLE0dJcbmcO9XXqxidZzQ6Gz=KNg@mail.gmail.com>
	<CABLGb9x6700smZcjzBr+NnjUyeHZuwGC01q4iR0Sh-FEVZvgfw@mail.gmail.com>
	<CALKB1SV-32KrCJSogiZjUqm5PcQqjabozS541+_tKEkhkH80ow@mail.gmail.com>
Message-ID: <CAJSAXGnAkA59yvsJ-XRpoMF2itFiY2zAnBdSrMqMmKHguwYzUg@mail.gmail.com>

Yes lombok-like features would be great
It's a shame to be forced to use an external tool to do this :(

On Wed, Oct 5, 2011 at 6:29 PM, Rich Midwinter <rich.midwinter at gmail.com>wrote:

> You wouldn't need dot notation just to have generated getters/setters
> though. http://projectlombok.org/features/GetterSetter.html
>
> Personally, I have no need for dot notation but do use lombok's @Data
> frequently (even as a mostly server side guy). I'd have a slight preference
> for having a similar solution ship with Java.
>
> Rich.
>
>
> On 5 October 2011 17:11, Paul Benedict <pbenedict at apache.org> wrote:
>
>> Here's my opinion... Properties brings its own issues. Part of Java's
>> success is the readability of the language. If the dot notation is
>> used for properties, readability diminishes because it is no longer
>> apparent whether field access or method access is occuring.
>>
>> someObject.x = 1; // method call or field access?
>>
>> If another syntax is used, then I think it almost defeats the purpose
>> of the proposal in the first place; it also begs the question how is
>> that any "better" than simply calling the getter/setter directly.
>>
>> Paul
>>
>>
>> On Wed, Oct 5, 2011 at 11:05 AM, Loic Descotte <loic.descotte at gmail.com>
>> wrote:
>> > About Alex Miller answer,
>> >
>> > The consensus was not there at the beggining for lambdas, but it worked
>> > (even if it was hard, I admit)
>> >
>> > For the second point, I work on server side but properties are important
>> to
>> > me :)
>> > And a lot of people I know feel the same.
>> >
>> > On Wed, Oct 5, 2011 at 5:26 PM, Mark Thornton <mthornton at optrak.com>
>> wrote:
>> >
>> >> On 05/10/11 16:15, Loic Descotte wrote:
>> >> > Hi all,
>> >> >
>> >> > I was wondering if coin 2 (in JDK 8) would possibly include a
>> >> "properties"
>> >> > feature, to avoid writing getters and setters for all fields in our
>> >> classes.
>> >> >
>> >> >
>> >> The second answer (from Alex Miller) probably still applies
>> >>
>> >>
>> >>
>> http://stackoverflow.com/questions/710266/why-will-there-be-no-native-properties-in-java-7
>> >>
>> >> Mark Thornton
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > Lo?c Descotte
>> > 4 rue Joseph Fourier
>> > 38000 Grenoble
>> >
>> > 06 23 23 36 80
>> >
>> >
>>
>>
>


-- 
Lo?c Descotte
4 rue Joseph Fourier
38000 Grenoble

06 23 23 36 80


From serafin.sedano at abiquo.com  Wed Oct  5 09:50:22 2011
From: serafin.sedano at abiquo.com (Serafin Sedano)
Date: Wed, 5 Oct 2011 18:50:22 +0200
Subject: JDK 8 and properties
In-Reply-To: <CAJSAXGnAkA59yvsJ-XRpoMF2itFiY2zAnBdSrMqMmKHguwYzUg@mail.gmail.com>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
	<4E8C770A.3000206@optrak.com>
	<CAJSAXGnT949vc4c7Kum4g6CLE0dJcbmcO9XXqxidZzQ6Gz=KNg@mail.gmail.com>
	<CABLGb9x6700smZcjzBr+NnjUyeHZuwGC01q4iR0Sh-FEVZvgfw@mail.gmail.com>
	<CALKB1SV-32KrCJSogiZjUqm5PcQqjabozS541+_tKEkhkH80ow@mail.gmail.com>
	<CAJSAXGnAkA59yvsJ-XRpoMF2itFiY2zAnBdSrMqMmKHguwYzUg@mail.gmail.com>
Message-ID: <CA+uJM+kNUc=O276pF9-qGx8tu9wWzqr3W3p5bmU3Ky34A=fFRQ@mail.gmail.com>

Rather that autogenerate setters and getters I'd like to see a full
integration. I way to access those variables that where less verbose. Where
no need for call to setObject nor getObject.

Just my opinion thou.

Regards.

Seraf?n.

2011/10/5 Loic Descotte <loic.descotte at gmail.com>

> Yes lombok-like features would be great
> It's a shame to be forced to use an external tool to do this :(
>
> On Wed, Oct 5, 2011 at 6:29 PM, Rich Midwinter <rich.midwinter at gmail.com
> >wrote:
>
> > You wouldn't need dot notation just to have generated getters/setters
> > though. http://projectlombok.org/features/GetterSetter.html
> >
> > Personally, I have no need for dot notation but do use lombok's @Data
> > frequently (even as a mostly server side guy). I'd have a slight
> preference
> > for having a similar solution ship with Java.
> >
> > Rich.
> >
> >
> > On 5 October 2011 17:11, Paul Benedict <pbenedict at apache.org> wrote:
> >
> >> Here's my opinion... Properties brings its own issues. Part of Java's
> >> success is the readability of the language. If the dot notation is
> >> used for properties, readability diminishes because it is no longer
> >> apparent whether field access or method access is occuring.
> >>
> >> someObject.x = 1; // method call or field access?
> >>
> >> If another syntax is used, then I think it almost defeats the purpose
> >> of the proposal in the first place; it also begs the question how is
> >> that any "better" than simply calling the getter/setter directly.
> >>
> >> Paul
> >>
> >>
> >> On Wed, Oct 5, 2011 at 11:05 AM, Loic Descotte <loic.descotte at gmail.com
> >
> >> wrote:
> >> > About Alex Miller answer,
> >> >
> >> > The consensus was not there at the beggining for lambdas, but it
> worked
> >> > (even if it was hard, I admit)
> >> >
> >> > For the second point, I work on server side but properties are
> important
> >> to
> >> > me :)
> >> > And a lot of people I know feel the same.
> >> >
> >> > On Wed, Oct 5, 2011 at 5:26 PM, Mark Thornton <mthornton at optrak.com>
> >> wrote:
> >> >
> >> >> On 05/10/11 16:15, Loic Descotte wrote:
> >> >> > Hi all,
> >> >> >
> >> >> > I was wondering if coin 2 (in JDK 8) would possibly include a
> >> >> "properties"
> >> >> > feature, to avoid writing getters and setters for all fields in our
> >> >> classes.
> >> >> >
> >> >> >
> >> >> The second answer (from Alex Miller) probably still applies
> >> >>
> >> >>
> >> >>
> >>
> http://stackoverflow.com/questions/710266/why-will-there-be-no-native-properties-in-java-7
> >> >>
> >> >> Mark Thornton
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Lo?c Descotte
> >> > 4 rue Joseph Fourier
> >> > 38000 Grenoble
> >> >
> >> > 06 23 23 36 80
> >> >
> >> >
> >>
> >>
> >
>
>
> --
> Lo?c Descotte
> 4 rue Joseph Fourier
> 38000 Grenoble
>
> 06 23 23 36 80
>
>


From brian.goetz at oracle.com  Wed Oct  5 11:50:49 2011
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 05 Oct 2011 14:50:49 -0400
Subject: JDK 8 and properties
In-Reply-To: <4E8C770A.3000206@optrak.com>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
	<4E8C770A.3000206@optrak.com>
Message-ID: <4E8CA709.4080308@oracle.com>

>> I was wondering if coin 2 (in JDK 8) would possibly include a "properties"
>> feature, to avoid writing getters and setters for all fields in our classes.
>>
> The second answer (from Alex Miller) probably still applies
>
> http://stackoverflow.com/questions/710266/why-will-there-be-no-native-properties-in-java-7

In fact, both answers still apply.

Part of the problem is everyone says "we want properties", but when you 
start digging, you find that it is like the blind men and the elephant 
-- everyone has a different idea of what it should be, and many are 
incompatible.  So even if 100% of the community thinks they want 
properties, if we actually did it, a significant fraction of those would 
be disappointed that we "waited fifteen years and then got it wrong."

With regard to Coin, properties are too big to be Coin features, it 
would require a separate JSR.  And, there's no way it could happen for 
8, even if we thought there was the right design out there (of which we 
are still not convinced.)  We've got too many other big language things 
on the docket for 8; that plate is full.





From brucechapman at paradise.net.nz  Thu Oct  6 01:18:33 2011
From: brucechapman at paradise.net.nz (Bruce Chapman)
Date: Thu, 06 Oct 2011 21:18:33 +1300
Subject: JDK 8 and properties
In-Reply-To: <CAJSAXGnAkA59yvsJ-XRpoMF2itFiY2zAnBdSrMqMmKHguwYzUg@mail.gmail.com>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
	<4E8C770A.3000206@optrak.com>
	<CAJSAXGnT949vc4c7Kum4g6CLE0dJcbmcO9XXqxidZzQ6Gz=KNg@mail.gmail.com>
	<CABLGb9x6700smZcjzBr+NnjUyeHZuwGC01q4iR0Sh-FEVZvgfw@mail.gmail.com>
	<CALKB1SV-32KrCJSogiZjUqm5PcQqjabozS541+_tKEkhkH80ow@mail.gmail.com>
	<CAJSAXGnAkA59yvsJ-XRpoMF2itFiY2zAnBdSrMqMmKHguwYzUg@mail.gmail.com>
Message-ID: <4E8D6459.4000506@paradise.net.nz>

On 6/10/2011 5:45 a.m., Loic Descotte wrote:
> Yes lombok-like features would be great
> It's a shame to be forced to use an external tool to do this :(

I am fairly certain that a lombok style solution can be made to work in 
a standard way. If that is the case, then it is not a language feature 
at all.

When I can drag myself away from the embedded development that is 
consuming more than a healthy proportion of both my mind and my time, I 
might have do a quick proof of concept. If someone else wants to have a 
go, I can point them in the direction I am thinking.

Bruce
>
> On Wed, Oct 5, 2011 at 6:29 PM, Rich Midwinter<rich.midwinter at gmail.com>wrote:
>
>> You wouldn't need dot notation just to have generated getters/setters
>> though. http://projectlombok.org/features/GetterSetter.html
>>
>> Personally, I have no need for dot notation but do use lombok's @Data
>> frequently (even as a mostly server side guy). I'd have a slight preference
>> for having a similar solution ship with Java.
>>
>> Rich.
>>
>>
>> On 5 October 2011 17:11, Paul Benedict<pbenedict at apache.org>  wrote:
>>
>>> Here's my opinion... Properties brings its own issues. Part of Java's
>>> success is the readability of the language. If the dot notation is
>>> used for properties, readability diminishes because it is no longer
>>> apparent whether field access or method access is occuring.
>>>
>>> someObject.x = 1; // method call or field access?
>>>
>>> If another syntax is used, then I think it almost defeats the purpose
>>> of the proposal in the first place; it also begs the question how is
>>> that any "better" than simply calling the getter/setter directly.
>>>
>>> Paul
>>>
>>>
>>> On Wed, Oct 5, 2011 at 11:05 AM, Loic Descotte<loic.descotte at gmail.com>
>>> wrote:
>>>> About Alex Miller answer,
>>>>
>>>> The consensus was not there at the beggining for lambdas, but it worked
>>>> (even if it was hard, I admit)
>>>>
>>>> For the second point, I work on server side but properties are important
>>> to
>>>> me :)
>>>> And a lot of people I know feel the same.
>>>>
>>>> On Wed, Oct 5, 2011 at 5:26 PM, Mark Thornton<mthornton at optrak.com>
>>> wrote:
>>>>> On 05/10/11 16:15, Loic Descotte wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I was wondering if coin 2 (in JDK 8) would possibly include a
>>>>> "properties"
>>>>>> feature, to avoid writing getters and setters for all fields in our
>>>>> classes.
>>>>>>
>>>>> The second answer (from Alex Miller) probably still applies
>>>>>
>>>>>
>>>>>
>>> http://stackoverflow.com/questions/710266/why-will-there-be-no-native-properties-in-java-7
>>>>> Mark Thornton
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Lo?c Descotte
>>>> 4 rue Joseph Fourier
>>>> 38000 Grenoble
>>>>
>>>> 06 23 23 36 80
>>>>
>>>>
>>>
>



From scolebourne at joda.org  Thu Oct  6 02:28:38 2011
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 6 Oct 2011 10:28:38 +0100
Subject: JDK 8 and properties
In-Reply-To: <4E8D6459.4000506@paradise.net.nz>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
	<4E8C770A.3000206@optrak.com>
	<CAJSAXGnT949vc4c7Kum4g6CLE0dJcbmcO9XXqxidZzQ6Gz=KNg@mail.gmail.com>
	<CABLGb9x6700smZcjzBr+NnjUyeHZuwGC01q4iR0Sh-FEVZvgfw@mail.gmail.com>
	<CALKB1SV-32KrCJSogiZjUqm5PcQqjabozS541+_tKEkhkH80ow@mail.gmail.com>
	<CAJSAXGnAkA59yvsJ-XRpoMF2itFiY2zAnBdSrMqMmKHguwYzUg@mail.gmail.com>
	<4E8D6459.4000506@paradise.net.nz>
Message-ID: <CACzrW9Dx4t4gUoTM1Xuku08c3ue42RHG673h=WH4D4UJRTmprw@mail.gmail.com>

On 6 October 2011 09:18, Bruce Chapman <brucechapman at paradise.net.nz> wrote:
> On 6/10/2011 5:45 a.m., Loic Descotte wrote:
>> Yes lombok-like features would be great
>> It's a shame to be forced to use an external tool to do this :(
>
> I am fairly certain that a lombok style solution can be made to work in
> a standard way. If that is the case, then it is not a language feature
> at all.

Simply generating the getter, setter, equals and hashcode is only part
of the problem. There also need to be a way to enumerate/loop over the
properties. Without this, each framework will continue to write their
own "bean introspector".

My work in this area is Joda-Beans, http://joda-beans.sourceforge.net/
which uses simple but effective repetitive code generation (ie. not
one-off code generation). I'd love to have someone join the project
and write an Eclipse plugin to regenerate within the IDE and hide/fold
the auto-generated code. There is also an opportunity for someone to
add invoke dynamic for a Java 7 specific version.

Part of the purpose of Joda-Beans is to test out an API and design for
properties. Being used in OpenGamma http://developers.opengamma.com/
(a large open source stack for finance) is the perfect test.

Stephen


From joe.darcy at oracle.com  Thu Oct  6 07:52:47 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 06 Oct 2011 07:52:47 -0700
Subject: JDK 8 and properties
In-Reply-To: <4E8D6459.4000506@paradise.net.nz>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>	<4E8C770A.3000206@optrak.com>	<CAJSAXGnT949vc4c7Kum4g6CLE0dJcbmcO9XXqxidZzQ6Gz=KNg@mail.gmail.com>	<CABLGb9x6700smZcjzBr+NnjUyeHZuwGC01q4iR0Sh-FEVZvgfw@mail.gmail.com>	<CALKB1SV-32KrCJSogiZjUqm5PcQqjabozS541+_tKEkhkH80ow@mail.gmail.com>	<CAJSAXGnAkA59yvsJ-XRpoMF2itFiY2zAnBdSrMqMmKHguwYzUg@mail.gmail.com>
	<4E8D6459.4000506@paradise.net.nz>
Message-ID: <4E8DC0BF.1010506@oracle.com>

Bruce Chapman wrote:
> On 6/10/2011 5:45 a.m., Loic Descotte wrote:
>   
>> Yes lombok-like features would be great
>> It's a shame to be forced to use an external tool to do this :(
>>     
>
> I am fairly certain that a lombok style solution can be made to work in 
> a standard way. If that is the case, then it is not a language feature 
> at all.
>
> When I can drag myself away from the embedded development that is 
> consuming more than a healthy proportion of both my mind and my time, I 
> might have do a quick proof of concept. If someone else wants to have a 
> go, I can point them in the direction I am thinking.
>   

FWIW, I wrote up a proof of concept implementation of properties support 
via standard annotation processing a few years ago:

http://blogs.oracle.com/darcy/entry/properties_via_annotation_processing

-Joe


From brian.goetz at oracle.com  Thu Oct  6 08:43:33 2011
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 06 Oct 2011 11:43:33 -0400
Subject: JEP process and Coin
Message-ID: <4E8DCCA5.1080101@oracle.com>

There have been a number of questions on this list about the JEP process 
[1], and how it relates to Project Coin.

JEP stands for "JDK Enhancement Proposal", and is part of our process 
for building a technical roadmap for the Java platform.  Filing a JEP 
(what we used to called a "one pager") is the first step towards 
inclusion of a proposed feature in the JDK.

The JEP process document linked below outlines the states a JEP can go 
through, from Draft (we're just talking) to Submitted (I think this is 
good enough to review) to Candidate (Group/Area leads think the idea has 
enough merit to not toss out) to Funded (someone has actually committed 
resources to making it happen.)  The last transition -- to Funded -- is 
the one at which this goes from being an idea to being part of the plan 
for some JDK release.

Note that the JEP process is not exclusively, or even primarily, 
intended for Java language changes (the JDK is far bigger than the Java 
language!)  The bar for language features will remain quite high, and in 
reality any language change will require a great deal of funding from 
Oracle.  Further, significant language changes will also still require a 
standalone JSR.

What JEP is not: it is not a "suggestion box" for drive-by requests. 
The JEP process is open to JDK *committers*, and it is unlikely a JEP 
will gain funding if the author is not prepared to contribute 
significant effort to the project's implementation or stewardship.

So, how does this relate to Coin?  Not to minimize the substantial 
community contribution to Coin, Sun and Oracle still contributed 
considerable effort and funding to validating, implementing, and testing 
the Coin features that were eventually included in Java SE 7.  Had the 
JEP process been in place at the time Coin was started, the likely use 
would have been that the Coin process selected features for inclusion 
through exact same process as was used, and then Sun would have 
sponsored and funded a JEP for each of the selected features (just as 
Sun stewarded them through the JCP process), and this seems a sensible 
model for future Coin-style enhancements.


[1] http://openjdk.java.net/jeps/1


From jantonio.illescas at rbcdexia-is.es  Fri Oct  7 04:34:31 2011
From: jantonio.illescas at rbcdexia-is.es (Jose Antonio Illescas Del Olmo)
Date: Fri, 07 Oct 2011 13:34:31 +0200
Subject: Please rethink extended enums inclusion
Message-ID: <4E8EE3C7.5040108@rbcdexia-is.es>

Now we have hundred of enums on our project (finantial application with 
120.000 lines) an repeat same code on any enum... (*mark as red*)


* Map our enums with old legacy system codes:

    public enum Type {

       ONE("01), TWO("03"), THREE("03"), ...;

       private Type(String code) {
           setCode(code);
       }

*      private String code;
*
*    public String code() {
           return code;
       }

       public void setCode(String code) {
           this.code = code;
       }

**      public static Type fromCode(String code) {
           if (code == null) return null;
           for(Type type: values()) {
              if (type.code.equals(code) return type;
           }
           return null;
       }

**      public boolean in(Type... types) {  // IMO all enums must have 
this method
           if (types == null) return false;
           for(Type type: types) {
              if (this == type) return true;
           }
           return false;
       }
*
Or with cache to avoid for iteration on fromCode(String) method => more 
code is necesary

public enum Type {

       ONE("01), TWO("03"), THREE("03"), ...;

       private Type(String code) {
           setCode(code);
       }

*      private String code;

**      private static Map<String, Type> cache= new HashMap<String,Type>();

       static {
           for(Type type: Type.values()) {
              cache.put(type.code(), type);
           }
       }
*
*    public String code() {
           return code;
       }

       public void setCode(String code) {
           this.code = code;
       }

**      public static Type fromCode(String code) {
           return cache.get(code);
       }

**      public boolean in(Type... types) {  // IMO all enums must have 
this method
           if (types == null) return false;
           for(Type type: types) {
              if (this == type) return true;
           }
           return false;
       }*

/Abstract enums with Generic support reduce dramatically the code of 
enums, see next code that use abstract enums:
/
*public enum Type extends MyAbstractEnum<String> {

       ONE("01), TWO("03"), THREE("03"), ...;

       private Type(String code) {
           super(code);
       }
   }*



From henrigerrits at yahoo.com  Fri Oct  7 05:32:20 2011
From: henrigerrits at yahoo.com (Henri Gerrits)
Date: Fri, 7 Oct 2011 05:32:20 -0700 (PDT)
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E8EE3C7.5040108@rbcdexia-is.es>
References: <4E8EE3C7.5040108@rbcdexia-is.es>
Message-ID: <1317990740.20878.YahooMailNeo@web160713.mail.bf1.yahoo.com>

Hi Jose Antonio,
?
I have some issues with your proposal:
?
1. Inserting a superclass with new methods might break many existing enums
2. Why do you need a code field? The name() method already returns a unique value.? The static valueOf() method can then be used instead of your fromCode() method.? I don't think caching makes much sense with enums, since the number of possible values are usually fairly small
3. Although the in(T...) method does look nice at the call site, I think it has nothing to do with the?enum; it belongs to a collection class (as "contains()", which admittedly means you need?to have a collection instance at the call site)
4. You could also implement the in(T...) method?by "mixing in" a?(generic) interface?using?an extension?method
?
Best regards,
?
Henri

From: Jose Antonio Illescas Del Olmo <jantonio.illescas at rbcdexia-is.es>
>To: coin-dev at openjdk.java.net
>Sent: Friday, October 7, 2011 7:34 AM
>Subject: Please rethink extended enums inclusion
>
>Now we have hundred of enums on our project (finantial application with 
>120.000 lines) an repeat same code on any enum... (*mark as red*)
>
>
>* Map our enums with old legacy system codes:
>
>? ? public enum Type {
>
>? ? ? ONE("01), TWO("03"), THREE("03"), ...;
>
>? ? ? private Type(String code) {
>? ? ? ? ? setCode(code);
>? ? ? }
>
>*? ? ? private String code;
>*
>*? ? public String code() {
>? ? ? ? ? return code;
>? ? ? }
>
>? ? ? public void setCode(String code) {
>? ? ? ? ? this.code = code;
>? ? ? }
>
>**? ? ? public static Type fromCode(String code) {
>? ? ? ? ? if (code == null) return null;
>? ? ? ? ? for(Type type: values()) {
>? ? ? ? ? ? ? if (type.code.equals(code) return type;
>? ? ? ? ? }
>? ? ? ? ? return null;
>? ? ? }
>
>**? ? ? public boolean in(Type... types) {? // IMO all enums must have 
>this method
>? ? ? ? ? if (types == null) return false;
>? ? ? ? ? for(Type type: types) {
>? ? ? ? ? ? ? if (this == type) return true;
>? ? ? ? ? }
>? ? ? ? ? return false;
>? ? ? }
>*
>Or with cache to avoid for iteration on fromCode(String) method => more 
>code is necesary
>
>public enum Type {
>
>? ? ? ONE("01), TWO("03"), THREE("03"), ...;
>
>? ? ? private Type(String code) {
>? ? ? ? ? setCode(code);
>? ? ? }
>
>*? ? ? private String code;
>
>**? ? ? private static Map<String, Type> cache= new HashMap<String,Type>();
>
>? ? ? static {
>? ? ? ? ? for(Type type: Type.values()) {
>? ? ? ? ? ? ? cache.put(type.code(), type);
>? ? ? ? ? }
>? ? ? }
>*
>*? ? public String code() {
>? ? ? ? ? return code;
>? ? ? }
>
>? ? ? public void setCode(String code) {
>? ? ? ? ? this.code = code;
>? ? ? }
>
>**? ? ? public static Type fromCode(String code) {
>? ? ? ? ? return cache.get(code);
>? ? ? }
>
>**? ? ? public boolean in(Type... types) {? // IMO all enums must have 
>this method
>? ? ? ? ? if (types == null) return false;
>? ? ? ? ? for(Type type: types) {
>? ? ? ? ? ? ? if (this == type) return true;
>? ? ? ? ? }
>? ? ? ? ? return false;
>? ? ? }*
>
>/Abstract enums with Generic support reduce dramatically the code of 
>enums, see next code that use abstract enums:
>/
>*public enum Type extends MyAbstractEnum<String> {
>
>? ? ? ONE("01), TWO("03"), THREE("03"), ...;
>
>? ? ? private Type(String code) {
>? ? ? ? ? super(code);
>? ? ? }
>? }*
>
>
>
>
>

From tom.hawtin at oracle.com  Fri Oct  7 05:38:25 2011
From: tom.hawtin at oracle.com (Tom Hawtin)
Date: Fri, 07 Oct 2011 13:38:25 +0100
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E8EE3C7.5040108@rbcdexia-is.es>
References: <4E8EE3C7.5040108@rbcdexia-is.es>
Message-ID: <4E8EF2C1.3080806@oracle.com>

On 07/10/2011 12:34, Jose Antonio Illescas Del Olmo wrote:
> Now we have hundred of enums on our project (finantial application with
> 120.000 lines) an repeat same code on any enum... (*mark as red*)

>      public enum Type {

[...]
>         public void setCode(String code) {
>             this.code = code;

I have to point out that mutable enums, or other statics, is generally a 
*really* bad idea. (Also a non-null check here wouldn't go amiss.)

It seems what we want here is a mutable Map<String,E extends Enum<E>>, 
which is easy enough.

 > **      public static Type fromCode(String code) {

Your inheritance wont work here. not unless you do something really dodgy.

> **      public boolean in(Type... types) {  // IMO all enums must have
> this method
>             if (types == null) return false;
>             for(Type type: types) {
>                if (this == type) return true;
>             }
>             return false;
>         }

     asList(a, b, c).contains(en)

Collection literals would help marginally.

Even if you were going for mutable statics (and I still strongly suggest 
you don't) it doesn't seem a difficult problem, so long as you don't 
require these methods within the enum itself. Just introduce a class 
that contains the mapping, and add an instance to each enum. You may 
need to implement a one-method interface if you want to initialise the 
mappings from MyEnum.values().

Tom


From jantonio.illescas at rbcdexia-is.es  Fri Oct  7 06:18:35 2011
From: jantonio.illescas at rbcdexia-is.es (Jose Antonio Illescas Del Olmo)
Date: Fri, 07 Oct 2011 15:18:35 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <1317990740.20878.YahooMailNeo@web160713.mail.bf1.yahoo.com>
References: <4E8EE3C7.5040108@rbcdexia-is.es>
	<1317990740.20878.YahooMailNeo@web160713.mail.bf1.yahoo.com>
Message-ID: <4E8EFC2B.4030607@rbcdexia-is.es>

On 07/10/2011 14:32, Henri Gerrits wrote:
> Hi Jose Antonio,
> I have some issues with your proposal:
> 1. Inserting a superclass with new methods might break many existing enums

Why? I decide when extends from custom abstract enum (checking that 
works fine) other enums (extends from "standard" enum) and works as ever.

> 2. Why do you need a code field? The name() method already returns a 
> unique value.  The static valueOf() method can then be used instead of 
> your fromCode() method.  I don't think caching makes much sense with 
> enums, since the number of possible values are usually fairly small

We have many communications with other finantial entities that use 
"standard protocols" with custom codes, while our application use 
descriptive enum names (on enums maps this relation between enums and 
codes).

Our enums can parse from "standard codes" to enums and viceversa.

> 3. Although the in(T...) method does look nice at the call site, I 
> think it has nothing to do with the enum; it belongs to a collection 
> class (as "contains()", which admittedly means you need to have a 
> collection instance at the call site)
:-(

> 4. You could also implement the in(T...) method by "mixing in" 
> a (generic) interface using an extension method
>
Sure, but I like if this method exist for any enum...

> Best regards,

Thank you, Henri
> Henri
>
>     *From:* Jose Antonio Illescas Del Olmo
>     <jantonio.illescas at rbcdexia-is.es>
>     *To:* coin-dev at openjdk.java.net
>     *Sent:* Friday, October 7, 2011 7:34 AM
>     *Subject:* Please rethink extended enums inclusion
>
>     Now we have hundred of enums on our project (finantial application
>     with
>     120.000 lines) an repeat same code on any enum... (*mark as red*)
>
>
>     * Map our enums with old legacy system codes:
>
>         public enum Type {
>
>           ONE("01), TWO("03"), THREE("03"), ...;
>
>           private Type(String code) {
>               setCode(code);
>           }
>
>     *      private String code;
>     *
>     *    public String code() {
>               return code;
>           }
>
>           public void setCode(String code) {
>               this.code = code;
>           }
>
>     **      public static Type fromCode(String code) {
>               if (code == null) return null;
>               for(Type type: values()) {
>                   if (type.code.equals(code) return type;
>               }
>               return null;
>           }
>
>     **      public boolean in(Type... types) {  // IMO all enums must
>     have
>     this method
>               if (types == null) return false;
>               for(Type type: types) {
>                   if (this == type) return true;
>               }
>               return false;
>           }
>     *
>     Or with cache to avoid for iteration on fromCode(String) method =>
>     more
>     code is necesary
>
>     public enum Type {
>
>           ONE("01), TWO("03"), THREE("03"), ...;
>
>           private Type(String code) {
>               setCode(code);
>           }
>
>     *      private String code;
>
>     **      private static Map<String, Type> cache= new
>     HashMap<String,Type>();
>
>           static {
>               for(Type type: Type.values()) {
>                   cache.put(type.code(), type);
>               }
>           }
>     *
>     *    public String code() {
>               return code;
>           }
>
>           public void setCode(String code) {
>               this.code = code;
>           }
>
>     **      public static Type fromCode(String code) {
>               return cache.get(code);
>           }
>
>     **      public boolean in(Type... types) {  // IMO all enums must
>     have
>     this method
>               if (types == null) return false;
>               for(Type type: types) {
>                   if (this == type) return true;
>               }
>               return false;
>           }*
>
>     /Abstract enums with Generic support reduce dramatically the code of
>     enums, see next code that use abstract enums:
>     /
>     *public enum Type extends MyAbstractEnum<String> {
>
>           ONE("01), TWO("03"), THREE("03"), ...;
>
>           private Type(String code) {
>               super(code);
>           }
>       }*
>
>
>
>



From jantonio.illescas at rbcdexia-is.es  Fri Oct  7 06:34:50 2011
From: jantonio.illescas at rbcdexia-is.es (Jose Antonio Illescas Del Olmo)
Date: Fri, 07 Oct 2011 15:34:50 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E8EF2C1.3080806@oracle.com>
References: <4E8EE3C7.5040108@rbcdexia-is.es> <4E8EF2C1.3080806@oracle.com>
Message-ID: <4E8EFFFA.6090106@rbcdexia-is.es>

On 07/10/2011 14:38, Tom Hawtin wrote:
> On 07/10/2011 12:34, Jose Antonio Illescas Del Olmo wrote:
>> Now we have hundred of enums on our project (finantial application with
>> 120.000 lines) an repeat same code on any enum... (*mark as red*)
>>       public enum Type {
> [...]
>>          public void setCode(String code) {
>>              this.code = code;
> I have to point out that mutable enums, or other statics, is generally a
> *really* bad idea. (Also a non-null check here wouldn't go amiss.)
>
Sorry, I don't understand you. Where is the mutable enums that you say?


> It seems what we want here is a mutable Map<String,E extends Enum<E>>,
> which is easy enough.
>
>   >  **      public static Type fromCode(String code) {
>
> Your inheritance wont work here. not unless you do something really dodgy.

It's true, I really need next method on MyAbstractEnum:

     public static <T extends Enum<T>> T fromCode(Class<T> enumType, 
String code)  // similar to JDK Enum.valueOf(Class<T>, String) method

and call from my Concrete enum:

   public static Type fromCode(String code) {
      return fromCode(Type.class, code);
   }




>> **      public boolean in(Type... types) {  // IMO all enums must have
>> this method
>>              if (types == null) return false;
>>              for(Type type: types) {
>>                 if (this == type) return true;
>>              }
>>              return false;
>>          }
>       asList(a, b, c).contains(en)
>
> Collection literals would help marginally.
>
It's true, but I think that this must be on java.lang.Enum.

> Even if you were going for mutable statics (and I still strongly suggest
> you don't) it doesn't seem a difficult problem, so long as you don't
> require these methods within the enum itself.

Tom I don't understand what say (Please be patient, english is not my 
native language)

>   Just introduce a class
> that contains the mapping, and add an instance to each enum. You may
> need to implement a one-method interface if you want to initialise the
> mappings from MyEnum.values().

But one additional class for every enum (exist more than 350 enums on my 
application) add to many code to map code-enum (I like to remove 
unnecesar code)
> Tom
>
>
Thank you, Tom


From Kai.Kunstmann at combase.de  Fri Oct  7 06:48:39 2011
From: Kai.Kunstmann at combase.de (Kai Kunstmann)
Date: Fri, 7 Oct 2011 15:48:39 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E8EE3C7.5040108@rbcdexia-is.es>
References: <4E8EE3C7.5040108@rbcdexia-is.es>
Message-ID: <1317995319.1766.269.camel@kak-box.cag.combase.de>

Hi,

I think, options are limitless, if you out-factor everything into a
helper class with some static magic:


public class Enums
{
  private final static Cache CACHE = new Cache();
  
  private static class Cache
  {
    ...
  }
  
  public static <E extends Enum<?>> void register(E const, Object code)
  {
    CACHE.put(const, code);
  }
  
  public static <E extends Enum<?>> E get(Class<E> type, Object code)
  {
    return CACHE.get(type, code);
  }
  
  // also, have a look at java.util.EnumSet
  public static boolean in(E needle, E ... haystack)
  {
    ...
  }
}


public enum Sample
{
  ONE("one"), TWO("two"), TEN("ten");
  
  private Sample(String code)
  {
    Enums.register(this, code);
  }
}


public class Client
{
  public void doSomething(Object code)
  {
    Enums.get(Sample.class, code);
  }
}


You can probably adopt the example to your needs. Just make sure you
don't get any race conditions or memory leaks in the Cache code.

By the way, since the registration() code should be executed rarely, you
can make it expensive and check for what ever conditions you like (e.g.
call-stack analyses). You can also force a certain interface upon the
cachable enums or their code type by simply defining it:


public static <E extends Enum<E> & Special> void put(E const, Code code)


The caveat is, not to register() your constants results in a runtime
exception on the client side rather than a compile-time exception. This
can happen, if you simply forget to put the register() call in your
constructor code, or if you try to access a constant in a fancy way
before the corresponding enum class is initialized (which usually
happens the first time you "mention" the class).


Cheers,
Kai



Am Freitag, den 07.10.2011, 13:34 +0200 schrieb Jose Antonio Illescas
Del Olmo:
> Now we have hundred of enums on our project (finantial application with 
> 120.000 lines) an repeat same code on any enum... (*mark as red*)
> 
> 
> * Map our enums with old legacy system codes:
> 
>     public enum Type {
> 
>        ONE("01), TWO("03"), THREE("03"), ...;
> 
>        private Type(String code) {
>            setCode(code);
>        }
> 
> *      private String code;
> *
> *    public String code() {
>            return code;
>        }
> 
>        public void setCode(String code) {
>            this.code = code;
>        }
> 
> **      public static Type fromCode(String code) {
>            if (code == null) return null;
>            for(Type type: values()) {
>               if (type.code.equals(code) return type;
>            }
>            return null;
>        }
> 
> **      public boolean in(Type... types) {  // IMO all enums must have 
> this method
>            if (types == null) return false;
>            for(Type type: types) {
>               if (this == type) return true;
>            }
>            return false;
>        }
> *
> Or with cache to avoid for iteration on fromCode(String) method => more 
> code is necesary
> 
> public enum Type {
> 
>        ONE("01), TWO("03"), THREE("03"), ...;
> 
>        private Type(String code) {
>            setCode(code);
>        }
> 
> *      private String code;
> 
> **      private static Map<String, Type> cache= new HashMap<String,Type>();
> 
>        static {
>            for(Type type: Type.values()) {
>               cache.put(type.code(), type);
>            }
>        }
> *
> *    public String code() {
>            return code;
>        }
> 
>        public void setCode(String code) {
>            this.code = code;
>        }
> 
> **      public static Type fromCode(String code) {
>            return cache.get(code);
>        }
> 
> **      public boolean in(Type... types) {  // IMO all enums must have 
> this method
>            if (types == null) return false;
>            for(Type type: types) {
>               if (this == type) return true;
>            }
>            return false;
>        }*
> 
> /Abstract enums with Generic support reduce dramatically the code of 
> enums, see next code that use abstract enums:
> /
> *public enum Type extends MyAbstractEnum<String> {
> 
>        ONE("01), TWO("03"), THREE("03"), ...;
> 
>        private Type(String code) {
>            super(code);
>        }
>    }*
> 
> 




From pbenedict at apache.org  Fri Oct  7 06:53:24 2011
From: pbenedict at apache.org (Paul Benedict)
Date: Fri, 7 Oct 2011 08:53:24 -0500
Subject: Please rethink extended enums inclusion
In-Reply-To: <1317995319.1766.269.camel@kak-box.cag.combase.de>
References: <4E8EE3C7.5040108@rbcdexia-is.es>
	<1317995319.1766.269.camel@kak-box.cag.combase.de>
Message-ID: <CABLGb9xMbnJZUXC9fC6hEiZDPYxv-F187T1U8m2UUv_uoR-a4w@mail.gmail.com>

I thought the "abstract enum" proposal was one of the best needed
features of Java. After using enums in large software, a hierarchy of
shared code naturally develops, but such common code has to be
refactored into external classes for delegation. It's a shame
"abstract enum" hasn't been seen as important yet.

Paul

On Fri, Oct 7, 2011 at 8:48 AM, Kai Kunstmann <Kai.Kunstmann at combase.de> wrote:
> Hi,
>
> I think, options are limitless, if you out-factor everything into a
> helper class with some static magic:
>
>
> public class Enums
> {
> ?private final static Cache CACHE = new Cache();
>
> ?private static class Cache
> ?{
> ? ?...
> ?}
>
> ?public static <E extends Enum<?>> void register(E const, Object code)
> ?{
> ? ?CACHE.put(const, code);
> ?}
>
> ?public static <E extends Enum<?>> E get(Class<E> type, Object code)
> ?{
> ? ?return CACHE.get(type, code);
> ?}
>
> ?// also, have a look at java.util.EnumSet
> ?public static boolean in(E needle, E ... haystack)
> ?{
> ? ?...
> ?}
> }
>
>
> public enum Sample
> {
> ?ONE("one"), TWO("two"), TEN("ten");
>
> ?private Sample(String code)
> ?{
> ? ?Enums.register(this, code);
> ?}
> }
>
>
> public class Client
> {
> ?public void doSomething(Object code)
> ?{
> ? ?Enums.get(Sample.class, code);
> ?}
> }
>
>
> You can probably adopt the example to your needs. Just make sure you
> don't get any race conditions or memory leaks in the Cache code.
>
> By the way, since the registration() code should be executed rarely, you
> can make it expensive and check for what ever conditions you like (e.g.
> call-stack analyses). You can also force a certain interface upon the
> cachable enums or their code type by simply defining it:
>
>
> public static <E extends Enum<E> & Special> void put(E const, Code code)
>
>
> The caveat is, not to register() your constants results in a runtime
> exception on the client side rather than a compile-time exception. This
> can happen, if you simply forget to put the register() call in your
> constructor code, or if you try to access a constant in a fancy way
> before the corresponding enum class is initialized (which usually
> happens the first time you "mention" the class).
>
>
> Cheers,
> Kai
>
>
>
> Am Freitag, den 07.10.2011, 13:34 +0200 schrieb Jose Antonio Illescas
> Del Olmo:
>> Now we have hundred of enums on our project (finantial application with
>> 120.000 lines) an repeat same code on any enum... (*mark as red*)
>>
>>
>> * Map our enums with old legacy system codes:
>>
>> ? ? public enum Type {
>>
>> ? ? ? ?ONE("01), TWO("03"), THREE("03"), ...;
>>
>> ? ? ? ?private Type(String code) {
>> ? ? ? ? ? ?setCode(code);
>> ? ? ? ?}
>>
>> * ? ? ?private String code;
>> *
>> * ? ?public String code() {
>> ? ? ? ? ? ?return code;
>> ? ? ? ?}
>>
>> ? ? ? ?public void setCode(String code) {
>> ? ? ? ? ? ?this.code = code;
>> ? ? ? ?}
>>
>> ** ? ? ?public static Type fromCode(String code) {
>> ? ? ? ? ? ?if (code == null) return null;
>> ? ? ? ? ? ?for(Type type: values()) {
>> ? ? ? ? ? ? ? if (type.code.equals(code) return type;
>> ? ? ? ? ? ?}
>> ? ? ? ? ? ?return null;
>> ? ? ? ?}
>>
>> ** ? ? ?public boolean in(Type... types) { ?// IMO all enums must have
>> this method
>> ? ? ? ? ? ?if (types == null) return false;
>> ? ? ? ? ? ?for(Type type: types) {
>> ? ? ? ? ? ? ? if (this == type) return true;
>> ? ? ? ? ? ?}
>> ? ? ? ? ? ?return false;
>> ? ? ? ?}
>> *
>> Or with cache to avoid for iteration on fromCode(String) method => more
>> code is necesary
>>
>> public enum Type {
>>
>> ? ? ? ?ONE("01), TWO("03"), THREE("03"), ...;
>>
>> ? ? ? ?private Type(String code) {
>> ? ? ? ? ? ?setCode(code);
>> ? ? ? ?}
>>
>> * ? ? ?private String code;
>>
>> ** ? ? ?private static Map<String, Type> cache= new HashMap<String,Type>();
>>
>> ? ? ? ?static {
>> ? ? ? ? ? ?for(Type type: Type.values()) {
>> ? ? ? ? ? ? ? cache.put(type.code(), type);
>> ? ? ? ? ? ?}
>> ? ? ? ?}
>> *
>> * ? ?public String code() {
>> ? ? ? ? ? ?return code;
>> ? ? ? ?}
>>
>> ? ? ? ?public void setCode(String code) {
>> ? ? ? ? ? ?this.code = code;
>> ? ? ? ?}
>>
>> ** ? ? ?public static Type fromCode(String code) {
>> ? ? ? ? ? ?return cache.get(code);
>> ? ? ? ?}
>>
>> ** ? ? ?public boolean in(Type... types) { ?// IMO all enums must have
>> this method
>> ? ? ? ? ? ?if (types == null) return false;
>> ? ? ? ? ? ?for(Type type: types) {
>> ? ? ? ? ? ? ? if (this == type) return true;
>> ? ? ? ? ? ?}
>> ? ? ? ? ? ?return false;
>> ? ? ? ?}*
>>
>> /Abstract enums with Generic support reduce dramatically the code of
>> enums, see next code that use abstract enums:
>> /
>> *public enum Type extends MyAbstractEnum<String> {
>>
>> ? ? ? ?ONE("01), TWO("03"), THREE("03"), ...;
>>
>> ? ? ? ?private Type(String code) {
>> ? ? ? ? ? ?super(code);
>> ? ? ? ?}
>> ? ?}*
>>
>>
>
>
>
>


From jantonio.illescas at rbcdexia-is.es  Fri Oct  7 07:09:01 2011
From: jantonio.illescas at rbcdexia-is.es (Jose Antonio Illescas Del Olmo)
Date: Fri, 07 Oct 2011 16:09:01 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <1317995319.1766.269.camel@kak-box.cag.combase.de>
References: <4E8EE3C7.5040108@rbcdexia-is.es>
	<1317995319.1766.269.camel@kak-box.cag.combase.de>
Message-ID: <4E8F07FD.4030601@rbcdexia-is.es>

Hello Kai,

  See this as "generic" example, on my project exist more duplicate code 
on related enums that can not refactorize into superclass (by java 
limitations)

     Your option is good (considering java limitations) but is not clean 
from a object-oriented view...

Thank you, Kai




On 07/10/2011 15:48, Kai Kunstmann wrote:
> Hi,
>
> I think, options are limitless, if you out-factor everything into a
> helper class with some static magic:
>
>
> public class Enums
> {
>    private final static Cache CACHE = new Cache();
>
>    private static class Cache
>    {
>      ...
>    }
>
>    public static<E extends Enum<?>>  void register(E const, Object code)
>    {
>      CACHE.put(const, code);
>    }
>
>    public static<E extends Enum<?>>  E get(Class<E>  type, Object code)
>    {
>      return CACHE.get(type, code);
>    }
>
>    // also, have a look at java.util.EnumSet
>    public static boolean in(E needle, E ... haystack)
>    {
>      ...
>    }
> }
>
>
> public enum Sample
> {
>    ONE("one"), TWO("two"), TEN("ten");
>
>    private Sample(String code)
>    {
>      Enums.register(this, code);
>    }
> }
>
>
> public class Client
> {
>    public void doSomething(Object code)
>    {
>      Enums.get(Sample.class, code);
>    }
> }
>
>
> You can probably adopt the example to your needs. Just make sure you
> don't get any race conditions or memory leaks in the Cache code.
>
> By the way, since the registration() code should be executed rarely, you
> can make it expensive and check for what ever conditions you like (e.g.
> call-stack analyses). You can also force a certain interface upon the
> cachable enums or their code type by simply defining it:
>
>
> public static<E extends Enum<E>  &  Special>  void put(E const, Code code)
>
>
> The caveat is, not to register() your constants results in a runtime
> exception on the client side rather than a compile-time exception. This
> can happen, if you simply forget to put the register() call in your
> constructor code, or if you try to access a constant in a fancy way
> before the corresponding enum class is initialized (which usually
> happens the first time you "mention" the class).
>
>
> Cheers,
> Kai
>
>
>
> Am Freitag, den 07.10.2011, 13:34 +0200 schrieb Jose Antonio Illescas
> Del Olmo:
>> Now we have hundred of enums on our project (finantial application with
>> 120.000 lines) an repeat same code on any enum... (*mark as red*)
>>
>>
>> * Map our enums with old legacy system codes:
>>
>>      public enum Type {
>>
>>         ONE("01), TWO("03"), THREE("03"), ...;
>>
>>         private Type(String code) {
>>             setCode(code);
>>         }
>>
>> *      private String code;
>> *
>> *    public String code() {
>>             return code;
>>         }
>>
>>         public void setCode(String code) {
>>             this.code = code;
>>         }
>>
>> **      public static Type fromCode(String code) {
>>             if (code == null) return null;
>>             for(Type type: values()) {
>>                if (type.code.equals(code) return type;
>>             }
>>             return null;
>>         }
>>
>> **      public boolean in(Type... types) {  // IMO all enums must have
>> this method
>>             if (types == null) return false;
>>             for(Type type: types) {
>>                if (this == type) return true;
>>             }
>>             return false;
>>         }
>> *
>> Or with cache to avoid for iteration on fromCode(String) method =>  more
>> code is necesary
>>
>> public enum Type {
>>
>>         ONE("01), TWO("03"), THREE("03"), ...;
>>
>>         private Type(String code) {
>>             setCode(code);
>>         }
>>
>> *      private String code;
>>
>> **      private static Map<String, Type>  cache= new HashMap<String,Type>();
>>
>>         static {
>>             for(Type type: Type.values()) {
>>                cache.put(type.code(), type);
>>             }
>>         }
>> *
>> *    public String code() {
>>             return code;
>>         }
>>
>>         public void setCode(String code) {
>>             this.code = code;
>>         }
>>
>> **      public static Type fromCode(String code) {
>>             return cache.get(code);
>>         }
>>
>> **      public boolean in(Type... types) {  // IMO all enums must have
>> this method
>>             if (types == null) return false;
>>             for(Type type: types) {
>>                if (this == type) return true;
>>             }
>>             return false;
>>         }*
>>
>> /Abstract enums with Generic support reduce dramatically the code of
>> enums, see next code that use abstract enums:
>> /
>> *public enum Type extends MyAbstractEnum<String>  {
>>
>>         ONE("01), TWO("03"), THREE("03"), ...;
>>
>>         private Type(String code) {
>>             super(code);
>>         }
>>     }*
>>
>>
>
>
>



From tom.hawtin at oracle.com  Fri Oct  7 07:20:46 2011
From: tom.hawtin at oracle.com (Tom Hawtin)
Date: Fri, 07 Oct 2011 15:20:46 +0100
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E8EFFFA.6090106@rbcdexia-is.es>
References: <4E8EE3C7.5040108@rbcdexia-is.es> <4E8EF2C1.3080806@oracle.com>
	<4E8EFFFA.6090106@rbcdexia-is.es>
Message-ID: <4E8F0ABE.6080309@oracle.com>

On 07/10/2011 14:34, Jose Antonio Illescas Del Olmo wrote:
> On 07/10/2011 14:38, Tom Hawtin wrote:
>> On 07/10/2011 12:34, Jose Antonio Illescas Del Olmo wrote:
>>> Now we have hundred of enums on our project (finantial application with
>>> 120.000 lines) an repeat same code on any enum... (*mark as red*)
>>>        public enum Type {
>> [...]
>>>           public void setCode(String code) {
>>>               this.code = code;
>> I have to point out that mutable enums, or other statics, is generally a
>> *really* bad idea. (Also a non-null check here wouldn't go amiss.)
>>
> Sorry, I don't understand you. Where is the mutable enums that you say?

The `Type` enum is mutable. You can set the code field. Instances of 
enums are statics. Mutable statics are bad, and so therefore are mutable 
enums (and singletons). Plenty has been written about this. In the olden 
days, the same thing went under the heading of "globals".

http://www.google.co.uk/search?q=java+"mutable+enums"
http://www.google.co.uk/search?q=java+"mutable+statics"

>>    Just introduce a class
>> that contains the mapping, and add an instance to each enum. You may
>> need to implement a one-method interface if you want to initialise the
>> mappings from MyEnum.values().
>
> But one additional class for every enum (exist more than 350 enums on my
> application) add to many code to map code-enum (I like to remove
> unnecesar code)

No, just a single class with one instance per enum. That isn't much.

Tom


From isidore at setgame.com  Fri Oct  7 07:26:05 2011
From: isidore at setgame.com (Llewellyn Falco)
Date: Fri, 7 Oct 2011 07:26:05 -0700
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E8EFFFA.6090106@rbcdexia-is.es>
References: <4E8EE3C7.5040108@rbcdexia-is.es> <4E8EF2C1.3080806@oracle.com>
	<4E8EFFFA.6090106@rbcdexia-is.es>
Message-ID: <70BC887D-20E9-48A7-81E9-C9D59E25BDD7@setgame.com>

I *really* think that changing enum is a bad idea. It is one of the things java has done right and better than anyone else.

However, I am once again struck at how extension methods would help in this situation. 


Just to be clear. I mean c#/ruby extension methods where you can externally extend an object you don't control, as opposed to defender methods where you can put default method on interfaces you do control.

Sent from my iPad

On Oct 7, 2011, at 6:34 AM, Jose Antonio Illescas Del Olmo <jantonio.illescas at rbcdexia-is.es> wrote:

> On 07/10/2011 14:38, Tom 
>> On 07/10/2011 12:34, Jose Antonio Illescas Del Olmo wrote:
>>> Now we have hundred of enums on our project (finantial application with
>>> 120.000 lines) an repeat same code on any enum... (*mark as red*)
>>>      public enum Type {
>> [...]
>>>         public void setCode(String code) {
>>>             this.code = code;
>> I have to point out that mutable enums, or other statics, is generally a
>> *really* bad idea. (Also a non-null check here wouldn't go amiss.)
>> 
> Sorry, I don't understand you. Where is the mutable enums that you say?
> 
> 
>> It seems what we want here is a mutable Map<String,E extends Enum<E>>,
>> which is easy enough.
>> 
>>> **      public static Type fromCode(String code) {
>> 
>> Your inheritance wont work here. not unless you do something really dodgy.
> 
> It's true, I really need next method on MyAbstractEnum:
> 
>     public static <T extends Enum<T>> T fromCode(Class<T> enumType, 
> String code)  // similar to JDK Enum.valueOf(Class<T>, String) method
> 
> and call from my Concrete enum:
> 
>   public static Type fromCode(String code) {
>      return fromCode(Type.class, code);
>   }
> 
> 
> 
> 
>>> **      public boolean in(Type... types) {  // IMO all enums must have
>>> this method
>>>             if (types == null) return false;
>>>             for(Type type: types) {
>>>                if (this == type) return true;
>>>             }
>>>             return false;
>>>         }
>>      asList(a, b, c).contains(en)
>> 
>> Collection literals would help marginally.
>> 
> It's true, but I think that this must be on java.lang.Enum.
> 
>> Even if you were going for mutable statics (and I still strongly suggest
>> you don't) it doesn't seem a difficult problem, so long as you don't
>> require these methods within the enum itself.
> 
> Tom I don't understand what say (Please be patient, english is not my 
> native language)
> 
>>  Just introduce a class
>> that contains the mapping, and add an instance to each enum. You may
>> need to implement a one-method interface if you want to initialise the
>> mappings from MyEnum.values().
> 
> But one additional class for every enum (exist more than 350 enums on my 
> application) add to many code to map code-enum (I like to remove 
> unnecesar code)
>> Tom
>> 
>> 
> Thank you, Tom
> 


From jantonio.illescas at rbcdexia-is.es  Fri Oct  7 07:32:17 2011
From: jantonio.illescas at rbcdexia-is.es (Jose Antonio Illescas Del Olmo)
Date: Fri, 07 Oct 2011 16:32:17 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E8F0ABE.6080309@oracle.com>
References: <4E8EE3C7.5040108@rbcdexia-is.es>
	<4E8EF2C1.3080806@oracle.com>	<4E8EFFFA.6090106@rbcdexia-is.es>
	<4E8F0ABE.6080309@oracle.com>
Message-ID: <4E8F0D71.2000003@rbcdexia-is.es>

On 07/10/2011 16:20, Tom Hawtin wrote:
> On 07/10/2011 14:34, Jose Antonio Illescas Del Olmo wrote:
>> On 07/10/2011 14:38, Tom Hawtin wrote:
>>> On 07/10/2011 12:34, Jose Antonio Illescas Del Olmo wrote:
>>>> Now we have hundred of enums on our project (finantial application with
>>>> 120.000 lines) an repeat same code on any enum... (*mark as red*)
>>>>         public enum Type {
>>> [...]
>>>>            public void setCode(String code) {
>>>>                this.code = code;
>>> I have to point out that mutable enums, or other statics, is generally a
>>> *really* bad idea. (Also a non-null check here wouldn't go amiss.)
>>>
>> Sorry, I don't understand you. Where is the mutable enums that you say?

Tom, this is an error on my example (setCode must be private), sorry

> The `Type` enum is mutable. You can set the code field. Instances of
> enums are statics. Mutable statics are bad, and so therefore are mutable
> enums (and singletons). Plenty has been written about this. In the olden
> days, the same thing went under the heading of "globals".
>
> http://www.google.co.uk/search?q=java+"mutable+enums"
> http://www.google.co.uk/search?q=java+"mutable+statics"
>
>>>     Just introduce a class
>>> that contains the mapping, and add an instance to each enum. You may
>>> need to implement a one-method interface if you want to initialise the
>>> mappings from MyEnum.values().
>> But one additional class for every enum (exist more than 350 enums on my
>> application) add to many code to map code-enum (I like to remove
>> unnecesar code)
> No, just a single class with one instance per enum. That isn't much.
>
> Tom
>
>



From jantonio.illescas at rbcdexia-is.es  Fri Oct  7 07:34:23 2011
From: jantonio.illescas at rbcdexia-is.es (Jose Antonio Illescas Del Olmo)
Date: Fri, 07 Oct 2011 16:34:23 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <70BC887D-20E9-48A7-81E9-C9D59E25BDD7@setgame.com>
References: <4E8EE3C7.5040108@rbcdexia-is.es> <4E8EF2C1.3080806@oracle.com>
	<4E8EFFFA.6090106@rbcdexia-is.es>
	<70BC887D-20E9-48A7-81E9-C9D59E25BDD7@setgame.com>
Message-ID: <4E8F0DEF.3090702@rbcdexia-is.es>

There is an error on my example.

   code setter must be private, I don't needed to change the internal code

Sorry for my mistake

On 07/10/2011 16:26, Llewellyn Falco wrote:
> I *really* think that changing enum is a bad idea. It is one of the things java has done right and better than anyone else.
>
> However, I am once again struck at how extension methods would help in this situation.
>
>
> Just to be clear. I mean c#/ruby extension methods where you can externally extend an object you don't control, as opposed to defender methods where you can put default method on interfaces you do control.
>
> Sent from my iPad
>
> On Oct 7, 2011, at 6:34 AM, Jose Antonio Illescas Del Olmo<jantonio.illescas at rbcdexia-is.es>  wrote:
>
>> On 07/10/2011 14:38, Tom
>>> On 07/10/2011 12:34, Jose Antonio Illescas Del Olmo wrote:
>>>> Now we have hundred of enums on our project (finantial application with
>>>> 120.000 lines) an repeat same code on any enum... (*mark as red*)
>>>>       public enum Type {
>>> [...]
>>>>          public void setCode(String code) {
>>>>              this.code = code;
>>> I have to point out that mutable enums, or other statics, is generally a
>>> *really* bad idea. (Also a non-null check here wouldn't go amiss.)
>>>
>> Sorry, I don't understand you. Where is the mutable enums that you say?
>>
>>
>>> It seems what we want here is a mutable Map<String,E extends Enum<E>>,
>>> which is easy enough.
>>>
>>>> **      public static Type fromCode(String code) {
>>> Your inheritance wont work here. not unless you do something really dodgy.
>> It's true, I really need next method on MyAbstractEnum:
>>
>>      public static<T extends Enum<T>>  T fromCode(Class<T>  enumType,
>> String code)  // similar to JDK Enum.valueOf(Class<T>, String) method
>>
>> and call from my Concrete enum:
>>
>>    public static Type fromCode(String code) {
>>       return fromCode(Type.class, code);
>>    }
>>
>>
>>
>>
>>>> **      public boolean in(Type... types) {  // IMO all enums must have
>>>> this method
>>>>              if (types == null) return false;
>>>>              for(Type type: types) {
>>>>                 if (this == type) return true;
>>>>              }
>>>>              return false;
>>>>          }
>>>       asList(a, b, c).contains(en)
>>>
>>> Collection literals would help marginally.
>>>
>> It's true, but I think that this must be on java.lang.Enum.
>>
>>> Even if you were going for mutable statics (and I still strongly suggest
>>> you don't) it doesn't seem a difficult problem, so long as you don't
>>> require these methods within the enum itself.
>> Tom I don't understand what say (Please be patient, english is not my
>> native language)
>>
>>>   Just introduce a class
>>> that contains the mapping, and add an instance to each enum. You may
>>> need to implement a one-method interface if you want to initialise the
>>> mappings from MyEnum.values().
>> But one additional class for every enum (exist more than 350 enums on my
>> application) add to many code to map code-enum (I like to remove
>> unnecesar code)
>>> Tom
>>>
>>>
>> Thank you, Tom
>>



From jantonio.illescas at rbcdexia-is.es  Fri Oct  7 07:44:32 2011
From: jantonio.illescas at rbcdexia-is.es (Jose Antonio Illescas Del Olmo)
Date: Fri, 07 Oct 2011 16:44:32 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <CABLGb9xMbnJZUXC9fC6hEiZDPYxv-F187T1U8m2UUv_uoR-a4w@mail.gmail.com>
References: <4E8EE3C7.5040108@rbcdexia-is.es>	<1317995319.1766.269.camel@kak-box.cag.combase.de>
	<CABLGb9xMbnJZUXC9fC6hEiZDPYxv-F187T1U8m2UUv_uoR-a4w@mail.gmail.com>
Message-ID: <4E8F1050.70301@rbcdexia-is.es>

It's very important to reduce the large java code... (duplicate on all 
enums or delegated on external classes due to an enum extend limitation)



On 07/10/2011 15:53, Paul Benedict wrote:
> I thought the "abstract enum" proposal was one of the best needed
> features of Java. After using enums in large software, a hierarchy of
> shared code naturally develops, but such common code has to be
> refactored into external classes for delegation. It's a shame
> "abstract enum" hasn't been seen as important yet.
>



From jantonio.illescas at rbcdexia-is.es  Fri Oct  7 08:10:52 2011
From: jantonio.illescas at rbcdexia-is.es (Jose Antonio Illescas Del Olmo)
Date: Fri, 07 Oct 2011 17:10:52 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E8F1042.9010002@oracle.com>
References: <4E8EE3C7.5040108@rbcdexia-is.es>
	<4E8EF2C1.3080806@oracle.com>	<4E8EFFFA.6090106@rbcdexia-is.es>
	<4E8F0ABE.6080309@oracle.com> <4E8F0D71.2000003@rbcdexia-is.es>
	<4E8F1042.9010002@oracle.com>
Message-ID: <4E8F167C.2000608@rbcdexia-is.es>

Tom, also exists "utility" method:

    in(T...): boolean

Please, see this example as a simple scenario to use abstract enums, on 
my project exist more examples...

   On the past, prior to jdk 1.5, we can implement "enums" with 
hierarchies... and declare methods on abstract classes ("enums")

Did you known? www.extended-enums.org



On 07/10/2011 16:44, Tom Hawtin wrote:
> On 07/10/2011 15:32, Jose Antonio Illescas Del Olmo wrote:
>
>> Tom, this is an error on my example (setCode must be private), sorry
>
> Ah, so it'd be clearer if it didn't exist at all and code was made final.
>
> All that needs to be added per enum is a bit of boilerplate.
>
> Instead of (common pieces omitted):
>
>
> public enum Type extends CodeNamedEnum<Type> {
>
> private Type(String code) {
>     super(code);
> }
>
>
> We have:
>
>
> public enum Type implements CodeNamed  {
>
> private final String code;
>
> private Type(String code) {
>     this.code = code;
> }
>
> @Override public String code() {
>      return code;
> }
>
> public static final CodeMap<Type> CODES = new CodeMap<>(values());
>
>
> (Self-registration in the constructor is an alternative to the 
> interface, but makes CODES mutable (although there is a clean way of 
> protecting it from outsiders) and is somewhat tricky with respect to 
> initialisation order.)
>
>
> I don't think that is *so bad* that it requires a language change 
> (which I'm guessing wouldn't be a simple as it appears!).
>
> Tom
>



From henrigerrits at yahoo.com  Fri Oct  7 08:24:27 2011
From: henrigerrits at yahoo.com (Henri Gerrits)
Date: Fri, 7 Oct 2011 08:24:27 -0700 (PDT)
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E8EFC2B.4030607@rbcdexia-is.es>
References: <4E8EE3C7.5040108@rbcdexia-is.es>
	<1317990740.20878.YahooMailNeo@web160713.mail.bf1.yahoo.com>
	<4E8EFC2B.4030607@rbcdexia-is.es>
Message-ID: <1318001067.84923.YahooMailNeo@web160715.mail.bf1.yahoo.com>

From: Jose Antonio Illescas Del Olmo <jantonio.illescas at rbcdexia-is.es>
>To: Henri Gerrits <henrigerrits at yahoo.com>
>Cc: "coin-dev at openjdk.java.net" <coin-dev at openjdk.java.net>
>Sent: Friday, October 7, 2011 9:18 AM
>Subject: Re: Please rethink extended enums inclusion
>
>
>On 07/10/2011 14:32, Henri Gerrits wrote: 
>Hi Jose Antonio,
>>?
>>I have some issues with your proposal:
>>?
>>1. Inserting a superclass with new methods might break many existing enums
>
>Why? I decide when extends from custom abstract enum (checking that works fine) other enums (extends from "standard" enum) and works as ever.
?
I misunderstood - my mistake.
?
>
>2. Why do you need a code field? The name() method already returns a unique value.? The static valueOf() method can then be used instead of your fromCode() method.? I don't think caching makes much sense with enums, since the number of possible values are usually fairly small
>
>We have many communications with other finantial entities that use "standard protocols" with custom codes, while our application use descriptive enum names (on enums maps this relation between enums and codes).
>
>Our enums can parse from "standard codes" to enums and viceversa.
?
OK.? I don't know the details of your application but you might want to decouple the external protocol codes from your business code.? Maybe you can add?simple?"translator" classes used only in your interfaces?with the external entities.

>>>/Abstract enums with Generic support reduce dramatically the code of 
>>>enums, see next code that use abstract enums:
>>>/
>>>*public enum Type extends MyAbstractEnum<String> {
>>>
>>>? ? ? ONE("01), TWO("03"), THREE("03"), ...;
>>>
>>>? ? ? private Type(String code) {
>>>? ? ? ? ? super(code);
>>>? ? ? }
>>>? }*
>>>
?
I think that should read:
?
??public enum Type extends MyAbstractEnum<String, Type> {
?
because you need the subclass type ("Type") for the in() method in MyAbstractEnum.
?
Best regards,
?
Henri


From jantonio.illescas at rbcdexia-is.es  Fri Oct  7 08:35:34 2011
From: jantonio.illescas at rbcdexia-is.es (Jose Antonio Illescas Del Olmo)
Date: Fri, 07 Oct 2011 17:35:34 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <1318001067.84923.YahooMailNeo@web160715.mail.bf1.yahoo.com>
References: <4E8EE3C7.5040108@rbcdexia-is.es>
	<1317990740.20878.YahooMailNeo@web160713.mail.bf1.yahoo.com>
	<4E8EFC2B.4030607@rbcdexia-is.es>
	<1318001067.84923.YahooMailNeo@web160715.mail.bf1.yahoo.com>
Message-ID: <4E8F1C46.6040009@rbcdexia-is.es>

On 07/10/2011 17:24, Henri Gerrits wrote:
> From: Jose Antonio Illescas Del Olmo<jantonio.illescas at rbcdexia-is.es>
>> To: Henri Gerrits<henrigerrits at yahoo.com>
>> Cc: "coin-dev at openjdk.java.net"<coin-dev at openjdk.java.net>
>> Sent: Friday, October 7, 2011 9:18 AM
>> Subject: Re: Please rethink extended enums inclusion
>>
>>
>> On 07/10/2011 14:32, Henri Gerrits wrote:
>> Hi Jose Antonio,
>>>   
>>> I have some issues with your proposal:
>>>   
>>> 1. Inserting a superclass with new methods might break many existing enums
>> Why? I decide when extends from custom abstract enum (checking that works fine) other enums (extends from "standard" enum) and works as ever.
>   
> I misunderstood - my mistake.
>
>> 2. Why do you need a code field? The name() method already returns a unique value.  The static valueOf() method can then be used instead of your fromCode() method.  I don't think caching makes much sense with enums, since the number of possible values are usually fairly small
>>
>> We have many communications with other finantial entities that use "standard protocols" with custom codes, while our application use descriptive enum names (on enums maps this relation between enums and codes).
>>
>> Our enums can parse from "standard codes" to enums and viceversa.
>   
> OK.  I don't know the details of your application but you might want to decouple the external protocol codes from your business code.  Maybe you can add simple "translator" classes used only in your interfaces with the external entities.
>
The enum is my "translator",

    ? On some cases/enums I persist the code on database: our "new 
application" accesss to legacy tables used by other applications, and 
persists the enum code


>>>> /Abstract enums with Generic support reduce dramatically the code of
>>>> enums, see next code that use abstract enums:
>>>> /
>>>> *public enum Type extends MyAbstractEnum<String>  {
>>>>
>>>>        ONE("01), TWO("03"), THREE("03"), ...;
>>>>
>>>>        private Type(String code) {
>>>>            super(code);
>>>>        }
>>>>    }*
>>>>
>   
> I think that should read:
>   
>    public enum Type extends MyAbstractEnum<String, Type>  {
>   
> because you need the subclass type ("Type") for the in() method in MyAbstractEnum.
>
You are right.


> Best regards,
>   
> Henri
>



From forax at univ-mlv.fr  Fri Oct  7 09:16:08 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 07 Oct 2011 18:16:08 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E8F1C46.6040009@rbcdexia-is.es>
References: <4E8EE3C7.5040108@rbcdexia-is.es>
	<1317990740.20878.YahooMailNeo@web160713.mail.bf1.yahoo.com>
	<4E8EFC2B.4030607@rbcdexia-is.es>
	<1318001067.84923.YahooMailNeo@web160715.mail.bf1.yahoo.com>
	<4E8F1C46.6040009@rbcdexia-is.es>
Message-ID: <4E8F25C8.8090700@univ-mlv.fr>

I think this should work:

public interface EnumCode {
   public String getCode();
}

public class EnumCodes {
   private static final ClassValue<HashMap<String, EnumCode>> 
ENUM_CODE_MAP =
       new ClassValue<HashMap<String, EnumCode>>() {
         @Override
         protected HashMap<String, EnumCode> computeValue(Class<?> type) {
           HashMap<String, EnumCode> map = new HashMap<>();
           Object[] enumConstants=type.getEnumConstants();
           if (enumConstants == null) {
             return null;
           }
           EnumCode[] enumCodes = (EnumCode[]) enumConstants;
           for(EnumCode enumCode: enumCodes) {
             map.put(enumCode.getCode(), enumCode);
           }
           return map;
         }
       };

    public static <E extends Enum<E> & EnumCode> E getEnum(String code, 
Class<E> enumType) {
      HashMap<String, EnumCode> map = ENUM_CODE_MAP.get(enumType);
      if (map == null) {
        throw new AssertionError("not an enum code");
      }
      EnumCode enumCode = map.get(code);
      if (enumCode == null) {
        throw new IllegalArgumentException("invalid code "+code+" for 
enum type "+enumType.getName());
      }
      return enumType.cast(enumCode);
    }
}

so your enums are coded like that:

public enum EnumCodeFoo implements EnumCode {
   A("1"),
   B("456"),
   C("788999");

   private final String code;

   private EnumCodeFoo(String code) {
     this.code = code;
   }

   @Override
   public String getCode() {
     return code;
   }
}

and you can use EnumCodes like this:
   EnumCodeFoo enumCodeFoo = EnumCodes.getEnum("788999", EnumCodeFoo.class);
   System.out.println(enumCodeFoo);

basically you encode the association enum -> code in the enum and you 
use a ClassValue
and a HashMap to store the association class -> code -> enum.

cheers,
R?mi

On 10/07/2011 05:35 PM, Jose Antonio Illescas Del Olmo wrote:
> On 07/10/2011 17:24, Henri Gerrits wrote:
>> From: Jose Antonio Illescas Del Olmo<jantonio.illescas at rbcdexia-is.es>
>>> To: Henri Gerrits<henrigerrits at yahoo.com>
>>> Cc: "coin-dev at openjdk.java.net"<coin-dev at openjdk.java.net>
>>> Sent: Friday, October 7, 2011 9:18 AM
>>> Subject: Re: Please rethink extended enums inclusion
>>>
>>>
>>> On 07/10/2011 14:32, Henri Gerrits wrote:
>>> Hi Jose Antonio,
>>>>
>>>> I have some issues with your proposal:
>>>>
>>>> 1. Inserting a superclass with new methods might break many existing enums
>>> Why? I decide when extends from custom abstract enum (checking that works fine) other enums (extends from "standard" enum) and works as ever.
>>
>> I misunderstood - my mistake.
>>
>>> 2. Why do you need a code field? The name() method already returns a unique value.  The static valueOf() method can then be used instead of your fromCode() method.  I don't think caching makes much sense with enums, since the number of possible values are usually fairly small
>>>
>>> We have many communications with other finantial entities that use "standard protocols" with custom codes, while our application use descriptive enum names (on enums maps this relation between enums and codes).
>>>
>>> Our enums can parse from "standard codes" to enums and viceversa.
>>
>> OK.  I don't know the details of your application but you might want to decouple the external protocol codes from your business code.  Maybe you can add simple "translator" classes used only in your interfaces with the external entities.
>>
> The enum is my "translator",
>
>      ? On some cases/enums I persist the code on database: our "new
> application" accesss to legacy tables used by other applications, and
> persists the enum code
>
>
>>>>> /Abstract enums with Generic support reduce dramatically the code of
>>>>> enums, see next code that use abstract enums:
>>>>> /
>>>>> *public enum Type extends MyAbstractEnum<String>   {
>>>>>
>>>>>         ONE("01), TWO("03"), THREE("03"), ...;
>>>>>
>>>>>         private Type(String code) {
>>>>>             super(code);
>>>>>         }
>>>>>     }*
>>>>>
>>
>> I think that should read:
>>
>>     public enum Type extends MyAbstractEnum<String, Type>   {
>>
>> because you need the subclass type ("Type") for the in() method in MyAbstractEnum.
>>
> You are right.
>
>
>> Best regards,
>>
>> Henri
>>
>



From tball at google.com  Fri Oct  7 09:37:34 2011
From: tball at google.com (Tom Ball)
Date: Fri, 7 Oct 2011 09:37:34 -0700
Subject: New Java language alias?
Message-ID: <CAPLadK5ZYXe=a2zG4LzxniHbOE46_gQGD-UMPQM7VGABJSNuDg@mail.gmail.com>

Joe,

Would it be possible for your team to create a moderated Java language
announcements email alias?  Now that OpenJDK 7 has released the Project Coin
features, the signal-to-noise level on this list is approaching zero.  Each
time I start to unsubscribe from this list, however, you send out a useful
status update.  The OpenJDK announce alias doesn't appear to allow language
announcements, or I'd just subscribe to that.

Thanks,
Tom


From vimilsaju at yahoo.com  Fri Oct  7 09:51:20 2011
From: vimilsaju at yahoo.com (Vimil Saju)
Date: Fri, 7 Oct 2011 09:51:20 -0700 (PDT)
Subject: Why does this() and super() have to be the first statement in a
	constructor?
Message-ID: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>

If you have subclass then java requires that this() or super has to be first statement in the constructor of the subclass.?
Here is an example
?
publicclassMyClass{
? ? ? ? publicMyClass(intx){}
}

publicclassMySubClassextendsMyClass{
? ? ? ? publicMySubClass(inta,intb){
? ? ? ? ? ? ? ? intc =a +b;
? ? ? ? ? ? ? ? super(c);?// COMPILE ERROR
? ? ? ? }
}The above compilation error can be resolved by rewriting the code in the constructor as follows

publicclassMySubClassextendsMyClass{
? ? ? ? publicMySubClass(inta,intb){
? ? ? ? ? ? ? ? super(a + b);?
? ? ? ? }
}Can't the Java compiler detect that in the previous code there was no access to the instance fields or methods and therefore allow the code to compile without any error.

From jantonio.illescas at rbcdexia-is.es  Fri Oct  7 09:52:49 2011
From: jantonio.illescas at rbcdexia-is.es (Jose Antonio Illescas Del Olmo)
Date: Fri, 07 Oct 2011 18:52:49 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E8F25C8.8090700@univ-mlv.fr>
References: <4E8EE3C7.5040108@rbcdexia-is.es>	<1317990740.20878.YahooMailNeo@web160713.mail.bf1.yahoo.com>	<4E8EFC2B.4030607@rbcdexia-is.es>	<1318001067.84923.YahooMailNeo@web160715.mail.bf1.yahoo.com>	<4E8F1C46.6040009@rbcdexia-is.es>
	<4E8F25C8.8090700@univ-mlv.fr>
Message-ID: <4E8F2E61.5030803@rbcdexia-is.es>

Hello R?mi,

   This see as Tom's solution: CodeNamed (EnumCode), CodeMap (EnumCodes)


   public interface CodeNamed {
     public String code();
   }


    public enum Type implements CodeNamed {

    public static final CodeMap<Type>  CODES = new CodeMap<>(values());




On 07/10/2011 18:16, R?mi Forax wrote:
> I think this should work:
>
> public interface EnumCode {
>     public String getCode();
> }
>
> public class EnumCodes {
>     private static final ClassValue<HashMap<String, EnumCode>>
> ENUM_CODE_MAP =
>         new ClassValue<HashMap<String, EnumCode>>() {
>           @Override
>           protected HashMap<String, EnumCode>  computeValue(Class<?>  type) {
>             HashMap<String, EnumCode>  map = new HashMap<>();
>             Object[] enumConstants=type.getEnumConstants();
>             if (enumConstants == null) {
>               return null;
>             }
>             EnumCode[] enumCodes = (EnumCode[]) enumConstants;
>             for(EnumCode enumCode: enumCodes) {
>               map.put(enumCode.getCode(), enumCode);
>             }
>             return map;
>           }
>         };
>
>      public static<E extends Enum<E>  &  EnumCode>  E getEnum(String code,
> Class<E>  enumType) {
>        HashMap<String, EnumCode>  map = ENUM_CODE_MAP.get(enumType);
>        if (map == null) {
>          throw new AssertionError("not an enum code");
>        }
>        EnumCode enumCode = map.get(code);
>        if (enumCode == null) {
>          throw new IllegalArgumentException("invalid code "+code+" for
> enum type "+enumType.getName());
>        }
>        return enumType.cast(enumCode);
>      }
> }
>
> so your enums are coded like that:
>
> public enum EnumCodeFoo implements EnumCode {
>     A("1"),
>     B("456"),
>     C("788999");
>
>     private final String code;
>
>     private EnumCodeFoo(String code) {
>       this.code = code;
>     }
>
>     @Override
>     public String getCode() {
>       return code;
>     }
> }
>
> and you can use EnumCodes like this:
>     EnumCodeFoo enumCodeFoo = EnumCodes.getEnum("788999", EnumCodeFoo.class);
>     System.out.println(enumCodeFoo);
>
> basically you encode the association enum ->  code in the enum and you
> use a ClassValue
> and a HashMap to store the association class ->  code ->  enum.
>
> cheers,
> R?mi
>
> On 10/07/2011 05:35 PM, Jose Antonio Illescas Del Olmo wrote:
>> On 07/10/2011 17:24, Henri Gerrits wrote:
>>> From: Jose Antonio Illescas Del Olmo<jantonio.illescas at rbcdexia-is.es>
>>>> To: Henri Gerrits<henrigerrits at yahoo.com>
>>>> Cc: "coin-dev at openjdk.java.net"<coin-dev at openjdk.java.net>
>>>> Sent: Friday, October 7, 2011 9:18 AM
>>>> Subject: Re: Please rethink extended enums inclusion
>>>>
>>>>
>>>> On 07/10/2011 14:32, Henri Gerrits wrote:
>>>> Hi Jose Antonio,
>>>>> I have some issues with your proposal:
>>>>>
>>>>> 1. Inserting a superclass with new methods might break many existing enums
>>>> Why? I decide when extends from custom abstract enum (checking that works fine) other enums (extends from "standard" enum) and works as ever.
>>> I misunderstood - my mistake.
>>>
>>>> 2. Why do you need a code field? The name() method already returns a unique value.  The static valueOf() method can then be used instead of your fromCode() method.  I don't think caching makes much sense with enums, since the number of possible values are usually fairly small
>>>>
>>>> We have many communications with other finantial entities that use "standard protocols" with custom codes, while our application use descriptive enum names (on enums maps this relation between enums and codes).
>>>>
>>>> Our enums can parse from "standard codes" to enums and viceversa.
>>> OK.  I don't know the details of your application but you might want to decouple the external protocol codes from your business code.  Maybe you can add simple "translator" classes used only in your interfaces with the external entities.
>>>
>> The enum is my "translator",
>>
>>       ? On some cases/enums I persist the code on database: our "new
>> application" accesss to legacy tables used by other applications, and
>> persists the enum code
>>
>>
>>>>>> /Abstract enums with Generic support reduce dramatically the code of
>>>>>> enums, see next code that use abstract enums:
>>>>>> /
>>>>>> *public enum Type extends MyAbstractEnum<String>    {
>>>>>>
>>>>>>          ONE("01), TWO("03"), THREE("03"), ...;
>>>>>>
>>>>>>          private Type(String code) {
>>>>>>              super(code);
>>>>>>          }
>>>>>>      }*
>>>>>>
>>> I think that should read:
>>>
>>>      public enum Type extends MyAbstractEnum<String, Type>    {
>>>
>>> because you need the subclass type ("Type") for the in() method in MyAbstractEnum.
>>>
>> You are right.
>>
>>
>>> Best regards,
>>>
>>> Henri
>>>
>
>



From pbenedict at apache.org  Fri Oct  7 09:58:22 2011
From: pbenedict at apache.org (Paul Benedict)
Date: Fri, 7 Oct 2011 11:58:22 -0500
Subject: Why does this() and super() have to be the first statement in a
	constructor?
In-Reply-To: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>
Message-ID: <CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>

It's a compiler error because the superclass is guaranteed to be
initialized first before the subclass.

On Fri, Oct 7, 2011 at 11:51 AM, Vimil Saju <vimilsaju at yahoo.com> wrote:
> If you have subclass then java requires that this() or super has to be first statement in the constructor of the subclass.
> Here is an example
>
> publicclassMyClass{
> ? ? ? ? publicMyClass(intx){}
> }
>
> publicclassMySubClassextendsMyClass{
> ? ? ? ? publicMySubClass(inta,intb){
> ? ? ? ? ? ? ? ? intc =a +b;
> ? ? ? ? ? ? ? ? super(c);?// COMPILE ERROR
> ? ? ? ? }
> }The above compilation error can be resolved by rewriting the code in the constructor as follows
>
> publicclassMySubClassextendsMyClass{
> ? ? ? ? publicMySubClass(inta,intb){
> ? ? ? ? ? ? ? ? super(a + b);
> ? ? ? ? }
> }Can't the Java compiler detect that in the previous code there was no access to the instance fields or methods and therefore allow the code to compile without any error.
>
>


From tball at google.com  Fri Oct  7 12:07:16 2011
From: tball at google.com (Tom Ball)
Date: Fri, 7 Oct 2011 12:07:16 -0700
Subject: Why does this() and super() have to be the first statement in a
	constructor?
In-Reply-To: <CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>
	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>
Message-ID: <CAPLadK7PJ+T1QUyunfmw41h0upRDET=r1=G3P2qA+PQG8UEf4w@mail.gmail.com>

If you have an initialization problem that is difficult to resolve in a
constructor, a common solution is to have a public factory method and a
private constructor.

Tom

On Fri, Oct 7, 2011 at 9:58 AM, Paul Benedict <pbenedict at apache.org> wrote:

> It's a compiler error because the superclass is guaranteed to be
> initialized first before the subclass.
>
> On Fri, Oct 7, 2011 at 11:51 AM, Vimil Saju <vimilsaju at yahoo.com> wrote:
> > If you have subclass then java requires that this() or super has to be
> first statement in the constructor of the subclass.
> > Here is an example
> >
> > publicclassMyClass{
> >         publicMyClass(intx){}
> > }
> >
> > publicclassMySubClassextendsMyClass{
> >         publicMySubClass(inta,intb){
> >                 intc =a +b;
> >                 super(c); // COMPILE ERROR
> >         }
> > }The above compilation error can be resolved by rewriting the code in the
> constructor as follows
> >
> > publicclassMySubClassextendsMyClass{
> >         publicMySubClass(inta,intb){
> >                 super(a + b);
> >         }
> > }Can't the Java compiler detect that in the previous code there was no
> access to the instance fields or methods and therefore allow the code to
> compile without any error.
> >
> >
>
>


From daniel.yokomizo at gmail.com  Fri Oct  7 16:39:51 2011
From: daniel.yokomizo at gmail.com (Daniel Yokomizo)
Date: Fri, 7 Oct 2011 20:39:51 -0300
Subject: Why does this() and super() have to be the first statement in a
	constructor?
In-Reply-To: <CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>
	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>
Message-ID: <CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>

On Oct 7, 2011 1:58 PM, "Paul Benedict" <pbenedict at apache.org> wrote:
>
> It's a compiler error because the superclass is guaranteed to be
> initialized first before the subclass.

Not guaranteed by the JVM, as in anonymous inner classes.

> On Fri, Oct 7, 2011 at 11:51 AM, Vimil Saju <vimilsaju at yahoo.com> wrote:
> > If you have subclass then java requires that this() or super has to be
first statement in the constructor of the subclass.
> > Here is an example
> >
> > publicclassMyClass{
> >         publicMyClass(intx){}
> > }
> >
> > publicclassMySubClassextendsMyClass{
> >         publicMySubClass(inta,intb){
> >                 intc =a +b;
> >                 super(c); // COMPILE ERROR
> >         }
> > }The above compilation error can be resolved by rewriting the code in
the constructor as follows
> >
> > publicclassMySubClassextendsMyClass{
> >         publicMySubClass(inta,intb){
> >                 super(a + b);
> >         }
> > }Can't the Java compiler detect that in the previous code there was no
access to the instance fields or methods and therefore allow the code to
compile without any error.
> >
> >
>


From Ulf.Zibis at gmx.de  Sat Oct  8 04:28:52 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 08 Oct 2011 13:28:52 +0200
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>
	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>
	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
Message-ID: <4E9033F4.2080202@gmx.de>

Anyway,
     int c = a + b;
doesn't affect any object field initialization.
It's just a local variable, which gets lost after the instance is instantiated.

As workaround, you can always use a static helper method which does the same:
     super(staticHelper(a, b));

So I agree, it would reasonable, to allow some code in advance of this() or super().

+ 1 for your proposal, Vimil Saju.

-Ulf



Am 08.10.2011 01:39, schrieb Daniel Yokomizo:
> On Oct 7, 2011 1:58 PM, "Paul Benedict"<pbenedict at apache.org>  wrote:
>> It's a compiler error because the superclass is guaranteed to be
>> initialized first before the subclass.
> Not guaranteed by the JVM, as in anonymous inner classes.
>
>> On Fri, Oct 7, 2011 at 11:51 AM, Vimil Saju<vimilsaju at yahoo.com>  wrote:
>>> If you have subclass then java requires that this() or super has to be
> first statement in the constructor of the subclass.
>>> Here is an example
>>>
>>> publicclassMyClass{
>>>          publicMyClass(intx){}
>>> }
>>>
>>> publicclassMySubClassextendsMyClass{
>>>          publicMySubClass(inta,intb){
>>>                  intc =a +b;
>>>                  super(c); // COMPILE ERROR
>>>          }
>>> }The above compilation error can be resolved by rewriting the code in
> the constructor as follows
>>> publicclassMySubClassextendsMyClass{
>>>          publicMySubClass(inta,intb){
>>>                  super(a + b);
>>>          }
>>> }Can't the Java compiler detect that in the previous code there was no
> access to the instance fields or methods and therefore allow the code to
> compile without any error.
>>>
>


From t.salfischberger at celerity.nl  Sat Oct  8 05:33:52 2011
From: t.salfischberger at celerity.nl (Tomas Salfischberger)
Date: Sat, 8 Oct 2011 14:33:52 +0200
Subject: New Java language alias?
In-Reply-To: <CAPLadK5ZYXe=a2zG4LzxniHbOE46_gQGD-UMPQM7VGABJSNuDg@mail.gmail.com>
References: <CAPLadK5ZYXe=a2zG4LzxniHbOE46_gQGD-UMPQM7VGABJSNuDg@mail.gmail.com>
Message-ID: <CAGqPp2YMRjRHM_PtxBaj-dJbOe-3Gy7RsCByt6obH=RrAS2i1w@mail.gmail.com>

+1, I want to follow the announcements but tend to ignore/delete all "please
add this random feature" mails.

Tomas



On Fri, Oct 7, 2011 at 18:37, Tom Ball <tball at google.com> wrote:

> Joe,
>
> Would it be possible for your team to create a moderated Java language
> announcements email alias?  Now that OpenJDK 7 has released the Project
> Coin
> features, the signal-to-noise level on this list is approaching zero.  Each
> time I start to unsubscribe from this list, however, you send out a useful
> status update.  The OpenJDK announce alias doesn't appear to allow language
> announcements, or I'd just subscribe to that.
>
> Thanks,
> Tom
>
>


From Ulf.Zibis at gmx.de  Sat Oct  8 07:43:44 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 08 Oct 2011 16:43:44 +0200
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <CAFm6iEhH4eYW1E1YZ3a5TiF0bYthQ0G_iW-wd=kBtPw71RDFUQ@mail.gmail.com>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>
	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>
	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
	<4E9033F4.2080202@gmx.de>
	<CAFm6iEhH4eYW1E1YZ3a5TiF0bYthQ0G_iW-wd=kBtPw71RDFUQ@mail.gmail.com>
Message-ID: <4E9061A0.4050803@gmx.de>

     class A extends Base {
         A() {
             // ERROR:
             Foo foo = new Foo();
             super(foo);
             foo.special_init();

              // Workaround: (would work, if we would have method invocation chaining:
              //                    
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html)
             super(__lastFoo.set(new Foo()).get());
             __lastFoo.get().special_init();
         }
         // Need to make it thread-local to avoid concurrent access.
         private static final ThreadLocal<Foo> __lastFoo = new ThreadLocal<Foo>();
     }

-Ulf


Am 08.10.2011 14:48, schrieb BODZ, Domain:
> +1, I've also had this problem for many times. Static helper doesn't always work, see this example:
>
>     class Base {
>         /* foo is private and unreadable, no getter anyway. */
>         private final Foo  foo;
>
>        Base(Foo foo) { this.foo = foo; }
>     }
>
>     class A extends Base {
>         A() {
>             // ERROR:
>                    Foo foo = new Foo();
>                    super(foo);
>                    foo.special_init();
>
>              // Workaround:
>                    super(__lastFoo = new Foo());
>                    Foo foo = __lastFoo;
>                    foo.special_init();
>         }
>         static Foo __lastFoo;    // XXX Need to make it thread-local to avoid concurrent access.
>     }
>
> -Xie Jilei
>
>
> On Sat, Oct 8, 2011 at 7:28 PM, Ulf Zibis <Ulf.Zibis at gmx.de <mailto:Ulf.Zibis at gmx.de>> wrote:
>
>     Anyway,
>         int c = a + b;
>     doesn't affect any object field initialization.
>     It's just a local variable, which gets lost after the instance is instantiated.
>
>     As workaround, you can always use a static helper method which does the same:
>         super(staticHelper(a, b));
>
>     So I agree, it would reasonable, to allow some code in advance of this() or super().
>


From joe.darcy at oracle.com  Sat Oct  8 19:42:44 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 08 Oct 2011 19:42:44 -0700
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <4E9033F4.2080202@gmx.de>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
	<4E9033F4.2080202@gmx.de>
Message-ID: <4E910A24.1070109@oracle.com>

Ulf Zibis wrote:
> Anyway,
>      int c = a + b;
> doesn't affect any object field initialization.
> It's just a local variable, which gets lost after the instance is instantiated.
>
> As workaround, you can always use a static helper method which does the same:
>      super(staticHelper(a, b));
>
> So I agree, it would reasonable, to allow some code in advance of this() or super().
>
> + 1 for your proposal, Vimil Saju.
>   

This is not a proposal, it is a question!

The answer to the question has already been given on the list: since 
superclass state of the object is not initialized until after the 
superclass constructor is called, the Java language requires that a call 
to a superclass constructor occur in the first statement of a subclass 
constructor in an attempt to reduce logic errors in initialization.

This restriction is annoying at time, but no one has put forward a 
detailed proposal for how the requirement could be sensibility loosened 
in a way that can be standardized and tested.

-Joe

> -Ulf
>
>
>
> Am 08.10.2011 01:39, schrieb Daniel Yokomizo:
>   
>> On Oct 7, 2011 1:58 PM, "Paul Benedict"<pbenedict at apache.org>  wrote:
>>     
>>> It's a compiler error because the superclass is guaranteed to be
>>> initialized first before the subclass.
>>>       
>> Not guaranteed by the JVM, as in anonymous inner classes.
>>
>>     
>>> On Fri, Oct 7, 2011 at 11:51 AM, Vimil Saju<vimilsaju at yahoo.com>  wrote:
>>>       
>>>> If you have subclass then java requires that this() or super has to be
>>>>         
>> first statement in the constructor of the subclass.
>>     
>>>> Here is an example
>>>>
>>>> publicclassMyClass{
>>>>          publicMyClass(intx){}
>>>> }
>>>>
>>>> publicclassMySubClassextendsMyClass{
>>>>          publicMySubClass(inta,intb){
>>>>                  intc =a +b;
>>>>                  super(c); // COMPILE ERROR
>>>>          }
>>>> }The above compilation error can be resolved by rewriting the code in
>>>>         
>> the constructor as follows
>>     
>>>> publicclassMySubClassextendsMyClass{
>>>>          publicMySubClass(inta,intb){
>>>>                  super(a + b);
>>>>          }
>>>> }Can't the Java compiler detect that in the previous code there was no
>>>>         
>> access to the instance fields or methods and therefore allow the code to
>> compile without any error.
>>     
>
>   



From forax at univ-mlv.fr  Sun Oct  9 05:56:26 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sun, 09 Oct 2011 14:56:26 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E8F2E61.5030803@rbcdexia-is.es>
References: <4E8EE3C7.5040108@rbcdexia-is.es>	<1317990740.20878.YahooMailNeo@web160713.mail.bf1.yahoo.com>	<4E8EFC2B.4030607@rbcdexia-is.es>	<1318001067.84923.YahooMailNeo@web160715.mail.bf1.yahoo.com>	<4E8F1C46.6040009@rbcdexia-is.es>
	<4E8F25C8.8090700@univ-mlv.fr> <4E8F2E61.5030803@rbcdexia-is.es>
Message-ID: <4E9199FA.2030700@univ-mlv.fr>

On 10/07/2011 06:52 PM, Jose Antonio Illescas Del Olmo wrote:
> Hello R?mi,
>
>     This see as Tom's solution: CodeNamed (EnumCode), CodeMap (EnumCodes)
>
>
>     public interface CodeNamed {
>       public String code();
>     }
>
>
>      public enum Type implements CodeNamed {
>
>      public static final CodeMap<Type>   CODES = new CodeMap<>(values());

Right,
the only difference is that CODES is lazily computed in my code.

R?mi



From Ulf.Zibis at gmx.de  Sun Oct  9 06:00:32 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 09 Oct 2011 15:00:32 +0200
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <4E910A24.1070109@oracle.com>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
	<4E9033F4.2080202@gmx.de> <4E910A24.1070109@oracle.com>
Message-ID: <4E919AEF.8070602@gmx.de>

Am 09.10.2011 04:42, schrieb Joe Darcy:
> Ulf Zibis wrote:
>> Anyway,
>>      int c = a + b;
>> doesn't affect any object field initialization.
>> It's just a local variable, which gets lost after the instance is instantiated.
>>
>> As workaround, you can always use a static helper method which does the same:
>>      super(staticHelper(a, b));
>>
>> So I agree, it would reasonable, to allow some code in advance of this() or super().
>>
>> + 1 for your proposal, Vimil Saju.
>
> This is not a proposal, it is a question!
Yes, you are correct, I had implied it behind, as "question" seemed too innocent to me.
Please apologize my ease, not having referred a dictionary. English is not my mother tongue.
Now I did, and assume, "challenge" would have been the best wording.

>
> The answer to the question has already been given on the list:
But it is improper, because Vimil's example doesn't affect the guarantee , the superclass to be
initialized first before the subclass.

> ... in an attempt to reduce logic errors in initialization.
This is fine, but on one hand, the standard is too strict, and in prominent corner cases, e.g. inner 
classes, the guarantee is violated, but could be too "repaired":
Bug 7091048 <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7091048> - Compiler should detect 
race conditions on final fields

>
> This restriction is annoying at time, but no one has put forward a detailed proposal for how the 
> requirement could be sensibility loosened in a way that can be standardized and tested.
I allege, the test is already there: If a member variable or method is referred as parameter of 
super() or this(), the compiler reports an error. So I imply, there already exists a suitable 
standard to fulfil the asked requirement.

-Ulf


>
> -Joe
>
>> -Ulf
>>
>>
>>
>> Am 08.10.2011 01:39, schrieb Daniel Yokomizo:
>>> On Oct 7, 2011 1:58 PM, "Paul Benedict"<pbenedict at apache.org>  wrote:
>>>> It's a compiler error because the superclass is guaranteed to be
>>>> initialized first before the subclass.
>>> Not guaranteed by the JVM, as in anonymous inner classes.
>>>
>>>> On Fri, Oct 7, 2011 at 11:51 AM, Vimil Saju<vimilsaju at yahoo.com>  wrote:
>>>>> If you have subclass then java requires that this() or super has to be
>>> first statement in the constructor of the subclass.
>>>>> Here is an example
>>>>>
>>>>> publicclassMyClass{
>>>>>          publicMyClass(intx){}
>>>>> }
>>>>>
>>>>> publicclassMySubClassextendsMyClass{
>>>>>          publicMySubClass(inta,intb){
>>>>>                  intc =a +b;
>>>>>                  super(c); // COMPILE ERROR
>>>>>          }
>>>>> }The above compilation error can be resolved by rewriting the code in
>>> the constructor as follows
>>>>> publicclassMySubClassextendsMyClass{
>>>>>          publicMySubClass(inta,intb){
>>>>>                  super(a + b);
>>>>>          }
>>>>> }Can't the Java compiler detect that in the previous code there was no
>>> access to the instance fields or methods and therefore allow the code to
>>> compile without any error.
>>
>
>


From jantonio.illescas at rbcdexia-is.es  Mon Oct 10 01:55:46 2011
From: jantonio.illescas at rbcdexia-is.es (Jose Antonio Illescas Del Olmo)
Date: Mon, 10 Oct 2011 10:55:46 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E9199FA.2030700@univ-mlv.fr>
References: <4E8EE3C7.5040108@rbcdexia-is.es>	<1317990740.20878.YahooMailNeo@web160713.mail.bf1.yahoo.com>	<4E8EFC2B.4030607@rbcdexia-is.es>	<1318001067.84923.YahooMailNeo@web160715.mail.bf1.yahoo.com>	<4E8F1C46.6040009@rbcdexia-is.es>	<4E8F25C8.8090700@univ-mlv.fr>
	<4E8F2E61.5030803@rbcdexia-is.es> <4E9199FA.2030700@univ-mlv.fr>
Message-ID: <4E92B312.2050003@rbcdexia-is.es>

Let me explain a real case: my current project (120.00 lines of code) 
with many enums (350 enums)

An abstract enum can reduce aprox. 10 lines of code: internal field 
"code", getter/setter of "code", static attribute "CODES", utility 
methods as "in"....

     350 enums x 10 lines of code = 3500 removed lines (it's an 
important reduction)


I think that abstract enums can help us (all java developer) to reduce 
dramatically our lines of code...


From jantonio.illescas at rbcdexia-is.es  Mon Oct 10 02:08:31 2011
From: jantonio.illescas at rbcdexia-is.es (Jose Antonio Illescas Del Olmo)
Date: Mon, 10 Oct 2011 11:08:31 +0200
Subject: Please rethink extended enums inclusion
In-Reply-To: <4E92B312.2050003@rbcdexia-is.es>
References: <4E8EE3C7.5040108@rbcdexia-is.es>	<1317990740.20878.YahooMailNeo@web160713.mail.bf1.yahoo.com>	<4E8EFC2B.4030607@rbcdexia-is.es>	<1318001067.84923.YahooMailNeo@web160715.mail.bf1.yahoo.com>	<4E8F1C46.6040009@rbcdexia-is.es>	<4E8F25C8.8090700@univ-mlv.fr>	<4E8F2E61.5030803@rbcdexia-is.es>
	<4E9199FA.2030700@univ-mlv.fr> <4E92B312.2050003@rbcdexia-is.es>
Message-ID: <4E92B60F.5080805@rbcdexia-is.es>

A mistake, my proyect contains 120000 lines of code

On 10/10/2011 10:55, Jose Antonio Illescas Del Olmo wrote:
> Let me explain a real case: my current project (120.00 lines of code)
> with many enums (350 enums)
>
> An abstract enum can reduce aprox. 10 lines of code: internal field
> "code", getter/setter of "code", static attribute "CODES", utility
> methods as "in"....
>
>       350 enums x 10 lines of code = 3500 removed lines (it's an
> important reduction)
>
>
> I think that abstract enums can help us (all java developer) to reduce
> dramatically our lines of code...
>
>



From tball at google.com  Mon Oct 10 09:36:56 2011
From: tball at google.com (Tom Ball)
Date: Mon, 10 Oct 2011 09:36:56 -0700
Subject: Why does this() and super() have to be the first statement in a
	constructor?
In-Reply-To: <4E910A24.1070109@oracle.com>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>
	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>
	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
	<4E9033F4.2080202@gmx.de> <4E910A24.1070109@oracle.com>
Message-ID: <CAPLadK4U6OA1QRnweKkCkbWZK4PyKx6fW=q=dxfkPEhYN7mOwA@mail.gmail.com>

>
> This restriction is annoying at time, but no one has put forward a
> detailed proposal for how the requirement could be sensibility loosened
> in a way that can be standardized and tested.


Josh Bloch did in Effective Java: "prefer factory methods to constructors."
 You'd be amazed at what I get away with in my factory methods. :-)

Tom

On Sat, Oct 8, 2011 at 7:42 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> Ulf Zibis wrote:
> > Anyway,
> >      int c = a + b;
> > doesn't affect any object field initialization.
> > It's just a local variable, which gets lost after the instance is
> instantiated.
> >
> > As workaround, you can always use a static helper method which does the
> same:
> >      super(staticHelper(a, b));
> >
> > So I agree, it would reasonable, to allow some code in advance of this()
> or super().
> >
> > + 1 for your proposal, Vimil Saju.
> >
>
> This is not a proposal, it is a question!
>
> The answer to the question has already been given on the list: since
> superclass state of the object is not initialized until after the
> superclass constructor is called, the Java language requires that a call
> to a superclass constructor occur in the first statement of a subclass
> constructor in an attempt to reduce logic errors in initialization.
>
> This restriction is annoying at time, but no one has put forward a
> detailed proposal for how the requirement could be sensibility loosened
> in a way that can be standardized and tested.
>
> -Joe
>
> > -Ulf
> >
> >
> >
> > Am 08.10.2011 01:39, schrieb Daniel Yokomizo:
> >
> >> On Oct 7, 2011 1:58 PM, "Paul Benedict"<pbenedict at apache.org>  wrote:
> >>
> >>> It's a compiler error because the superclass is guaranteed to be
> >>> initialized first before the subclass.
> >>>
> >> Not guaranteed by the JVM, as in anonymous inner classes.
> >>
> >>
> >>> On Fri, Oct 7, 2011 at 11:51 AM, Vimil Saju<vimilsaju at yahoo.com>
>  wrote:
> >>>
> >>>> If you have subclass then java requires that this() or super has to be
> >>>>
> >> first statement in the constructor of the subclass.
> >>
> >>>> Here is an example
> >>>>
> >>>> publicclassMyClass{
> >>>>          publicMyClass(intx){}
> >>>> }
> >>>>
> >>>> publicclassMySubClassextendsMyClass{
> >>>>          publicMySubClass(inta,intb){
> >>>>                  intc =a +b;
> >>>>                  super(c); // COMPILE ERROR
> >>>>          }
> >>>> }The above compilation error can be resolved by rewriting the code in
> >>>>
> >> the constructor as follows
> >>
> >>>> publicclassMySubClassextendsMyClass{
> >>>>          publicMySubClass(inta,intb){
> >>>>                  super(a + b);
> >>>>          }
> >>>> }Can't the Java compiler detect that in the previous code there was no
> >>>>
> >> access to the instance fields or methods and therefore allow the code to
> >> compile without any error.
> >>
> >
> >
>
>
>


From alex at puredanger.com  Fri Oct  7 10:50:26 2011
From: alex at puredanger.com (Alex Miller)
Date: Fri, 7 Oct 2011 12:50:26 -0500
Subject: Please rethink extended enums inclusion
Message-ID: <CAOdgdgxbRnSnTTJcV47cKhUyMnfgsfN=3DdS8r-ceUcGjq_Ttg@mail.gmail.com>

On Fri, Oct 7, 2011, Jose Antonio Illescas Del Olmo
<jantonio.illescas at rbcdexia-is.es> wrote:
> Now we have hundred of enums on our project (finantial application with
> 120.000 lines) an repeat same code on any enum... (*mark as red*)

I would second that I think having abstract enums would be useful.
One use case I ran into and blogged about long ago is here if you're
interested:

http://tech.puredanger.com/2008/01/10/property-enum/

Alex Miller


From lenik at bodz.net  Sat Oct  8 05:55:33 2011
From: lenik at bodz.net (Lenik)
Date: Sat, 08 Oct 2011 20:55:33 +0800
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <4E9033F4.2080202@gmx.de>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
	<4E9033F4.2080202@gmx.de>
Message-ID: <4E904845.6030509@bodz.net>

+1, I've also had this problem for many times. Static helper doesn't 
always work, see this example:

     class Base {
         /* foo is private and unreadable, no getter anyway. */
         private final Foo  foo;

        Base(Foo foo) { this.foo = foo; }
     }

     class A extends Base {
         A() {
             // ERROR:
                    Foo foo = new Foo();
                    super(foo);
                    foo.special_init();

              // Workaround:
                    super(__lastFoo = new Foo());
                    Foo foo = __lastFoo;
                    foo.special_init();
         }
         static Foo __lastFoo;    // XXX Need to make it thread-local to 
avoid concurrent access.
     }

-Xie Jilei


On 10/08/2011 07:28 PM, Ulf Zibis wrote:
> Anyway,
>       int c = a + b;
> doesn't affect any object field initialization.
> It's just a local variable, which gets lost after the instance is instantiated.
>
> As workaround, you can always use a static helper method which does the same:
>       super(staticHelper(a, b));
>
> So I agree, it would reasonable, to allow some code in advance of this() or super().
>
> + 1 for your proposal, Vimil Saju.
>
> -Ulf
>
>
>
> Am 08.10.2011 01:39, schrieb Daniel Yokomizo:
>> On Oct 7, 2011 1:58 PM, "Paul Benedict"<pbenedict at apache.org>   wrote:
>>> It's a compiler error because the superclass is guaranteed to be
>>> initialized first before the subclass.
>> Not guaranteed by the JVM, as in anonymous inner classes.
>>
>>> On Fri, Oct 7, 2011 at 11:51 AM, Vimil Saju<vimilsaju at yahoo.com>   wrote:
>>>> If you have subclass then java requires that this() or super has to be
>> first statement in the constructor of the subclass.
>>>> Here is an example
>>>>
>>>> publicclassMyClass{
>>>>           publicMyClass(intx){}
>>>> }
>>>>
>>>> publicclassMySubClassextendsMyClass{
>>>>           publicMySubClass(inta,intb){
>>>>                   intc =a +b;
>>>>                   super(c); // COMPILE ERROR
>>>>           }
>>>> }The above compilation error can be resolved by rewriting the code in
>> the constructor as follows
>>>> publicclassMySubClassextendsMyClass{
>>>>           publicMySubClass(inta,intb){
>>>>                   super(a + b);
>>>>           }
>>>> }Can't the Java compiler detect that in the previous code there was no
>> access to the instance fields or methods and therefore allow the code to
>> compile without any error.



From per at bothner.com  Mon Oct 10 17:54:29 2011
From: per at bothner.com (Per Bothner)
Date: Mon, 10 Oct 2011 17:54:29 -0700
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <4E904845.6030509@bodz.net>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
	<4E9033F4.2080202@gmx.de> <4E904845.6030509@bodz.net>
Message-ID: <4E9393C5.8030002@bothner.com>

On 10/08/2011 05:55 AM, Lenik wrote:
> +1, I've also had this problem for many times. Static helper doesn't
> always work, see this example:
>
>       class Base {
>           /* foo is private and unreadable, no getter anyway. */
>           private final Foo  foo;
>
>          Base(Foo foo) { this.foo = foo; }
>       }
>
>       class A extends Base {
>           A() {
>               // ERROR:
>                      Foo foo = new Foo();
>                      super(foo);
>                      foo.special_init();
>
>                // Workaround:
>                      super(__lastFoo = new Foo());
>                      Foo foo = __lastFoo;
>                      foo.special_init();
>           }
>           static Foo __lastFoo;    // XXX Need to make it thread-local to
> avoid concurrent access.
>       }

What is wrong with:

     class A extends Base {
          A() { this(new Foo); }
          private A(Foo foo) {
              super(foo);
              foo.special_init();
          }
     }

or:

     class A extends Base {
          A() { super(specialFoo()); }
          private static Foo specialFoo() {
              Foo foo = new Foo;
              foo.special_init();
              return foo; }
         }
     }
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/


From Ulf.Zibis at gmx.de  Tue Oct 11 02:28:42 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 11 Oct 2011 11:28:42 +0200
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <4E9393C5.8030002@bothner.com>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
	<4E9033F4.2080202@gmx.de> <4E904845.6030509@bodz.net>
	<4E9393C5.8030002@bothner.com>
Message-ID: <4E940C4A.5040002@gmx.de>

Am 11.10.2011 02:54, schrieb Per Bothner:
> On 10/08/2011 05:55 AM, Lenik wrote:
>> +1, I've also had this problem for many times. Static helper doesn't
>> always work, see this example:
>>
>>        class Base {
>>            /* foo is private and unreadable, no getter anyway. */
>>            private final Foo  foo;
>>
>>           Base(Foo foo) { this.foo = foo; }
>>        }
>>
>>        class A extends Base {
>>            A() {
>>                // ERROR:
>>                       Foo foo = new Foo();
>>                       super(foo);
>>                       foo.special_init();
>>
>>                 // Workaround:
>>                       super(__lastFoo = new Foo());
>>                       Foo foo = __lastFoo;
>>                       foo.special_init();
>>            }
>>            static Foo __lastFoo;    // XXX Need to make it thread-local to
>> avoid concurrent access.
>>        }
> What is wrong with:
>
>       class A extends Base {
>            A() { this(new Foo); }
>            private A(Foo foo) {
>                super(foo);
>                foo.special_init();
>            }
>       }
Seems great, did it compile?

> or:
>
>       class A extends Base {
>            A() { super(specialFoo()); }
>            private static Foo specialFoo() {
>                Foo foo = new Foo;
>                foo.special_init();
>                return foo; }
>           }
>       }
In the original example, super(foo) is executed *before* foo.special_init(), so in most cases this 
workaround would have different result, i.e. is not compatible.

-Ulf



From Ulf.Zibis at gmx.de  Tue Oct 11 02:45:59 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 11 Oct 2011 11:45:59 +0200
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <4E9393C5.8030002@bothner.com>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
	<4E9033F4.2080202@gmx.de> <4E904845.6030509@bodz.net>
	<4E9393C5.8030002@bothner.com>
Message-ID: <4E941057.3090502@gmx.de>

Am 11.10.2011 02:54, schrieb Per Bothner:
> .....
> or:
>
>       class A extends Base {
>            A() { super(specialFoo()); }
>            private static Foo specialFoo() {
>                Foo foo = new Foo;
>                foo.special_init();
>                return foo; }
>           }
>       }
BTW: this is the same as:
(If special_init() would return foo itself, of if we would have method invocation chaining: ...
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html))

      class A extends Base {
           A() { super((new foo()).special_init()); }
      }




From per at bothner.com  Tue Oct 11 09:18:49 2011
From: per at bothner.com (Per Bothner)
Date: Tue, 11 Oct 2011 09:18:49 -0700
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <4E940C4A.5040002@gmx.de>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
	<4E9033F4.2080202@gmx.de> <4E904845.6030509@bodz.net>
	<4E9393C5.8030002@bothner.com> <4E940C4A.5040002@gmx.de>
Message-ID: <4E946C69.5050508@bothner.com>

On 10/11/2011 02:28 AM, Ulf Zibis wrote:
>> What is wrong with:
>>
>> class A extends Base {
>> A() { this(new Foo); }
>> private A(Foo foo) {
>> super(foo);
>> foo.special_init();
>> }
>> }
> Seems great, did it compile?

I didn't have to - I've used this idiom numerous times.

But just to be sure: I did compile it.  I had to fix one typo:
Missing parens after 'new Foo'.

>> or:
>>
>> class A extends Base {
>> A() { super(specialFoo()); }
>> private static Foo specialFoo() {
>> Foo foo = new Foo;
>> foo.special_init();
>> return foo; }
>> }
>> }
> In the original example, super(foo) is executed *before*
> foo.special_init(), so in most cases this workaround would have
> different result, i.e. is not compatible.

Of course, but it would be pretty rare (and ugly) for super(foo) to
have the kind of side-effects where the order would matter.

But I agree it is mot a general replacement.
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/


From Ulf.Zibis at gmx.de  Tue Oct 11 09:57:15 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 11 Oct 2011 18:57:15 +0200
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <4E946C69.5050508@bothner.com>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
	<4E9033F4.2080202@gmx.de> <4E904845.6030509@bodz.net>
	<4E9393C5.8030002@bothner.com> <4E940C4A.5040002@gmx.de>
	<4E946C69.5050508@bothner.com>
Message-ID: <4E94756B.9000108@gmx.de>

Am 11.10.2011 18:18, schrieb Per Bothner:
> On 10/11/2011 02:28 AM, Ulf Zibis wrote: In the original example, super(foo) is executed *before*
>> foo.special_init(), so in most cases this workaround would have
>> different result, i.e. is not compatible.
>
> Of course, but it would be pretty rare (and ugly) for super(foo) to
> have the kind of side-effects where the order would matter.
Maybe that was the reason, why it was called "special_init" ;-)

-Ulf



From mike.duigou at oracle.com  Tue Oct 11 13:03:49 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 11 Oct 2011 13:03:49 -0700
Subject: Why does this() and super() have to be the first statement in	 a
	constructor?
In-Reply-To: <mailman.40.1318359602.25430.coin-dev@openjdk.java.net>
References: <mailman.40.1318359602.25430.coin-dev@openjdk.java.net>
Message-ID: <0DC8E0EB-27F3-4DCA-9ED0-8ED60189903D@oracle.com>

I submitted a proposal for exactly this request as part of the original coin call for proposals. 

http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000798.html

(long thread follows)

The request also resulted in the identification of several older requests:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4093999
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4879515
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4107474

The first issue (4093999) points out that the JVMS specification only requires that super() or this() be called before instance members (including "this") are accessed. The restriction that super() or this() must be the first statement of a constructor is a tighter restriction imposed by the Java language. 

The proposal was ultimately not selected for project coin:

http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000817.html

Note that the resolution in leaves open the opportunity (*not* commitment) for it to be addressed in future coin efforts or at any time by an enterprising compiler hacker. 

I do still think the restriction is an annoyance :-)

Mike



From Ulf.Zibis at gmx.de  Tue Oct 11 13:56:16 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 11 Oct 2011 22:56:16 +0200
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <0DC8E0EB-27F3-4DCA-9ED0-8ED60189903D@oracle.com>
References: <mailman.40.1318359602.25430.coin-dev@openjdk.java.net>
	<0DC8E0EB-27F3-4DCA-9ED0-8ED60189903D@oracle.com>
Message-ID: <4E94AD70.5080109@gmx.de>

Am 11.10.2011 22:03, schrieb Mike Duigou:
> I submitted a proposal for exactly this request as part of the original coin call for proposals.
>
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000798.html
>
> (long thread follows)

Much thanks Mike!

Unfortunately I missed this, as I inscribed to coin list on March 30 2009.

Most work for defining a standard seems to be done already.

So my answer to the initial question now is:

This restriction is a historical convenience to make the implementation of the java compiler less 
complicated, simplify the java language spec, and perhaps to avoid the additional discussion in 
"Learning Java" books ;-) , but there is no technical reasonable for this.

-Ulf



From joe.darcy at oracle.com  Tue Oct 11 18:24:43 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 11 Oct 2011 18:24:43 -0700
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <4E94AD70.5080109@gmx.de>
References: <mailman.40.1318359602.25430.coin-dev@openjdk.java.net>	<0DC8E0EB-27F3-4DCA-9ED0-8ED60189903D@oracle.com>
	<4E94AD70.5080109@gmx.de>
Message-ID: <4E94EC5B.4030906@oracle.com>

On 10/11/2011 1:56 PM, Ulf Zibis wrote:
> Am 11.10.2011 22:03, schrieb Mike Duigou:
>   
>> I submitted a proposal for exactly this request as part of the original coin call for proposals.
>>
>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000798.html
>>
>> (long thread follows)
>>     
>
> Much thanks Mike!
>
> Unfortunately I missed this, as I inscribed to coin list on March 30 2009.
>
> Most work for defining a standard seems to be done already.
>   

No.

As pointed out in the thread cited by Mike, there were technical issues 
discussed in various related bugs, in particular

    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4093999

and from feedback from Jeremy Manson on the thread:

> Here are a couple of constructors for class Foo that should probably 
> result
> in compilation errors:
>
>   Foo() {
>     if (something) {
>       super(blah)
>     }
>   }
>   Foo() {
>     super(blah);
>     super(blah);
>   }
>
> Also, it seems to me that you would want to be careful about access to
> fields of the parent object before the invocation of super().
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000805.html

> So my answer to the initial question now is:
>
> This restriction is a historical convenience to make the implementation of the java compiler less 
> complicated, simplify the java language spec, and perhaps to avoid the additional discussion in 
> "Learning Java" books ;-) , but there is no technical reasonable for this.
>
>
>   

Until and unless data flow analysis akin to definite 
assignment/unassignment is defined to permit the sort of desirable 
programs the proposal wants to allow, the main piece of technical work 
needed to implement this request has not been done.

IMO this loosening would be fine in and of itself, but it has too high 
an opportunity cost compared to other language changes that could be 
done with the same amount of effort.

-Joe


From Ulf.Zibis at gmx.de  Thu Oct 13 04:53:19 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 13 Oct 2011 13:53:19 +0200
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <4E94EC5B.4030906@oracle.com>
References: <mailman.40.1318359602.25430.coin-dev@openjdk.java.net>	<0DC8E0EB-27F3-4DCA-9ED0-8ED60189903D@oracle.com>
	<4E94AD70.5080109@gmx.de> <4E94EC5B.4030906@oracle.com>
Message-ID: <4E96D12F.4050101@gmx.de>

Joe,

now I'm a little bit confused.

First you refer simply:
"The answer to the question has already been given on the list. ..."
Now you point to Bug 4093999 with IMHO very sophisticated loosening cases, e.g.: obj.super().

I think, as first step, this request could be handled like as on switch enhancements (only for 
String, but not for all objects or arbitrary expressions).

Following loosening rules seem simple, clear and enough to me:
1. Allow the explicit call to super() or this() only before any reference to this or instance fields 
or methods.
2. In case where no explicit call to super/this() is given, add implicit call to the no params 
super() as 1. statement.
3. Allow super() or this() call only outside any block ({...}, if, for, etc.), maybe except 
synchronize block.
4. Allow only one of super() or this() and only once.

Further loosenings could be discussed later, as they need complicated data flow analysis.

I agree, that other language changes might have higher priority.

-Ulf


Am 12.10.2011 03:24, schrieb joe.darcy at oracle.com:
>
> As pointed out in the thread cited by Mike, there were technical issues discussed in various 
> related bugs, in particular
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4093999

>
> IMO this loosening would be fine in and of itself, but it has too high an opportunity cost 
> compared to other language changes that could be done with the same amount of effort.
>
> -Joe


From henrigerrits at yahoo.com  Thu Oct 13 06:16:08 2011
From: henrigerrits at yahoo.com (Henri Gerrits)
Date: Thu, 13 Oct 2011 06:16:08 -0700 (PDT)
Subject: Why does this() and super() have to be the first statement in a
	constructor?
In-Reply-To: <4E96D12F.4050101@gmx.de>
References: <mailman.40.1318359602.25430.coin-dev@openjdk.java.net>
	<0DC8E0EB-27F3-4DCA-9ED0-8ED60189903D@oracle.com>
	<4E94AD70.5080109@gmx.de> <4E94EC5B.4030906@oracle.com>
	<4E96D12F.4050101@gmx.de>
Message-ID: <1318511768.53622.YahooMailNeo@web160701.mail.bf1.yahoo.com>

Ulf,

In?rule 1, using a field access as the left-hand operand in a simple (not compound, of course) assignment could be allowed before an explicit?call to this() or super().
In rule 2, by "1." I assume you mean "first"?

Regards,

Henri

----- Original Message -----
> From: Ulf Zibis <Ulf.Zibis at gmx.de>
> To: joe.darcy at oracle.com
> Cc: coin-dev at openjdk.java.net; Mike Duigou <mike.duigou at oracle.com>
> Sent: Thursday, October 13, 2011 7:53 AM
> Subject: Re: Why does this() and super() have to be the first statement in a constructor?
> 
> Joe,
> 
> now I'm a little bit confused.
> 
> First you refer simply:
> "The answer to the question has already been given on the list. ..."
> Now you point to Bug 4093999 with IMHO very sophisticated loosening cases, e.g.: 
> obj.super().
> 
> I think, as first step, this request could be handled like as on switch 
> enhancements (only for 
> String, but not for all objects or arbitrary expressions).
> 
> Following loosening rules seem simple, clear and enough to me:
> 1. Allow the explicit call to super() or this() only before any reference to 
> this or instance fields 
> or methods.
> 2. In case where no explicit call to super/this() is given, add implicit call to 
> the no params 
> super() as 1. statement.
> 3. Allow super() or this() call only outside any block ({...}, if, for, etc.), 
> maybe except 
> synchronize block.
> 4. Allow only one of super() or this() and only once.
> 
> Further loosenings could be discussed later, as they need complicated data flow 
> analysis.
> 
> I agree, that other language changes might have higher priority.
> 
> -Ulf
> 
> 
> Am 12.10.2011 03:24, schrieb joe.darcy at oracle.com:
>> 
>> As pointed out in the thread cited by Mike, there were technical issues 
> discussed in various 
>> related bugs, in particular
>> 
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4093999
> 
>> 
>> IMO this loosening would be fine in and of itself, but it has too high an 
> opportunity cost 
>> compared to other language changes that could be done with the same amount 
> of effort.
>> 
>> -Joe
>


From Ulf.Zibis at gmx.de  Thu Oct 13 06:50:47 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 13 Oct 2011 15:50:47 +0200
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <1318511768.53622.YahooMailNeo@web160701.mail.bf1.yahoo.com>
References: <mailman.40.1318359602.25430.coin-dev@openjdk.java.net>
	<0DC8E0EB-27F3-4DCA-9ED0-8ED60189903D@oracle.com>
	<4E94AD70.5080109@gmx.de> <4E94EC5B.4030906@oracle.com>
	<4E96D12F.4050101@gmx.de>
	<1318511768.53622.YahooMailNeo@web160701.mail.bf1.yahoo.com>
Message-ID: <4E96ECB7.2090308@gmx.de>

Am 13.10.2011 15:16, schrieb Henri Gerrits:
> Ulf,
>
> In rule 1, using a field access as the left-hand operand in a simple (not compound, of course) assignment could be allowed before an explicit call to this() or super().
May be, but should be waived to future, to simplify the 1st loosening step.
Workaround: First assign to temporal local variable, and after this/super() to instance field. 
Hotspot would anyway optimize this.

> In rule 2, by "1." I assume you mean "first"?
Correct! "1." is german notation for "1st". ;-)

-Ulf


>
> Regards,
>
> Henri
>
> ----- Original Message -----
>> From: Ulf Zibis<Ulf.Zibis at gmx.de>
>> To: joe.darcy at oracle.com
>> Cc: coin-dev at openjdk.java.net; Mike Duigou<mike.duigou at oracle.com>
>> Sent: Thursday, October 13, 2011 7:53 AM
>> Subject: Re: Why does this() and super() have to be the first statement in a constructor?
>>
>> Joe,
>>
>> now I'm a little bit confused.
>>
>> First you refer simply:
>> "The answer to the question has already been given on the list. ..."
>> Now you point to Bug 4093999 with IMHO very sophisticated loosening cases, e.g.:
>> obj.super().
>>
>> I think, as first step, this request could be handled like as on switch
>> enhancements (only for
>> String, but not for all objects or arbitrary expressions).
>>
>> Following loosening rules seem simple, clear and enough to me:
>> 1. Allow the explicit call to super() or this() only before any reference to
>> this or instance fields
>> or methods.
>> 2. In case where no explicit call to super/this() is given, add implicit call to
>> the no params
>> super() as 1. statement.
>> 3. Allow super() or this() call only outside any block ({...}, if, for, etc.),
>> maybe except
>> synchronize block.
>> 4. Allow only one of super() or this() and only once.
>>
>> Further loosenings could be discussed later, as they need complicated data flow
>> analysis.
>>
>> I agree, that other language changes might have higher priority.
>>
>> -Ulf
>>


From isidore at setgame.com  Thu Oct 13 12:01:44 2011
From: isidore at setgame.com (Llewellyn Falco)
Date: Thu, 13 Oct 2011 12:01:44 -0700
Subject: JDK 8 and properties
In-Reply-To: <CACzrW9Dx4t4gUoTM1Xuku08c3ue42RHG673h=WH4D4UJRTmprw@mail.gmail.com>
References: <CAJSAXGm_1ELBTdU0iRJAk9B7BLB-zeLmw_qP2kHDik-HE52VXg@mail.gmail.com>
	<4E8C770A.3000206@optrak.com>
	<CAJSAXGnT949vc4c7Kum4g6CLE0dJcbmcO9XXqxidZzQ6Gz=KNg@mail.gmail.com>
	<CABLGb9x6700smZcjzBr+NnjUyeHZuwGC01q4iR0Sh-FEVZvgfw@mail.gmail.com>
	<CALKB1SV-32KrCJSogiZjUqm5PcQqjabozS541+_tKEkhkH80ow@mail.gmail.com>
	<CAJSAXGnAkA59yvsJ-XRpoMF2itFiY2zAnBdSrMqMmKHguwYzUg@mail.gmail.com>
	<4E8D6459.4000506@paradise.net.nz>
	<CACzrW9Dx4t4gUoTM1Xuku08c3ue42RHG673h=WH4D4UJRTmprw@mail.gmail.com>
Message-ID: <CAD_OyrHx0NxVR+v1R9zAnF4ZuvE3f2X6VZhvL6mwnvQ8kDuDdw@mail.gmail.com>

> Simply generating the getter, setter, equals and hashcode is only part
> of the problem. There also need to be a way to enumerate/loop over the
> properties. Without this, each framework will continue to write their
> own "bean introspector".

I use C# for about 1/2 of my development time.
As such I have a lot of experience with properties.
And I wanted to quickly disspel the idea that properties remove getters&setters
they do not.
You will still get many situations where a getter and setter is
preferred or required.
especially when a Conversion is in play, such as
setLengthInMeters(meters)
or
getAverage(includeExtraCredit, includeTransfers)

In general, I am not a Fan of properties, although I am VERY
supportive of a syntax like lombok to reduce the clutter and
boilerplate.

because the Properties split up and then you have to deal with the
getters/setters anyways. you will always need a bean introspector.
probably somethings like
getMethods().where(m->m.getName().startsWith("get")



-- 
Llewellyn Falco
www.approvaltests.com
www.teachingkidsprogramming.org


From howard.lovatt at gmail.com  Sun Oct 16 16:41:54 2011
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Mon, 17 Oct 2011 10:41:54 +1100
Subject: Why does this() and super() have to be the first statement in a
	constructor?
In-Reply-To: <4E910A24.1070109@oracle.com>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>
	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>
	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
	<4E9033F4.2080202@gmx.de> <4E910A24.1070109@oracle.com>
Message-ID: <CACR_FB4cNsRYpM3H2VJCdV7aO_p=RJ+7nQqdH3Xv3Ci9raXX7w@mail.gmail.com>

I proposed this a long while ago, see email chain below. My particular
requirement was wanting a field initialised so that the super constructor
could call an instance method defined in the derived class. The example I
gave in the email below was contrived to keep it short. The actual use case
was very similar to an inner class (therefore easy to see why you would want
this because inner clas do this already).

My proposal was to allow read and write of a class's own fields (not those
in super) and local variables before super/this was called.

Would the above description be a sufficiently detailed request to start
working on a formal proposal? Is this something that is likely to get
support if a formal proposal was submitted?

Cheers,

 -- Howard.

=================================================================

fromIncidentDaemon at sun.com IncidentDaemon at sun.comtohoward.lovatt@iee.org
date23 February 2006 21:37subjectYour Report (Review ID: 654094) - Alow
field inizialization before super call in constructors
hide details 23/02/2006
************************************************
Your report has been assigned an internal review ID of: 654094

This review ID is NOT visible on on Sun Developer Network (SDN).

We greatly appreciate your interest in improving the quality of Java(tm)
Technology from Sun Microsystems.

Please be aware that the large volume of reports we receive sometimes
prevents us from responding individually to each message.

We currently have a three week average response time.  If the information is
determined to be a new bug, or a duplicate of a known bug, you will receive
a followup email containing a seven digit bug number.  You may search for,
view, or vote for this bug on the Bug Database at http://bugs.sun.com/

.

If you just reported an issue that could have a major impact on your project
and you require a timely response, please consider purchasing one of the
support offerings at http://java.sun.com/support/index.html

.

The Sun Developer Network (http://developers.sun.com

) is a free service that Sun offers.  To join, visit
http://developers.sun.com/global/join_sdn.html

.

For a limited time, SDN members can obtain fully licensed Java IDEs for web
and enterprise development.  More information is at
http://developers.sun.com/prodtech/javatools/free/

.

Thank you for your help.



---------------------------------------------------------------


dateCreated: Thu Feb 23 03:37:04 MST 2006
type:        rfe
cust_name:   Howard Lovatt
cust_email:  howard.lovatt at iee.org
jdcid:       hlovatt
status:      Waiting
category:    java
subcategory: specification
company:     Personal submission
release:     5.0
hardware:    x86
OSversion:   win_xp
priority:    4
synopsis:    Alow field inizialization before super call in constructors
description: A DESCRIPTION OF THE REQUEST :
At present some code cannot be written using Java source code you need to
manipulate the bytecode. In particular the Java language requires that super be
the first line of a constructor. However there are times when you need to
initialize a field from arguments supplied to the constructor before calling
the constructor. So that the super constructor can call virtual methods
defined in the base class and not get errors (e.g. NullPointerException).
EG:

class Base {
   Base() { System.out.println( get_int() ); }
   abstract int get_int();
}

public class Derived extends Base {
   Integer value;
   Derived ( int value ) { this.value = value; } // NB Autoboxed
   int get_int() { return value; } // NB unboxed automatically

   public static void main( String[] notUsed ) { new Derived( 1 ); } //
NullPointerException!
}

The above code throws a null pointer because you can't initialize field
value before calling super (implicitly) in Derived's constructor.

The suggested solution is to allow super to appear after the initialization,
e.g. allow:

Derived( int value ) {
   this.value = value;
   super()
}

If super isn't explicityly mentioned then, as at present, it is assumed to
be the first line.

JUSTIFICATION :
There are plenty of examples were initializing fields is needed.

EG1 you can't manually write the equivalent of an inner class because the
field that points to the outer class needs to be initialized before the call
to super.

EG2 this problem has been recognized for C# and an MS proposed language
extension called SPEC#(
http://research.microsoft.com/projects/specsharp/papers/krml136.pdf

 on page 3) is to adopt C++ style field initialization after the : following
the constructor name and before the base (super) call. EG the example above
in SPEC# would be:

Derived( int value ) : this.value( value ), base() {}


CUSTOMER SUBMITTED WORKAROUND :
The only work around I know is to manipulate the bytecode. The system I have
used is to pass normal Java through the compiler (with super before field
initialization) and then use a bytcode manipulator called Javassist to move
the call to super to after the field initialization as a post processing
operation on the class file.
workaround:
comments:    (company - Personal submission , email - howard.lovatt at iee.org)
=================================================================

On 9 October 2011 13:42, Joe Darcy <joe.darcy at oracle.com> wrote:

> Ulf Zibis wrote:
> > Anyway,
> >      int c = a + b;
> > doesn't affect any object field initialization.
> > It's just a local variable, which gets lost after the instance is
> instantiated.
> >
> > As workaround, you can always use a static helper method which does the
> same:
> >      super(staticHelper(a, b));
> >
> > So I agree, it would reasonable, to allow some code in advance of this()
> or super().
> >
> > + 1 for your proposal, Vimil Saju.
> >
>
> This is not a proposal, it is a question!
>
> The answer to the question has already been given on the list: since
> superclass state of the object is not initialized until after the
> superclass constructor is called, the Java language requires that a call
> to a superclass constructor occur in the first statement of a subclass
> constructor in an attempt to reduce logic errors in initialization.
>
> This restriction is annoying at time, but no one has put forward a
> detailed proposal for how the requirement could be sensibility loosened
> in a way that can be standardized and tested.
>
> -Joe
>
> > -Ulf
> >
> >
> >
> > Am 08.10.2011 01:39, schrieb Daniel Yokomizo:
> >
> >> On Oct 7, 2011 1:58 PM, "Paul Benedict"<pbenedict at apache.org>  wrote:
> >>
> >>> It's a compiler error because the superclass is guaranteed to be
> >>> initialized first before the subclass.
> >>>
> >> Not guaranteed by the JVM, as in anonymous inner classes.
> >>
> >>
> >>> On Fri, Oct 7, 2011 at 11:51 AM, Vimil Saju<vimilsaju at yahoo.com>
>  wrote:
> >>>
> >>>> If you have subclass then java requires that this() or super has to be
> >>>>
> >> first statement in the constructor of the subclass.
> >>
> >>>> Here is an example
> >>>>
> >>>> publicclassMyClass{
> >>>>          publicMyClass(intx){}
> >>>> }
> >>>>
> >>>> publicclassMySubClassextendsMyClass{
> >>>>          publicMySubClass(inta,intb){
> >>>>                  intc =a +b;
> >>>>                  super(c); // COMPILE ERROR
> >>>>          }
> >>>> }The above compilation error can be resolved by rewriting the code in
> >>>>
> >> the constructor as follows
> >>
> >>>> publicclassMySubClassextendsMyClass{
> >>>>          publicMySubClass(inta,intb){
> >>>>                  super(a + b);
> >>>>          }
> >>>> }Can't the Java compiler detect that in the previous code there was no
> >>>>
> >> access to the instance fields or methods and therefore allow the code to
> >> compile without any error.
> >>
> >
> >
>
>
>


-- 
  -- Howard.


From howard.lovatt at gmail.com  Sun Oct 16 20:35:30 2011
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Mon, 17 Oct 2011 14:35:30 +1100
Subject: Please rethink extended enums inclusion
In-Reply-To: <CAOdgdgxbRnSnTTJcV47cKhUyMnfgsfN=3DdS8r-ceUcGjq_Ttg@mail.gmail.com>
References: <CAOdgdgxbRnSnTTJcV47cKhUyMnfgsfN=3DdS8r-ceUcGjq_Ttg@mail.gmail.com>
Message-ID: <CACR_FB7xitYmVoJiAK5FLcJc6eVia3ktp6w8itCpecML+=twNA@mail.gmail.com>

I too have suggested abstract enums in the past and at the last coin
initiative there was some discussion about the idea. As an alternative, can
defender methods from Java 8 be used instead of an abstract class? For the
usage that I want, saving repeated code, this would be viable.

On 8 October 2011 04:50, Alex Miller <alex at puredanger.com> wrote:

> On Fri, Oct 7, 2011, Jose Antonio Illescas Del Olmo
> <jantonio.illescas at rbcdexia-is.es> wrote:
> > Now we have hundred of enums on our project (finantial application with
> > 120.000 lines) an repeat same code on any enum... (*mark as red*)
>
> I would second that I think having abstract enums would be useful.
> One use case I ran into and blogged about long ago is here if you're
> interested:
>
> http://tech.puredanger.com/2008/01/10/property-enum/
>
> Alex Miller
>
>


-- 
  -- Howard.


From reinier at zwitserloot.com  Wed Oct 19 19:50:08 2011
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Thu, 20 Oct 2011 04:50:08 +0200
Subject: PROPOSAL: Named and Optional parameters, "Java-style"
In-Reply-To: <CAM-X9gWH5Ed8Hm3CnR-hLYyN=XM6EWsOWxveerMWiuSwpNLFNg@mail.gmail.com>
References: <CAM-X9gWRgwf+Zyzf47A4cdyvARHU=s1nGtnHZVHG_mTsT+_FgA@mail.gmail.com>
	<CABLGb9wNMW=8FZyNFmsseMTHu+xiX-57oBnHddxYyePoUAznGA@mail.gmail.com>
	<4E4D3B9E.3040308@oracle.com>
	<CAM-X9gUcOC1JEmR++JwNDq6-hzAWfmJ1fEQkV4+Zjx7gyFzNfQ@mail.gmail.com>
	<CAM-X9gVKjqHtQrO5v7SQMqFR+YHPad3tcHfLwNC_Kwx6CPivsg@mail.gmail.com>
	<CAJH9WWStPHaUpX4F1ESu+X97CW2ouZXV_oAsWm14TAoL5y3Veg@mail.gmail.com>
	<CAM-X9gXfi+TpA2XuAU0HiqiUcQFp3j8XvK5Ui71B1=-Ns_ovDg@mail.gmail.com>
	<821uwdu1d5.fsf@mid.bfk.de>
	<CAM-X9gX6azgZAHtMh-fMsy2KB8NEfZ37J1bt+sJ3aoXggX94Sw@mail.gmail.com>
	<CAJH9WWQNZdutH8NRe_qbEZwZGpZ9y9DeBbiJYg5TeXBT89g=bw@mail.gmail.com>
	<CAM-X9gXRsy+A6GkxERyUn-paT+UAsFJBknbd0UqZJF_uuKwRrA@mail.gmail.com>
	<CABLGb9xEwPNKrQFMLQS0H94ZQ_OJCQyN=7egnjw4r1qj_OA-iA@mail.gmail.com>
	<CAM-X9gWH5Ed8Hm3CnR-hLYyN=XM6EWsOWxveerMWiuSwpNLFNg@mail.gmail.com>
Message-ID: <CAK6PxWP+EHp5LT3XR6B-yhwZnFaZCgEhLNyBa5TofJ6Evr12MQ@mail.gmail.com>

This is one of those features that's near the top of my 'want' list, but,
this proposal is not complete. The issues that I see with it:

(A) How does this affect resolution of methods? If I have public void foo()
and public void foo({int named = 5}), and somewhere also I call foo(), which
method is called? Or, alternatively, how is the compiler going to prevent
both of these methods existing? Will class files that somehow contain both
anyway fail in the verifier, or is there an obscure resolution algorithm in
these rare cases?

(B) Your plan of sticking the relevant type information in an annotation
doesn't work, because the classes you can stick in an annotation value
cannot be generified, so, you can make int.class, but you can't make
List<Integer>.class, just List.class.

 --Reinier Zwitserloot


From reinier at zwitserloot.com  Wed Oct 19 19:58:45 2011
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Thu, 20 Oct 2011 04:58:45 +0200
Subject: Opportunistic coin improvements for JDK8: Can those be tracked
	someplace? (Any annotation in annotations)
Message-ID: <CAK6PxWNcR44ptZ57UMtXS4h3q_DBv73O_s_3Dcve8ogjfO7pHA@mail.gmail.com>

A minor update to annotations is on the 'hey, maybe we can get around to it
for 8' list, to be specific: Allowing the same annotation to show up
multiple times on the same node.

If annotations are being looked at anyway, I'd love to be able to add
"Annotation" and "Annotation[]" to the list of legal return types for an
annotation method declaration. The valid constants that can be used for
these are _any_ annotation, i.e.:

@OnMethod({@SuppressWarnings("all"), @Generated})
private final int foo; // An annotation processor will generate a new file
with a method based on this field.


It seems like a pretty low-impact change, but without a coin process I'm not
sure I should bother putting in the effort to write it up and make a javac
patch. If there's more clarity that annotations are going to go through some
changes anyway, will there still be enough time for me to cook up a patch so
it can be considered?

 --Reinier Zwitserloot


From frederic.martini at gmail.com  Thu Oct 20 02:14:50 2011
From: frederic.martini at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Martini?=)
Date: Thu, 20 Oct 2011 11:14:50 +0200
Subject: PROPOSAL: Named and Optional parameters, "Java-style"
In-Reply-To: <CAK6PxWP+EHp5LT3XR6B-yhwZnFaZCgEhLNyBa5TofJ6Evr12MQ@mail.gmail.com>
References: <CAM-X9gWRgwf+Zyzf47A4cdyvARHU=s1nGtnHZVHG_mTsT+_FgA@mail.gmail.com>
	<CABLGb9wNMW=8FZyNFmsseMTHu+xiX-57oBnHddxYyePoUAznGA@mail.gmail.com>
	<4E4D3B9E.3040308@oracle.com>
	<CAM-X9gUcOC1JEmR++JwNDq6-hzAWfmJ1fEQkV4+Zjx7gyFzNfQ@mail.gmail.com>
	<CAM-X9gVKjqHtQrO5v7SQMqFR+YHPad3tcHfLwNC_Kwx6CPivsg@mail.gmail.com>
	<CAJH9WWStPHaUpX4F1ESu+X97CW2ouZXV_oAsWm14TAoL5y3Veg@mail.gmail.com>
	<CAM-X9gXfi+TpA2XuAU0HiqiUcQFp3j8XvK5Ui71B1=-Ns_ovDg@mail.gmail.com>
	<821uwdu1d5.fsf@mid.bfk.de>
	<CAM-X9gX6azgZAHtMh-fMsy2KB8NEfZ37J1bt+sJ3aoXggX94Sw@mail.gmail.com>
	<CAJH9WWQNZdutH8NRe_qbEZwZGpZ9y9DeBbiJYg5TeXBT89g=bw@mail.gmail.com>
	<CAM-X9gXRsy+A6GkxERyUn-paT+UAsFJBknbd0UqZJF_uuKwRrA@mail.gmail.com>
	<CABLGb9xEwPNKrQFMLQS0H94ZQ_OJCQyN=7egnjw4r1qj_OA-iA@mail.gmail.com>
	<CAM-X9gWH5Ed8Hm3CnR-hLYyN=XM6EWsOWxveerMWiuSwpNLFNg@mail.gmail.com>
	<CAK6PxWP+EHp5LT3XR6B-yhwZnFaZCgEhLNyBa5TofJ6Evr12MQ@mail.gmail.com>
Message-ID: <CAM-X9gUYsC9kdvPXUVGmS=tDkyB-uB8_M4Sw8v1Jk4HCq0OJ6Q@mail.gmail.com>

(A) We already have this problem with varargs. For example with method foo()
and foo(Object...args).
In this case the empty foo() is called. We can opt for the same choice here.

But you're right : there is still a problem if we use varargs and named-args
: foo(Object...args) and foo(Object named=null). Which method is called when
I call foo() ?

I think it's reasonable to generate an "ambiguous" compilation error in this
case, like when we have foo(CharSequence) and foo(Serializable) and we call
foo("Hello")...


(B) That's true... and I fear that this implies a change in the bytecode :(


Le 20 octobre 2011 04:50, Reinier Zwitserloot <reinier at zwitserloot.com> a
?crit :

> This is one of those features that's near the top of my 'want' list, but,
> this proposal is not complete. The issues that I see with it:
>
> (A) How does this affect resolution of methods? If I have public void foo()
> and public void foo({int named = 5}), and somewhere also I call foo(), which
> method is called? Or, alternatively, how is the compiler going to prevent
> both of these methods existing? Will class files that somehow contain both
> anyway fail in the verifier, or is there an obscure resolution algorithm in
> these rare cases?
>
> (B) Your plan of sticking the relevant type information in an annotation
> doesn't work, because the classes you can stick in an annotation value
> cannot be generified, so, you can make int.class, but you can't make
> List<Integer>.class, just List.class.
>
>  --Reinier Zwitserloot
>
>
>


From forax at univ-mlv.fr  Thu Oct 20 02:40:35 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 20 Oct 2011 11:40:35 +0200
Subject: PROPOSAL: Named and Optional parameters, "Java-style"
In-Reply-To: <CAM-X9gUYsC9kdvPXUVGmS=tDkyB-uB8_M4Sw8v1Jk4HCq0OJ6Q@mail.gmail.com>
References: <CAM-X9gWRgwf+Zyzf47A4cdyvARHU=s1nGtnHZVHG_mTsT+_FgA@mail.gmail.com>
	<CABLGb9wNMW=8FZyNFmsseMTHu+xiX-57oBnHddxYyePoUAznGA@mail.gmail.com>
	<4E4D3B9E.3040308@oracle.com>
	<CAM-X9gUcOC1JEmR++JwNDq6-hzAWfmJ1fEQkV4+Zjx7gyFzNfQ@mail.gmail.com>
	<CAM-X9gVKjqHtQrO5v7SQMqFR+YHPad3tcHfLwNC_Kwx6CPivsg@mail.gmail.com>
	<CAJH9WWStPHaUpX4F1ESu+X97CW2ouZXV_oAsWm14TAoL5y3Veg@mail.gmail.com>
	<CAM-X9gXfi+TpA2XuAU0HiqiUcQFp3j8XvK5Ui71B1=-Ns_ovDg@mail.gmail.com>
	<821uwdu1d5.fsf@mid.bfk.de>
	<CAM-X9gX6azgZAHtMh-fMsy2KB8NEfZ37J1bt+sJ3aoXggX94Sw@mail.gmail.com>
	<CAJH9WWQNZdutH8NRe_qbEZwZGpZ9y9DeBbiJYg5TeXBT89g=bw@mail.gmail.com>
	<CAM-X9gXRsy+A6GkxERyUn-paT+UAsFJBknbd0UqZJF_uuKwRrA@mail.gmail.com>
	<CABLGb9xEwPNKrQFMLQS0H94ZQ_OJCQyN=7egnjw4r1qj_OA-iA@mail.gmail.com>
	<CAM-X9gWH5Ed8Hm3CnR-hLYyN=XM6EWsOWxveerMWiuSwpNLFNg@mail.gmail.com>
	<CAK6PxWP+EHp5LT3XR6B-yhwZnFaZCgEhLNyBa5TofJ6Evr12MQ@mail.gmail.com>
	<CAM-X9gUYsC9kdvPXUVGmS=tDkyB-uB8_M4Sw8v1Jk4HCq0OJ6Q@mail.gmail.com>
Message-ID: <4E9FEC93.1010709@univ-mlv.fr>

On 10/20/2011 11:14 AM, Fr?d?ric Martini wrote:
> (A) We already have this problem with varargs. For example with method foo()
> and foo(Object...args).
> In this case the empty foo() is called. We can opt for the same choice here.
>
> But you're right : there is still a problem if we use varargs and named-args
> : foo(Object...args) and foo(Object named=null). Which method is called when
> I call foo() ?
>
> I think it's reasonable to generate an "ambiguous" compilation error in this
> case, like when we have foo(CharSequence) and foo(Serializable) and we call
> foo("Hello")...

In that case, adding a default value to an existing method is not source 
compatible !

>
>
> (B) That's true... and I fear that this implies a change in the bytecode :(

http://weblogs.java.net/blog/forax/archive/2011/01/21/jsr-292-goodness-named-parameters

R?mi



From frederic.martini at gmail.com  Thu Oct 20 05:33:18 2011
From: frederic.martini at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Martini?=)
Date: Thu, 20 Oct 2011 14:33:18 +0200
Subject: PROPOSAL: Named and Optional parameters, "Java-style"
In-Reply-To: <4E9FEC93.1010709@univ-mlv.fr>
References: <CAM-X9gWRgwf+Zyzf47A4cdyvARHU=s1nGtnHZVHG_mTsT+_FgA@mail.gmail.com>
	<CABLGb9wNMW=8FZyNFmsseMTHu+xiX-57oBnHddxYyePoUAznGA@mail.gmail.com>
	<4E4D3B9E.3040308@oracle.com>
	<CAM-X9gUcOC1JEmR++JwNDq6-hzAWfmJ1fEQkV4+Zjx7gyFzNfQ@mail.gmail.com>
	<CAM-X9gVKjqHtQrO5v7SQMqFR+YHPad3tcHfLwNC_Kwx6CPivsg@mail.gmail.com>
	<CAJH9WWStPHaUpX4F1ESu+X97CW2ouZXV_oAsWm14TAoL5y3Veg@mail.gmail.com>
	<CAM-X9gXfi+TpA2XuAU0HiqiUcQFp3j8XvK5Ui71B1=-Ns_ovDg@mail.gmail.com>
	<821uwdu1d5.fsf@mid.bfk.de>
	<CAM-X9gX6azgZAHtMh-fMsy2KB8NEfZ37J1bt+sJ3aoXggX94Sw@mail.gmail.com>
	<CAJH9WWQNZdutH8NRe_qbEZwZGpZ9y9DeBbiJYg5TeXBT89g=bw@mail.gmail.com>
	<CAM-X9gXRsy+A6GkxERyUn-paT+UAsFJBknbd0UqZJF_uuKwRrA@mail.gmail.com>
	<CABLGb9xEwPNKrQFMLQS0H94ZQ_OJCQyN=7egnjw4r1qj_OA-iA@mail.gmail.com>
	<CAM-X9gWH5Ed8Hm3CnR-hLYyN=XM6EWsOWxveerMWiuSwpNLFNg@mail.gmail.com>
	<CAK6PxWP+EHp5LT3XR6B-yhwZnFaZCgEhLNyBa5TofJ6Evr12MQ@mail.gmail.com>
	<CAM-X9gUYsC9kdvPXUVGmS=tDkyB-uB8_M4Sw8v1Jk4HCq0OJ6Q@mail.gmail.com>
	<4E9FEC93.1010709@univ-mlv.fr>
Message-ID: <CAM-X9gWMrXJj3Z8L90i88ubmtiSDvL5_GdBAckoLHv3rx3nBGw@mail.gmail.com>

(A) I just say that this will not break existing code...
Of course the simple fact of changing an existing class can break
compatibility.


(B) It seems to me that parameter's name is not always present on the
bytecode, like when you compile with no debugging info (-g:none).

Using JSR292 and invokedynamic is a great approach for this problem !
But it should not be possible on all methods, to avoid possible
incompatibility on the future...



2011/10/20 R?mi Forax <forax at univ-mlv.fr>

> On 10/20/2011 11:14 AM, Fr?d?ric Martini wrote:
> > (A) We already have this problem with varargs. For example with method
> foo()
> > and foo(Object...args).
> > In this case the empty foo() is called. We can opt for the same choice
> here.
> >
> > But you're right : there is still a problem if we use varargs and
> named-args
> > : foo(Object...args) and foo(Object named=null). Which method is called
> when
> > I call foo() ?
> >
> > I think it's reasonable to generate an "ambiguous" compilation error in
> this
> > case, like when we have foo(CharSequence) and foo(Serializable) and we
> call
> > foo("Hello")...
>
> In that case, adding a default value to an existing method is not source
> compatible !
>
> >
> >
> > (B) That's true... and I fear that this implies a change in the bytecode
> :(
>
>
> http://weblogs.java.net/blog/forax/archive/2011/01/21/jsr-292-goodness-named-parameters
>
> R?mi
>
>
>


From forax at univ-mlv.fr  Thu Oct 20 06:32:58 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 20 Oct 2011 15:32:58 +0200
Subject: PROPOSAL: Named and Optional parameters, "Java-style"
In-Reply-To: <CAM-X9gWMrXJj3Z8L90i88ubmtiSDvL5_GdBAckoLHv3rx3nBGw@mail.gmail.com>
References: <CAM-X9gWRgwf+Zyzf47A4cdyvARHU=s1nGtnHZVHG_mTsT+_FgA@mail.gmail.com>
	<4E4D3B9E.3040308@oracle.com>
	<CAM-X9gUcOC1JEmR++JwNDq6-hzAWfmJ1fEQkV4+Zjx7gyFzNfQ@mail.gmail.com>
	<CAM-X9gVKjqHtQrO5v7SQMqFR+YHPad3tcHfLwNC_Kwx6CPivsg@mail.gmail.com>
	<CAJH9WWStPHaUpX4F1ESu+X97CW2ouZXV_oAsWm14TAoL5y3Veg@mail.gmail.com>
	<CAM-X9gXfi+TpA2XuAU0HiqiUcQFp3j8XvK5Ui71B1=-Ns_ovDg@mail.gmail.com>
	<821uwdu1d5.fsf@mid.bfk.de>
	<CAM-X9gX6azgZAHtMh-fMsy2KB8NEfZ37J1bt+sJ3aoXggX94Sw@mail.gmail.com>
	<CAJH9WWQNZdutH8NRe_qbEZwZGpZ9y9DeBbiJYg5TeXBT89g=bw@mail.gmail.com>
	<CAM-X9gXRsy+A6GkxERyUn-paT+UAsFJBknbd0UqZJF_uuKwRrA@mail.gmail.com>
	<CABLGb9xEwPNKrQFMLQS0H94ZQ_OJCQyN=7egnjw4r1qj_OA-iA@mail.gmail.com>
	<CAM-X9gWH5Ed8Hm3CnR-hLYyN=XM6EWsOWxveerMWiuSwpNLFNg@mail.gmail.com>
	<CAK6PxWP+EHp5LT3XR6B-yhwZnFaZCgEhLNyBa5TofJ6Evr12MQ@mail.gmail.com>
	<CAM-X9gUYsC9kdvPXUVGmS=tDkyB-uB8_M4Sw8v1Jk4HCq0OJ6Q@mail.gmail.com>
	<4E9FEC93.1010709@univ-mlv.fr>
	<CAM-X9gWMrXJj3Z8L90i88ubmtiSDvL5_GdBAckoLHv3rx3nBGw@mail.gm!
	ail.com>
Message-ID: <4EA0230A.3000104@univ-mlv.fr>

On 10/20/2011 02:33 PM, Fr?d?ric Martini wrote:
> (A) I just say that this will not break existing code...
> Of course the simple fact of changing an existing class can break
> compatibility.

The only way to not break code is to consider that
optional parameters are used if all other ways to call a method
have failed (classical pre-1.5, boxing, varargs).

>
> (B) It seems to me that parameter's name is not always present on the
> bytecode, like when you compile with no debugging info (-g:none).

Yes, currently you have no way to be sure to have parameter names of a 
method.
I think there is a proposal to spec a new bytecode attribute for
storing parameter name for Java 8.

>
> Using JSR292 and invokedynamic is a great approach for this problem !
> But it should not be possible on all methods, to avoid possible
> incompatibility on the future...

Could you elaborate ?

R?mi



From jantonio.illescas at rbcdexia-is.es  Thu Oct 20 06:57:51 2011
From: jantonio.illescas at rbcdexia-is.es (Jose Antonio Illescas Del Olmo)
Date: Thu, 20 Oct 2011 15:57:51 +0200
Subject: Traits for java
Message-ID: <4EA028DF.4040209@rbcdexia-is.es>

I don't know if this list is the best place to submit this request.

One interesting feature can be Traits (interfaces with implemented methods)


      Split multiples functionalities on each Traits and remove 
macro-classes with macro-functionalities


Please see: http://code.google.com/p/groovypptest/wiki/Traits

    PD: this change is minimun from a java coder view (some methods on 
interfaces can have a default implementation)


From frederic.martini at gmail.com  Thu Oct 20 07:09:56 2011
From: frederic.martini at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Martini?=)
Date: Thu, 20 Oct 2011 16:09:56 +0200
Subject: PROPOSAL: Named and Optional parameters, "Java-style"
In-Reply-To: <4EA0230A.3000104@univ-mlv.fr>
References: <CAM-X9gWRgwf+Zyzf47A4cdyvARHU=s1nGtnHZVHG_mTsT+_FgA@mail.gmail.com>
	<4E4D3B9E.3040308@oracle.com>
	<CAM-X9gUcOC1JEmR++JwNDq6-hzAWfmJ1fEQkV4+Zjx7gyFzNfQ@mail.gmail.com>
	<CAM-X9gVKjqHtQrO5v7SQMqFR+YHPad3tcHfLwNC_Kwx6CPivsg@mail.gmail.com>
	<CAJH9WWStPHaUpX4F1ESu+X97CW2ouZXV_oAsWm14TAoL5y3Veg@mail.gmail.com>
	<CAM-X9gXfi+TpA2XuAU0HiqiUcQFp3j8XvK5Ui71B1=-Ns_ovDg@mail.gmail.com>
	<821uwdu1d5.fsf@mid.bfk.de>
	<CAM-X9gX6azgZAHtMh-fMsy2KB8NEfZ37J1bt+sJ3aoXggX94Sw@mail.gmail.com>
	<CAJH9WWQNZdutH8NRe_qbEZwZGpZ9y9DeBbiJYg5TeXBT89g=bw@mail.gmail.com>
	<CAM-X9gXRsy+A6GkxERyUn-paT+UAsFJBknbd0UqZJF_uuKwRrA@mail.gmail.com>
	<CABLGb9xEwPNKrQFMLQS0H94ZQ_OJCQyN=7egnjw4r1qj_OA-iA@mail.gmail.com>
	<CAM-X9gWH5Ed8Hm3CnR-hLYyN=XM6EWsOWxveerMWiuSwpNLFNg@mail.gmail.com>
	<CAK6PxWP+EHp5LT3XR6B-yhwZnFaZCgEhLNyBa5TofJ6Evr12MQ@mail.gmail.com>
	<CAM-X9gUYsC9kdvPXUVGmS=tDkyB-uB8_M4Sw8v1Jk4HCq0OJ6Q@mail.gmail.com>
	<4E9FEC93.1010709@univ-mlv.fr>
	<CAM-X9gWMrXJj3Z8L90i88ubmtiSDvL5_GdBAckoLHv3rx3nBGw@mail.gmail.com>
	<4EA0230A.3000104@univ-mlv.fr>
Message-ID: <CAM-X9gXDJ+Z=5XzsmtZFGHuKLABvRcar-D4vE05QSycCzz6qBw@mail.gmail.com>

If the langage allow to call any existing methods using named-parameters,
the parameter's names will become a very important part of the API, like
class or method's names. So any change in the parameter's names will be a
potentially breaking change !

It would be better to limit that to some methods (tagged via annotation or
keyword).


Fred,


2011/10/20 R?mi Forax <forax at univ-mlv.fr>

>
> > But it should not be possible on all methods, to avoid possible
> > incompatibility on the future...
>
> Could you elaborate ?
>
> R?mi
>
>
>


From joe.darcy at oracle.com  Thu Oct 20 07:26:24 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 20 Oct 2011 07:26:24 -0700
Subject: Traits for java
In-Reply-To: <4EA028DF.4040209@rbcdexia-is.es>
References: <4EA028DF.4040209@rbcdexia-is.es>
Message-ID: <4EA02F90.9080900@oracle.com>

On 10/20/2011 06:57 AM, Jose Antonio Illescas Del Olmo wrote:
> I don't know if this list is the best place to submit this request.

The proper place to submit such requests is
http://bugreport.sun.com/bugreport/

> One interesting feature can be Traits (interfaces with implemented methods)
>
>
>        Split multiples functionalities on each Traits and remove
> macro-classes with macro-functionalities
>
>
> Please see: http://code.google.com/p/groovypptest/wiki/Traits
>
>      PD: this change is minimun from a java coder view (some methods on
> interfaces can have a default implementation)
>

FYI, this is similar to the defender methods/virtual extension methods 
being worked on in the context of Project Lambda:

     http://openjdk.java.net/projects/lambda/
     http://mail.openjdk.java.net/mailman/listinfo/lambda-dev

Cheers,

-Joe



From forax at univ-mlv.fr  Thu Oct 20 07:54:19 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 20 Oct 2011 16:54:19 +0200
Subject: Traits for java
In-Reply-To: <4EA028DF.4040209@rbcdexia-is.es>
References: <4EA028DF.4040209@rbcdexia-is.es>
Message-ID: <4EA0361B.6000104@univ-mlv.fr>

On 10/20/2011 03:57 PM, Jose Antonio Illescas Del Olmo wrote:
> I don't know if this list is the best place to submit this request.
>
> One interesting feature can be Traits (interfaces with implemented methods)
>
>
>        Split multiples functionalities on each Traits and remove
> macro-classes with macro-functionalities
>
>
> Please see: http://code.google.com/p/groovypptest/wiki/Traits
>
>      PD: this change is minimun from a java coder view (some methods on
> interfaces can have a default implementation)
>

Java 8 will have something along that line.

R?mi



From david.holmes at oracle.com  Thu Oct 20 16:36:03 2011
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 21 Oct 2011 09:36:03 +1000
Subject: Traits for java
In-Reply-To: <4EA02F90.9080900@oracle.com>
References: <4EA028DF.4040209@rbcdexia-is.es> <4EA02F90.9080900@oracle.com>
Message-ID: <4EA0B063.6070301@oracle.com>

On 21/10/2011 12:26 AM, Joe Darcy wrote:
> On 10/20/2011 06:57 AM, Jose Antonio Illescas Del Olmo wrote:
>> I don't know if this list is the best place to submit this request.
>
> The proper place to submit such requests is
> http://bugreport.sun.com/bugreport/

I think these days the right thing to do is to create a JEP:

http://openjdk.java.net/jeps/0
http://openjdk.java.net/jeps/1

but even then it should be discussed on an open mailing-list 
before/during/after formulation.

David

>> One interesting feature can be Traits (interfaces with implemented methods)
>>
>>
>>         Split multiples functionalities on each Traits and remove
>> macro-classes with macro-functionalities
>>
>>
>> Please see: http://code.google.com/p/groovypptest/wiki/Traits
>>
>>       PD: this change is minimun from a java coder view (some methods on
>> interfaces can have a default implementation)
>>
>
> FYI, this is similar to the defender methods/virtual extension methods
> being worked on in the context of Project Lambda:
>
>       http://openjdk.java.net/projects/lambda/
>       http://mail.openjdk.java.net/mailman/listinfo/lambda-dev
>
> Cheers,
>
> -Joe
>
>


From joe.darcy at oracle.com  Fri Oct 28 17:22:37 2011
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Fri, 28 Oct 2011 17:22:37 -0700
Subject: Opportunistic coin improvements for JDK8: Can those be tracked
	someplace? (Any annotation in annotations)
In-Reply-To: <CAK6PxWNcR44ptZ57UMtXS4h3q_DBv73O_s_3Dcve8ogjfO7pHA@mail.gmail.com>
References: <CAK6PxWNcR44ptZ57UMtXS4h3q_DBv73O_s_3Dcve8ogjfO7pHA@mail.gmail.com>
Message-ID: <4EAB474D.7000007@oracle.com>

Hello,

The request for this kind of extension to annotations has come up before.

The RuntimeVisibleAnnotations and RuntimeInvisibleAnnotations attributes 
might need to be updated to support this feature since at a top level in 
the class file the annotation information is stored as [member name, 
data] pairs and not [member name, member type, data] triples.

Platform changes needed by this request would include changes to javac 
to write out the revised annotations and revisions to the 
annotation-reading methods in core reflection and javax.lang.model.

Another adjustment to annotations that was been requested is something 
in the space of allowing two annotation types to have a common supertype 
other than java.lang.annotation.Annotation.  For example, allow 
annotation types to implement interfaces or allow one annotation type to 
extend another.

You're free to work on a patch, but I don't think it would be likely to 
get into 8.

Regards,

-Joe

On 10/19/2011 7:58 PM, Reinier Zwitserloot wrote:
> A minor update to annotations is on the 'hey, maybe we can get around to it
> for 8' list, to be specific: Allowing the same annotation to show up
> multiple times on the same node.
>
> If annotations are being looked at anyway, I'd love to be able to add
> "Annotation" and "Annotation[]" to the list of legal return types for an
> annotation method declaration. The valid constants that can be used for
> these are _any_ annotation, i.e.:
>
> @OnMethod({@SuppressWarnings("all"), @Generated})
> private final int foo; // An annotation processor will generate a new file
> with a method based on this field.
>
>
> It seems like a pretty low-impact change, but without a coin process I'm not
> sure I should bother putting in the effort to write it up and make a javac
> patch. If there's more clarity that annotations are going to go through some
> changes anyway, will there still be enough time for me to cook up a patch so
> it can be considered?
>
>   --Reinier Zwitserloot
>


From joe.darcy at oracle.com  Fri Oct 28 17:31:39 2011
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Fri, 28 Oct 2011 17:31:39 -0700
Subject: Why does this() and super() have to be the first statement in
	a constructor?
In-Reply-To: <CACR_FB4cNsRYpM3H2VJCdV7aO_p=RJ+7nQqdH3Xv3Ci9raXX7w@mail.gmail.com>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>
	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>
	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
	<4E9033F4.2080202@gmx.de> <4E910A24.1070109@oracle.com>
	<CACR_FB4cNsRYpM3H2VJCdV7aO_p=RJ+7nQqdH3Xv3Ci9raXX7w@mail.gmail.com>
Message-ID: <4EAB496B.6030007@oracle.com>

Hello,

I have no plans to work on fleshing out a proposal in this problem space.

My assessment of the problem is that it is certainly an irritation, but 
that the opportunity cost of fixing this irritation as opposed to making 
other language improvements is not favorable.

Even given a formal proposal and an implementation, there would be a 
nontrivial testing cost.

-Joe

On 10/16/2011 4:41 PM, Howard Lovatt wrote:
> I proposed this a long while ago, see email chain below. My particular 
> requirement was wanting a field initialised so that the super 
> constructor could call an instance method defined in 
> the derived class. The example I gave in the email below was contrived 
> to keep it short. The actual use case was very similar to an inner 
> class (therefore easy to see why you would want this because inner 
> clas do this already).
>
> My proposal was to allow read and write of a class's own fields (not 
> those in super) and local variables before super/this was called.
>
> Would the above description be a sufficiently detailed request to 
> start working on a formal proposal? Is this something that is likely 
> to get support if a formal proposal was submitted?
>
> Cheers,
>
>  -- Howard.
>
> =================================================================
>
> from 	IncidentDaemon at sun.com <mailto:IncidentDaemon at sun.com> 
> IncidentDaemon at sun.com <mailto:IncidentDaemon at sun.com>
> to 	howard.lovatt at iee.org <mailto:howard.lovatt at iee.org>
> date 	23 February 2006 21:37
> subject 	Your Report (Review ID: 654094) - Alow field inizialization 
> before super call in constructors
>
> 	
> hide details 23/02/2006
> 	
>
> ************************************************
> Your report has been assigned an internal review ID of: 654094
>
> This review ID is NOT visible on on Sun Developer Network (SDN).
>
> We greatly appreciate your interest in improving the quality of 
> Java(tm) Technology from Sun Microsystems.
>
> Please be aware that the large volume of reports we receive sometimes 
> prevents us from responding individually to each message.
>
> We currently have a three week average response time.  If the 
> information is determined to be a new bug, or a duplicate of a known 
> bug, you will receive a followup email containing a seven digit bug 
> number.  You may search for, view, or vote for this bug on the Bug 
> Database at http://bugs.sun.com/
> .
>
> If you just reported an issue that could have a major impact on your 
> project and you require a timely response, please consider purchasing 
> one of the support offerings at http://java.sun.com/support/index.html
> .
>
> The Sun Developer Network (http://developers.sun.com 
> <http://developers.sun.com/>
> ) is a free service that Sun offers.  To join, visit 
> http://developers.sun.com/global/join_sdn.html
> .
>
> For a limited time, SDN members can obtain fully licensed Java IDEs 
> for web and enterprise development.  More information is at 
> http://developers.sun.com/prodtech/javatools/free/
> .
>
> Thank you for your help.
>
>
>
> ---------------------------------------------------------------
>
>
> dateCreated: Thu Feb 23 03:37:04 MST 2006
> type: rfe
> cust_name:   Howard Lovatt
> cust_email: howard.lovatt at iee.org <mailto:howard.lovatt at iee.org>
> jdcid:       hlovatt
> status:      Waiting
> category:    java
> subcategory: specification
> company:     Personal submission
> release:     5.0
> hardware:    x86
> OSversion:   win_xp
> priority:    4
> synopsis:    Alow field inizialization before super call in constructors
> description: A DESCRIPTION OF THE REQUEST :
> At present some code cannot be written using Java source code you need 
> to manipulate the bytecode. In particular the Java language requires 
> that super be the first line of a constructor. However there are times 
> when you need to initialize a field from arguments supplied to the 
> constructor before calling the constructor. So that the 
> super constructor can call virtual methods defined in the base class 
> and not get errors (e.g. NullPointerException). EG:
>
> class Base {
>    Base() { System.out.println( get_int() ); }
>    abstract int get_int();
> }
>
> public class Derived extends Base {
>    Integer value;
>    Derived ( int value ) { this.value = value; } // NB Autoboxed
>    int get_int() { return value; } // NB unboxed automatically
>
>    public static void main( String[] notUsed ) { new Derived( 1 ); } 
> // NullPointerException!
> }
>
> The above code throws a null pointer because you can't initialize 
> field value before calling super (implicitly) in Derived's constructor.
>
> The suggested solution is to allow super to appear after the 
> initialization, e.g. allow:
>
> Derived( int value ) {
>    this.value = value;
> super()
> }
>
> If super isn't explicityly mentioned then, as at present, it is 
> assumed to be the first line.
>
> JUSTIFICATION :
> There are plenty of examples were initializing fields is needed.
>
> EG1 you can't manually write the equivalent of an inner class because 
> the field that points to the outer class needs to be initialized 
> before the call to super.
>
> EG2 this problem has been recognized for C# and an MS proposed 
> language extension called 
> SPEC#(http://research.microsoft.com/projects/specsharp/papers/krml136.pdf
>  on page 3) is to adopt C++ style field initialization after the : 
> following the constructor name and before the base (super) call. EG 
> the example above in SPEC# would be:
>
> Derived( int value ) : this.value( value ), base() {}
>
>
> CUSTOMER SUBMITTED WORKAROUND :
> The only work around I know is to manipulate the bytecode. The system 
> I have used is to pass normal Java through the compiler (with 
> super before field initialization) and then use a bytcode manipulator 
> called Javassist to move the call to super to after the field 
> initialization as a post processing operation on the class file.
> workaround:
> comments:    (company - Personal submission , email - 
> howard.lovatt at iee.org <mailto:howard.lovatt at iee.org>)
> =================================================================
>
> On 9 October 2011 13:42, Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     Ulf Zibis wrote:
>     > Anyway,
>     >      int c = a + b;
>     > doesn't affect any object field initialization.
>     > It's just a local variable, which gets lost after the instance
>     is instantiated.
>     >
>     > As workaround, you can always use a static helper method which
>     does the same:
>     >      super(staticHelper(a, b));
>     >
>     > So I agree, it would reasonable, to allow some code in advance
>     of this() or super().
>     >
>     > + 1 for your proposal, Vimil Saju.
>     >
>
>     This is not a proposal, it is a question!
>
>     The answer to the question has already been given on the list: since
>     superclass state of the object is not initialized until after the
>     superclass constructor is called, the Java language requires that
>     a call
>     to a superclass constructor occur in the first statement of a subclass
>     constructor in an attempt to reduce logic errors in initialization.
>
>     This restriction is annoying at time, but no one has put forward a
>     detailed proposal for how the requirement could be sensibility
>     loosened
>     in a way that can be standardized and tested.
>
>     -Joe
>
>     > -Ulf
>     >
>     >
>     >
>     > Am 08.10.2011 01:39, schrieb Daniel Yokomizo:
>     >
>     >> On Oct 7, 2011 1:58 PM, "Paul Benedict"<pbenedict at apache.org
>     <mailto:pbenedict at apache.org>>  wrote:
>     >>
>     >>> It's a compiler error because the superclass is guaranteed to be
>     >>> initialized first before the subclass.
>     >>>
>     >> Not guaranteed by the JVM, as in anonymous inner classes.
>     >>
>     >>
>     >>> On Fri, Oct 7, 2011 at 11:51 AM, Vimil
>     Saju<vimilsaju at yahoo.com <mailto:vimilsaju at yahoo.com>>  wrote:
>     >>>
>     >>>> If you have subclass then java requires that this() or super
>     has to be
>     >>>>
>     >> first statement in the constructor of the subclass.
>     >>
>     >>>> Here is an example
>     >>>>
>     >>>> publicclassMyClass{
>     >>>>          publicMyClass(intx){}
>     >>>> }
>     >>>>
>     >>>> publicclassMySubClassextendsMyClass{
>     >>>>          publicMySubClass(inta,intb){
>     >>>>                  intc =a +b;
>     >>>>                  super(c); // COMPILE ERROR
>     >>>>          }
>     >>>> }The above compilation error can be resolved by rewriting the
>     code in
>     >>>>
>     >> the constructor as follows
>     >>
>     >>>> publicclassMySubClassextendsMyClass{
>     >>>>          publicMySubClass(inta,intb){
>     >>>>                  super(a + b);
>     >>>>          }
>     >>>> }Can't the Java compiler detect that in the previous code
>     there was no
>     >>>>
>     >> access to the instance fields or methods and therefore allow
>     the code to
>     >> compile without any error.
>     >>
>     >
>     >
>
>
>
>
>
> -- 
>   -- Howard.
>


From sonali.goel at oracle.com  Sat Oct 29 12:16:30 2011
From: sonali.goel at oracle.com (sonali.goel at oracle.com)
Date: Sat, 29 Oct 2011 12:16:30 -0700 (PDT)
Subject: Auto Reply: coin-dev Digest, Vol 33, Issue 19
Message-ID: <4ac7b0c9-3ac4-42c2-a9c6-272f0cc447b7@default>

This is an auto-reply. 
I am out of office and will reply to emails when I get back on 11/01. 

For urgent matters, please contact Vita.Santrucek at oracle.com


From vimilsaju at yahoo.com  Sat Oct 29 12:34:33 2011
From: vimilsaju at yahoo.com (Vimil Saju)
Date: Sat, 29 Oct 2011 12:34:33 -0700 (PDT)
Subject: Why does this() and super() have to be the first statement in a
	constructor?
In-Reply-To: <4EAB496B.6030007@oracle.com>
References: <1318006280.12046.YahooMailNeo@web161201.mail.bf1.yahoo.com>
	<CABLGb9w-FKBz7Ne-jbU6x5xNH02k6_D2Toqf3hF6a6fYQtEuGQ@mail.gmail.com>
	<CAOF0wK-1aCBnR6wC4y=ZwMRhTyfcygPjYyZhyUOLHstV2AdZ-g@mail.gmail.com>
	<4E9033F4.2080202@gmx.de> <4E910A24.1070109@oracle.com>
	<CACR_FB4cNsRYpM3H2VJCdV7aO_p=RJ+7nQqdH3Xv3Ci9raXX7w@mail.gmail.com>
	<4EAB496B.6030007@oracle.com>
Message-ID: <1319916873.29258.YahooMailNeo@web161204.mail.bf1.yahoo.com>

Can we at least maintain a list of feature requests so that if there ever is a coin 9, these requests might get considered again??


________________________________
From: Joseph Darcy <joe.darcy at oracle.com>
To: Howard Lovatt <howard.lovatt at gmail.com>
Cc: "coin-dev at openjdk.java.net" <coin-dev at openjdk.java.net>
Sent: Friday, October 28, 2011 5:31 PM
Subject: Re: Why does this() and super() have to be the first statement in a constructor?

Hello,

I have no plans to work on fleshing out a proposal in this problem space.

My assessment of the problem is that it is certainly an irritation, but 
that the opportunity cost of fixing this irritation as opposed to making 
other language improvements is not favorable.

Even given a formal proposal and an implementation, there would be a 
nontrivial testing cost.

-Joe

On 10/16/2011 4:41 PM, Howard Lovatt wrote:
> I proposed this a long while ago, see email chain below. My particular 
> requirement was wanting a field initialised so that the super 
> constructor could call an instance method defined in 
> the derived class. The example I gave in the email below was contrived 
> to keep it short. The actual use case was very similar to an inner 
> class (therefore easy to see why you would want this because inner 
> clas do this already).
>
> My proposal was to allow read and write of a class's own fields (not 
> those in super) and local variables before super/this was called.
>
> Would the above description be a sufficiently detailed request to 
> start working on a formal proposal? Is this something that is likely 
> to get support if a formal proposal was submitted?
>
> Cheers,
>
>? -- Howard.
>
> =================================================================
>
> from ??? IncidentDaemon at sun.com <mailto:IncidentDaemon at sun.com> 
> IncidentDaemon at sun.com <mailto:IncidentDaemon at sun.com>
> to ??? howard.lovatt at iee.org <mailto:howard.lovatt at iee.org>
> date ??? 23 February 2006 21:37
> subject ??? Your Report (Review ID: 654094) - Alow field inizialization 
> before super call in constructors
>
> ??? 
> hide details 23/02/2006
> ??? 
>
> ************************************************
> Your report has been assigned an internal review ID of: 654094
>
> This review ID is NOT visible on on Sun Developer Network (SDN).
>
> We greatly appreciate your interest in improving the quality of 
> Java(tm) Technology from Sun Microsystems.
>
> Please be aware that the large volume of reports we receive sometimes 
> prevents us from responding individually to each message.
>
> We currently have a three week average response time.? If the 
> information is determined to be a new bug, or a duplicate of a known 
> bug, you will receive a followup email containing a seven digit bug 
> number.? You may search for, view, or vote for this bug on the Bug 
> Database at http://bugs.sun.com/
> .
>
> If you just reported an issue that could have a major impact on your 
> project and you require a timely response, please consider purchasing 
> one of the support offerings at http://java.sun.com/support/index.html
> .
>
> The Sun Developer Network (http://developers.sun.com 
> <http://developers.sun.com/>
> ) is a free service that Sun offers.? To join, visit 
> http://developers.sun.com/global/join_sdn.html
> .
>
> For a limited time, SDN members can obtain fully licensed Java IDEs 
> for web and enterprise development.? More information is at 
> http://developers.sun.com/prodtech/javatools/free/
> .
>
> Thank you for your help.
>
>
>
> ---------------------------------------------------------------
>
>
> dateCreated: Thu Feb 23 03:37:04 MST 2006
> type: rfe
> cust_name:?  Howard Lovatt
> cust_email: howard.lovatt at iee.org <mailto:howard.lovatt at iee.org>
> jdcid:? ? ?  hlovatt
> status:? ? ? Waiting
> category:? ? java
> subcategory: specification
> company:? ?  Personal submission
> release:? ?  5.0
> hardware:? ? x86
> OSversion:?  win_xp
> priority:? ? 4
> synopsis:? ? Alow field inizialization before super call in constructors
> description: A DESCRIPTION OF THE REQUEST :
> At present some code cannot be written using Java source code you need 
> to manipulate the bytecode. In particular the Java language requires 
> that super be the first line of a constructor. However there are times 
> when you need to initialize a field from arguments supplied to the 
> constructor before calling the constructor. So that the 
> super constructor can call virtual methods defined in the base class 
> and not get errors (e.g. NullPointerException). EG:
>
> class Base {
>? ? Base() { System.out.println( get_int() ); }
>? ? abstract int get_int();
> }
>
> public class Derived extends Base {
>? ? Integer value;
>? ? Derived ( int value ) { this.value = value; } // NB Autoboxed
>? ? int get_int() { return value; } // NB unboxed automatically
>
>? ? public static void main( String[] notUsed ) { new Derived( 1 ); } 
> // NullPointerException!
> }
>
> The above code throws a null pointer because you can't initialize 
> field value before calling super (implicitly) in Derived's constructor.
>
> The suggested solution is to allow super to appear after the 
> initialization, e.g. allow:
>
> Derived( int value ) {
>? ? this.value = value;
> super()
> }
>
> If super isn't explicityly mentioned then, as at present, it is 
> assumed to be the first line.
>
> JUSTIFICATION :
> There are plenty of examples were initializing fields is needed.
>
> EG1 you can't manually write the equivalent of an inner class because 
> the field that points to the outer class needs to be initialized 
> before the call to super.
>
> EG2 this problem has been recognized for C# and an MS proposed 
> language extension called 
> SPEC#(http://research.microsoft.com/projects/specsharp/papers/krml136.pdf
>? on page 3) is to adopt C++ style field initialization after the : 
> following the constructor name and before the base (super) call. EG 
> the example above in SPEC# would be:
>
> Derived( int value ) : this.value( value ), base() {}
>
>
> CUSTOMER SUBMITTED WORKAROUND :
> The only work around I know is to manipulate the bytecode. The system 
> I have used is to pass normal Java through the compiler (with 
> super before field initialization) and then use a bytcode manipulator 
> called Javassist to move the call to super to after the field 
> initialization as a post processing operation on the class file.
> workaround:
> comments:? ? (company - Personal submission , email - 
> howard.lovatt at iee.org <mailto:howard.lovatt at iee.org>)
> =================================================================
>
> On 9 October 2011 13:42, Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>? ?  Ulf Zibis wrote:
>? ?  > Anyway,
>? ?  >? ? ? int c = a + b;
>? ?  > doesn't affect any object field initialization.
>? ?  > It's just a local variable, which gets lost after the instance
>? ?  is instantiated.
>? ?  >
>? ?  > As workaround, you can always use a static helper method which
>? ?  does the same:
>? ?  >? ? ? super(staticHelper(a, b));
>? ?  >
>? ?  > So I agree, it would reasonable, to allow some code in advance
>? ?  of this() or super().
>? ?  >
>? ?  > + 1 for your proposal, Vimil Saju.
>? ?  >
>
>? ?  This is not a proposal, it is a question!
>
>? ?  The answer to the question has already been given on the list: since
>? ?  superclass state of the object is not initialized until after the
>? ?  superclass constructor is called, the Java language requires that
>? ?  a call
>? ?  to a superclass constructor occur in the first statement of a subclass
>? ?  constructor in an attempt to reduce logic errors in initialization.
>
>? ?  This restriction is annoying at time, but no one has put forward a
>? ?  detailed proposal for how the requirement could be sensibility
>? ?  loosened
>? ?  in a way that can be standardized and tested.
>
>? ?  -Joe
>
>? ?  > -Ulf
>? ?  >
>? ?  >
>? ?  >
>? ?  > Am 08.10.2011 01:39, schrieb Daniel Yokomizo:
>? ?  >
>? ?  >> On Oct 7, 2011 1:58 PM, "Paul Benedict"<pbenedict at apache.org
>? ?  <mailto:pbenedict at apache.org>>? wrote:
>? ?  >>
>? ?  >>> It's a compiler error because the superclass is guaranteed to be
>? ?  >>> initialized first before the subclass.
>? ?  >>>
>? ?  >> Not guaranteed by the JVM, as in anonymous inner classes.
>? ?  >>
>? ?  >>
>? ?  >>> On Fri, Oct 7, 2011 at 11:51 AM, Vimil
>? ?  Saju<vimilsaju at yahoo.com <mailto:vimilsaju at yahoo.com>>? wrote:
>? ?  >>>
>? ?  >>>> If you have subclass then java requires that this() or super
>? ?  has to be
>? ?  >>>>
>? ?  >> first statement in the constructor of the subclass.
>? ?  >>
>? ?  >>>> Here is an example
>? ?  >>>>
>? ?  >>>> publicclassMyClass{
>? ?  >>>>? ? ? ? ? publicMyClass(intx){}
>? ?  >>>> }
>? ?  >>>>
>? ?  >>>> publicclassMySubClassextendsMyClass{
>? ?  >>>>? ? ? ? ? publicMySubClass(inta,intb){
>? ?  >>>>? ? ? ? ? ? ? ? ? intc =a +b;
>? ?  >>>>? ? ? ? ? ? ? ? ? super(c); // COMPILE ERROR
>? ?  >>>>? ? ? ? ? }
>? ?  >>>> }The above compilation error can be resolved by rewriting the
>? ?  code in
>? ?  >>>>
>? ?  >> the constructor as follows
>? ?  >>
>? ?  >>>> publicclassMySubClassextendsMyClass{
>? ?  >>>>? ? ? ? ? publicMySubClass(inta,intb){
>? ?  >>>>? ? ? ? ? ? ? ? ? super(a + b);
>? ?  >>>>? ? ? ? ? }
>? ?  >>>> }Can't the Java compiler detect that in the previous code
>? ?  there was no
>? ?  >>>>
>? ?  >> access to the instance fields or methods and therefore allow
>? ?  the code to
>? ?  >> compile without any error.
>? ?  >>
>? ?  >
>? ?  >
>
>
>
>
>
> -- 
>?  -- Howard.
>