PROPOSAL: Auto-assignment Parameters
Reinier Zwitserloot
reinier at zwitserloot.com
Wed Mar 25 13:27:36 PDT 2009
Context sensitive keyword creeps you out?
That's problematic. 'module' is already going to be one. I'd love an
alternative, but the few things I can come up with are all
considerably worse:
annotation, which is -slightly- more acceptable here than in other
places because generating methods and fields is what annotations are
supposed to do. However, they usually do so (via APT) in an entirely
new source file, not the same one.
(ab)using an existing keyword. 'const' and 'default' are the only
reasonable ones, and both of those are a stretch, in my book. I don't
like context sensitive keywords either, but as I've said before on
this list, that decision has been made: They will be part of java7,
and nothing on coin-dev is going to change that.
You should move away from the idea of 'this keyword does so much
magic!' and move towards the idea that this keyword simply declares
that the class is to have bean semantics. The amount of magic
performed by the compiler (right now, in java6) is enormous already.
The amount of magic performed by a C compiler is a few orders of
magnitude larger than that. As far as compiler magic goes, a simple
desugaring is in fact one of the simplest things it could possibly do.
As long as it doesn't cause surprises amongst the java programmer
crowd, that cannot reasonably be put forward as a con. Your suggestion
to have separate annotations is immediately going to run into the
following complaint: Oh, the boilerplate! Why can't we have 1
annotation that does it all!
Which brings us right back to my proposal.
Not auto-generating something that's already there is indeed a bit of
'magic', but is that really so far-fetched? What else should it do?
Generate an error? That's going to get the new vote as most annoying
javac error when the varargs thing finally (yay!) gets sorted via
Project Coin. There are very legitimate reasons to roll your own
methods for a few of the otherwise POJO-esque classes you'd write with
this feature. Backwards compatibility with other implementions of
hashCode() is one, and doing some processing on variables is another,
as is adding property support (with change listeners).
It would obviously be acceptable in a small data pojo to forego
hungarian notation. If it isn't - well, that won't be the first time
coding practices hurt more than they help. The thing with coding
practices is: Everyone has their own variant. One must at the very
least expect those practices to evolve a little in the face of
language changes, or one would be crippled.
What you are suggesting with parameterizing each aspect of the method
generation is going to become an entirely new programming language,
just so you can specify that you want to avoid the password field,
etcetera. The point of this proposal is very very specifically: For
the default case, we make it easy for you. If you dont like the
default case, that's perfectly allright. Roll your own method.
Just to drive the point home, here's a customized class versus how
you'd write it now. Note how the savings in size are almost ignorable,
and it now looks like a different programming language.
@GenerateConstructor(order={"bar", "foo"},
access=Access.PACKAGE_PRIVATE)
@GenerateEquals(exclude={"baz"})
@GenerateHashCode(prime=97)
@GenerateToString(JsonGenerator.class)
public class ThisIsMyDataClass {
@GenerateGetter @GenerateSetter(access=Access.PROTECTED)
private int foo;
@GenerateGetter
private final String bar;
//Oops! Forgot the annotation. Do I get any warning?
private int baz;
}
vs:
public data class ThisIsMyDataClass {
private int foo;
private final String bar;
private final int baz;
}
The point of such a proposal is NOT to ease the making of getters and
setters. It's only to do what it says on the tin: Make data classes.
--Reinier Zwitserloot
On Mar 25, 2009, at 19:25, Lawrence Kesteloot wrote:
> Reinier,
>
> The idea of adding a context-sensitive keyword creeps me out. Also
> this is doing a lot of magic based on a single keyword. Can you tell,
> at a glance, what the keyword is doing? How much is generated? What
> are the (complex) rules for auto-generating a constructor?
>
> I would prefer a more explicit approach, driven by annotations. If we
> feel like boilerplate is annoying to write and bug-prone, then we
> could have a java.lang.gen package with various annotations for
> automatically generating code. Something like:
>
> @GenerateFullConstructor
> @GenerateEqualsAndHashCode
> @GenerateToString(JsonToStringGenerator.class)
> public class Foo {
> @GenerateGetter
> private final int x;
> @GenerateGetter
> private final int y;
> @GenerateGetter
> private final String foo;
> }
>
> Then it's explicit, each annotation can have parameters to modify its
> behavior, and people can pick and choose what they need. There's no
> magic about skipping the generation of toString if you've implemented
> it.
>
> Here's an example of useful parameters for such annotations: many
> people (myself included) like to prefix fields with something. I use
> "m" (mFoo), but others use an underscore, and some both (m_foo). You'd
> want the GenerateGetter annotation to be flexible about that. My code
> would look like this:
>
> @GenerateGetter(prefix = "m")
> private final String mFoo;
>
> Your "data" keyword would preclude this, forcing me to either drop my
> (company-mandated) coding standard for data classes, or have getters
> like "getMFoo()".
>
> With GenerateEqualsAndHashCode you might want to skip some fields. You
> might want to skip fields for GenerateToString also (e.g., password
> fields, or super long strings).
>
> Lawrence
>
>
> On Wed, Mar 25, 2009 at 9:59 AM, Reinier Zwitserloot
> <reinier at zwitserloot.com> wrote:
>> There's no reference for auto-POJOs anywhere, but this should allow
>> you to write up all you need:
>>
>> 1. 'data' is a context sensitive keyword that is legal on classes.
>> The
>> 'data' keyword will add a number of members to the class.
>>
>> 2. For each field, a getter is generated, according to the beanspec
>> (getFoo() or isFoo()). if the field is not final, a setter is
>> generated, according to beanspec (setFoo()), and the field is
>> considered a property of the data class, unless it is transient. If
>> the field is public, the getter (and, if not final, the setter), is
>> not generated. For all generated getters/setters, if the getter/
>> setter
>> is already in the class, or already defined (that is; not abstract)
>> in
>> any supertype, then the getter/setter is not generated. protected and
>> visible package protected members from supertypes are also included
>> both for generating setters/getters and for hashCode/equals/toString/
>> clone (upcoming).
>>
>> 3. hashCode() and equals(): Existence of the hashCode() or equals()
>> method in any supertype is not relevant (obviously; all objects have
>> them!)
>>
>> 3a. If only one of hashCode() or equals() is present, a warning is
>> generated and neither hashCode() or equals() is auto-generated. The
>> warning basically explains that overriding one but not the other is a
>> bug.
>>
>> 3b. If both hashCode() and equals() are present, nothing happens.
>>
>> 3c. If neither is present, a hashCode() and equals() method are
>> generated. These involve all properties (non-transient visible
>> fields). equals() is defined by:
>>
>> 3c1: First check if the other object is of the exact same class as
>> ourselves; if not, false. If null, false.
>> 3c2: For each primitive property, check via == if they are equal. If
>> any isn't, false.
>> 3c3: For each object property, call its .equals(). If they aren't,
>> false.
>> 3c4: return true.
>>
>> for hashCode(), do whatever eclipse does out of the box to auto-
>> generate hashCode() methods. It basically looks like:
>>
>> final int PRIME = 31;
>> int result = 1;
>> for ( each field ) result = result*31 + field.hashCode();
>> return result;
>>
>> Where hashCode() is generated in obvious fashion for all primitives
>> (xor the upper and lower bits of longs together, convert floats and
>> doubles to long/intbits and use that, chars/bytes/ints/shorts's
>> hashCode is their own value, booleans are translated to 11/17. 'null'
>> becomes 3.
>>
>> 4. *IF* all fields are private, and *IF* all fields are final, *AND*
>> the class does not contain any explicit constructors, *AND* the class
>> has a no-args super constructor, then a constructor is generated that
>> includes all fields, in order of definition, which simply assigns
>> them
>> to the fields. visible properties from supertypes aren't included.
>>
>> 5. A toString() method is generated, if not already present in the
>> type, which produces a string like so: "MyClassName [field1=value,
>> field2=value]", for all properties. (so, non-visible fields from
>> supertypes and transient fields are skipped).
>>
>> 6 (optional). Each generated member gets a @Generated annotation,
>> which is a new annotation ( java.lang.annotations.Generated ). These
>> are @Documented and @Retention.RUNTIME.
>>
>>
>> Is it viable for coin? I'll write it up if so.
>>
>> --Reinier Zwitserloot
>>
>>
>>
>> On Mar 25, 2009, at 14:41, james lowden wrote:
>>
>>>
>>> I'd like to see both. Auto-getters/setters/equals/etc. would be
>>> really, really nice, but it would also be valuable to have a way of
>>> specifying a variety of different constructors to generate, which
>>> Mark's proposal would allow for. Example:
>>>
>>> public data class Foo {
>>> private final int x;
>>> private final int y;
>>> private final String foo;
>>>
>>> public Foo (this.x) {}
>>>
>>> public Foo (this.foo, this.y) {}
>>> }
>>>
>>>
>>> (I eliminated the types from the automagical constructors, as they
>>> can be inferred by the compiler.)
>>>
>>> This would generate all three getters and setters, equals (),
>>> hashcode (), a general constructor taking in all 3 fields, and two
>>> additional constructors, one taking in just int x, and one taking in
>>> both String foo and int y.
>>>
>>> Reinier--is there a copy of your original proposal for auto-POJOs
>>> somewhere?
>>>
>>> -JL-
>>>
>>>
>>>> From: Reinier Zwitserloot <reinier at zwitserloot.com>
>>>> Subject: Re: PROPOSAL: Auto-assignment Parameters
>>>> To: "Mark Mahieu" <markmahieu at googlemail.com>
>>>> Cc: coin-dev at openjdk.java.net
>>>> Date: Tuesday, March 24, 2009, 8:34 PM
>>>> I like where this is going, but I'd rather see a bigger
>>>> setup for auto-
>>>> POJO classes. I proposed this before and in most java
>>>> circles (outside
>>>> of coin-dev!), this idea was considered very useful:
>>>>
>>>> public data class Foo {
>>>> private final int x;
>>>> private final int y;
>>>> private final String foo;
>>>> }
>>>>
>>>>
>>>> The above class would auto-generate the getters, a
>>>> constructor,
>>>> hashCode, equals, and toString. You can add methods to it
>>>> if you want,
>>>> and if you define a method that would usually be
>>>> auto-generated, it
>>>> isn't auto-generated. So, if you need to do some extra
>>>> processing
>>>> before returning 'foo' via the getter, go right
>>>> ahead. You can even
>>>> add this later without breaking your API's
>>>> compatibility.
>>>>
>>>> --Reinier Zwitserloot
>>>>
>>>>
>>>>
>>>> On Mar 25, 2009, at 02:07, Mark Mahieu wrote:
>>>>
>>>>> HTML version + prototype available at
>>>> http://slm888.com/javac
>>>>>
>>>>>
>>>>>
>>>>> Auto-assignment Parameters v0.1
>>>>>
>>>>>
>>>>> AUTHOR(S):
>>>>>
>>>>> Mark Mahieu
>>>>>
>>>>>
>>>>> OVERVIEW
>>>>>
>>>>> FEATURE SUMMARY: Should be suitable as a summary in a
>>>> language
>>>>> tutorial.
>>>>>
>>>>> An additional form of constructor parameter which
>>>> provides automatic
>>>>> assignment of the parameter's value to an instance
>>>> field. These
>>>>> parameters
>>>>> are implicitly declared as final to prevent
>>>> unintentional
>>>>> assignments to the
>>>>> wrong variable in the constructor body.
>>>>>
>>>>>
>>>>> MAJOR ADVANTAGE: What makes the proposal a favorable
>>>> change?
>>>>>
>>>>> Reduces the likelihood of some common coding errors
>>>> relating to
>>>>> assignment
>>>>> of fields in a constructor, including those where:
>>>>>
>>>>> * a field is assigned to itself
>>>>> * the parameter is assigned instead of the field
>>>>> * the assignment to the field is missing entirely
>>>>>
>>>>> These and other errors are often caused by typos or
>>>> code refactoring.
>>>>>
>>>>>
>>>>> MAJOR BENEFIT: Why is the platform better if the
>>>> proposal is adopted?
>>>>>
>>>>> A programmer's intent is more clearly expressed
>>>> for the extremely
>>>>> common
>>>>> case of assigning a constructor parameter directly to
>>>> an instance
>>>>> field with
>>>>> the same name.
>>>>>
>>>>>
>>>>> MAJOR DISADVANTAGE: There is always a cost.
>>>>>
>>>>> As with any sugar which enables a more concise way of
>>>> expressing an
>>>>> existing
>>>>> idiom, programmers may be tempted to use it even when
>>>> the original
>>>>> form
>>>>> would be more appropriate.
>>>>>
>>>>>
>>>>> ALTERNATIVES: Can the benefits and advantages be had
>>>> some way
>>>>> without a
>>>>> language change?
>>>>>
>>>>> IDEs and tools such as FindBugs are good at warning
>>>> about the kind
>>>>> of errors
>>>>> mentioned above, however since the code in question is
>>>> usually still
>>>>> valid
>>>>> to the compiler, they are limited in what action they
>>>> can take by
>>>>> default.
>>>>>
>>>>> A language change can combine the ability to avoid
>>>> these errors
>>>>> entirely
>>>>> with a more expressive idiom, resulting in an
>>>> increased signal to
>>>>> noise
>>>>> ratio for readers of that code.
>>>>>
>>>>>
>>>>>
>>>>> EXAMPLES
>>>>>
>>>>> SIMPLE EXAMPLE: Show the simplest possible program
>>>> utilizing the new
>>>>> feature.
>>>>>
>>>>> class C {
>>>>> int i;
>>>>> C(int this.i) {}
>>>>> }
>>>>>
>>>>>
>>>>> ADVANCED EXAMPLE: Show advanced usage(s) of the
>>>> feature.
>>>>>
>>>>>
>>>>> class Proposal {
>>>>>
>>>>> private final String name;
>>>>> private final String author;
>>>>> private boolean suitableForCoin;
>>>>> private Integer score;
>>>>>
>>>>> public Proposal(String this.name,
>>>>> String this.author,
>>>>> boolean this.suitableForCoin,
>>>>> int this.score) {
>>>>>
>>>>> if (name.equals(“Auto-assignment
>>>> Parameters”)) {
>>>>> suitableForCoin = true; // final so
>>>> compile-time error
>>>>> }
>>>>> }
>>>>>
>>>>> // rest of class ...
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> DETAILS
>>>>>
>>>>>
>>>>> SPECIFICATION: Describe how the proposal affects the
>>>> grammar, type
>>>>> system,
>>>>> and meaning of expressions and statements in the Java
>>>> Programming
>>>>> Language
>>>>> as well as any other known impacts.
>>>>>
>>>>> The syntactic grammar is modified to include
>>>> auto-assignment
>>>>> parameters for
>>>>> constructors:
>>>>>
>>>>> ConstructorDeclaratorRest:
>>>>> ConstructorParameters [throws
>>>> QualifiedIdentifierList]
>>>>> MethodBody
>>>>>
>>>>> ConstructorParameters:
>>>>> ( [ConstructorParameterDecls] )
>>>>>
>>>>> ConstructorParameterDecls:
>>>>> [final] [Annotations] Type
>>>>> ConstructorParameterDeclsRest
>>>>>
>>>>> ConstructorParameterDeclsRest:
>>>>> ConstructorParameterId [ ,
>>>> ConstructorParameterDecls]
>>>>> ... ConstructorParameterId
>>>>>
>>>>> ConstructorParameterId:
>>>>> VariableDeclaratorId
>>>>> this . VariableDeclaratorId
>>>>> super . VariableDeclaratorId
>>>>>
>>>>> An auto-assignment parameter is a formal parameter
>>>> (JLSv3 §8.4.1)
>>>>> which
>>>>> specifies an instance field instead of an identifier.
>>>> Its value is
>>>>> automatically assigned to the specified field. It may
>>>> only be used
>>>>> in a
>>>>> constructor.
>>>>>
>>>>> The automatic assignment takes place after any
>>>> explicit or implicit
>>>>> invocation of another constructor, and before any
>>>> statements in the
>>>>> body of
>>>>> the constructor. A constructor which declares n
>>>> auto-assignment
>>>>> parameters
>>>>> will perform n such automatic assignments, in the
>>>> order that the
>>>>> parameters
>>>>> are declared.
>>>>>
>>>>> The parameter has the same name (JLSv3 §6.2) as the
>>>> field to which
>>>>> it is
>>>>> assigned; replacing each auto-assignment parameter
>>>> with a normal
>>>>> formal
>>>>> parameter with the same name would yield a constructor
>>>> with an
>>>>> identical
>>>>> signature. As with a normal parameter, the
>>>> parameter's name is
>>>>> entered into
>>>>> the scope of the constructor body (JLSv3 §6.3), and
>>>> therefore
>>>>> shadows the
>>>>> field (JLSv3 §6.3.1) within that scope.
>>>>>
>>>>> It is a compile-time error if the field is not
>>>> accessible from the
>>>>> constructor in which the parameter appears.
>>>>>
>>>>> It is a compile-time error if the declared type of the
>>>> parameter is
>>>>> not
>>>>> assignment compatible (JLSv3 §5.2) with the field to
>>>> which it is
>>>>> automatically assigned.
>>>>>
>>>>> If an unboxing conversion is required by an automatic
>>>> assignment, any
>>>>> NullPointerException thrown as a result (JLSv3
>>>> §5.1.8) will contain
>>>>> the name
>>>>> of the field on which the conversion failed, which may
>>>> be retrieved by
>>>>> calling getMessage() on the exception.
>>>>>
>>>>> Auto-assignment parameters are implicitly final, and
>>>> follow the
>>>>> standard
>>>>> rules for final variables (JLSv3 §4.12.4).
>>>> Explicitly declaring an
>>>>> auto-assignment parameter as final has no effect, and
>>>> does not cause a
>>>>> compilation error.
>>>>>
>>>>> Auto-assignment parameters follow the standard
>>>> definite assignment
>>>>> rules for
>>>>> formal parameters (JLSv3 §16.3).
>>>>>
>>>>> An auto-assignment parameter may be annotated.
>>>>>
>>>>> If an auto-assignment parameter is the last parameter
>>>> in the list, and
>>>>> refers to a field of array type, it may be a variable
>>>> arity parameter.
>>>>>
>>>>>
>>>>>
>>>>> COMPILATION: How would the feature be compiled to
>>>> class files? Show
>>>>> how the
>>>>> simple and advanced examples would be compiled.
>>>> Compilation can be
>>>>> expressed
>>>>> as at least one of a desugaring to existing source
>>>> constructs and a
>>>>> translation down to bytecode. If a new bytecode is
>>>> used or the
>>>>> semantics of
>>>>> an existing bytecode are changed, describe those
>>>> changes, including
>>>>> how they
>>>>> impact verification. Also discuss any new class file
>>>> attributes that
>>>>> are
>>>>> introduced. Note that there are many downstream tools
>>>> that consume
>>>>> class
>>>>> files and that they may to be updated to support the
>>>> proposal!
>>>>>
>>>>> Desugaring of the following class:
>>>>>
>>>>> class Foo {
>>>>> int value;
>>>>> Foo(Integer this.value) {
>>>>> System.out.println(value);
>>>>> }
>>>>> }
>>>>>
>>>>> would result in (unboxing desugaring omitted):
>>>>>
>>>>> class Foo {
>>>>> int value;
>>>>> Foo(final Integer value) {
>>>>> super();
>>>>> if (value == null)
>>>>> throw new
>>>> NullPointerException("value");
>>>>> this.value = value;
>>>>> System.out.println(value);
>>>>> }
>>>>> }
>>>>>
>>>>> No changes to the classfile format are required.
>>>> Tools which
>>>>> consume class
>>>>> files see the constructor signature as though it had
>>>> been written
>>>>> using
>>>>> normal formal parameters.
>>>>>
>>>>>
>>>>> TESTING: How can the feature be tested?
>>>>>
>>>>> An initial set of jtreg tests is included in the
>>>> prototype.
>>>>>
>>>>>
>>>>> LIBRARY SUPPORT: Are any supporting libraries needed
>>>> for the feature?
>>>>>
>>>>> No
>>>>>
>>>>>
>>>>> REFLECTIVE APIS: Do any of the various and sundry
>>>> reflection APIs
>>>>> need to be
>>>>> updated? This list of reflective APIs includes but is
>>>> not limited to
>>>>> core
>>>>> reflection (java.lang.Class and java.lang.reflect.*),
>>>>
>>>>> javax.lang.model.*,
>>>>> the doclet API, and JPDA.
>>>>>
>>>>> com.sun.source.tree.VariableTree would require an
>>>> additional method
>>>>> which
>>>>> returns the auto-assigned field.
>>>>>
>>>>>
>>>>> OTHER CHANGES: Do any other parts of the platform need
>>>> be updated too?
>>>>> Possibilities include but are not limited to JNI,
>>>> serialization, and
>>>>> output
>>>>> of the javadoc tool.
>>>>>
>>>>> No
>>>>>
>>>>>
>>>>> MIGRATION: Sketch how a code base could be converted,
>>>> manually or
>>>>> automatically, to use the new feature.
>>>>>
>>>>> Assignment statements in constructors for which all of
>>>> the following
>>>>> are
>>>>> true can be considered suitable for conversion:
>>>>> * the lhs of the assignment is a non-static field
>>>>> * the rhs is a parameter with the same name as the
>>>> field
>>>>> * there are no other assignments to the parameter
>>>> anywhere in the
>>>>> constructor
>>>>> * there are no assignments to, or other uses of
>>>> the field before
>>>>> the
>>>>> assignment statement in question (including invoked
>>>> constructors)
>>>>>
>>>>> Such statements can be converted by:
>>>>> 1) replacing the parameter with an auto-assignment
>>>> parameter
>>>>> (prefixing
>>>>> the existing parameter's identifier with
>>>> 'this.'), and
>>>>> 2) removing the assignment statement
>>>>>
>>>>>
>>>>>
>>>>> COMPATIBILITY
>>>>>
>>>>> BREAKING CHANGES: Are any previously valid programs
>>>> now invalid? If
>>>>> so, list
>>>>> one.
>>>>>
>>>>> No
>>>>>
>>>>>
>>>>> EXISTING PROGRAMS: How do source and class files of
>>>> earlier platform
>>>>> versions interact with the feature? Can any new
>>>> overloadings occur?
>>>>> Can any
>>>>> new overriding occur?
>>>>>
>>>>> The semantics of existing class files and legal source
>>>> files are
>>>>> unchanged
>>>>> by this feature.
>>>>>
>>>>>
>>>>>
>>>>> REFERENCES
>>>>>
>>>>> EXISTING BUGS: Please include a list of any existing
>>>> Sun bug ids
>>>>> related to
>>>>> this proposal.
>>>>>
>>>>>
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6582394
>>>>> (uses a 'setter' method rather than a
>>>> constructor in its example)
>>>>>
>>>>> FindBugs bug patterns -
>>>> http://findbugs.sourceforge.net/bugDescriptions.html
>>>>> * Self assignment of field (SA_FIELD_SELF_ASSIGNMENT)
>>>>> * Self comparison of field with itself
>>>> (SA_FIELD_SELF_COMPARISON)
>>>>> * Nonsensical self computation involving a field
>>>> (e.g., x & x)
>>>>> (SA_FIELD_SELF_COMPUTATION)
>>>>> * Self assignment of local variable
>>>> (SA_LOCAL_SELF_ASSIGNMENT)
>>>>> * Nonsensical self computation involving a variable
>>>> (e.g., x & x)
>>>>> (SA_LOCAL_SELF_COMPUTATION)
>>>>> * Uninitialized read of field in constructor
>>>> (UR_UNINIT_READ)
>>>>> * Unwritten field (UWF_UNWRITTEN_FIELD)
>>>>> * Dead store to local variable (DLS_DEAD_LOCAL_STORE)
>>>>> * Dead store of null to local variable
>>>> (DLS_DEAD_LOCAL_STORE_OF_NULL)
>>>>>
>>>>>
>>>>>
>>>>> URL FOR PROTOTYPE (optional):
>>>>>
>>>>> http://slm888.com/javac
>>>>>
>>>>>
>>>>>
>>>>> DESIGN ALTERNATIVES:
>>>>>
>>>>> The following variations have been explored and are
>>>> worth mentioning:
>>>>>
>>>>> * Allow auto-assignment parameters on all non-abstract
>>>> methods.
>>>>> This may be especially useful on the extremely
>>>> common 'setter'
>>>>> methods
>>>>> in 'value object' classes.
>>>>>
>>>>> * Remove the requirement for (or even disallow) the
>>>> type to be
>>>>> specified on
>>>>> auto-assignment parameters.
>>>>> Experimentation with this idea suggests that it may
>>>> work quite
>>>>> well for
>>>>> constructors, further emphasising the difference in
>>>> intent and
>>>>> semantics
>>>>> from those of normal parameters. However, it may not
>>>> work so well in
>>>>> combination with auto-assignment parameters on all
>>>> non-abstract
>>>>> methods, and
>>>>> requires a change to the order in which javac compiles
>>>> classes (can
>>>>> still
>>>>> pass jtreg tests).
>>>>>
>>>>> * Allow an alternative name to be specified.
>>>>> This adds additional complexity to support a
>>>> fractional
>>>>> percentage of
>>>>> cases, which could continue to use the existing coding
>>>> pattern.
>>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
More information about the coin-dev
mailing list