Value types and parameter names

[Lovro Pandzic]

Well I do understand the reasoning behind it so I guess no value would be
gained by changing the behavior for value classes.
On the side note, is there an option to get classes with the JDK with
parameter names? (like String, Integer, etc)

On Mon, Dec 1, 2014 at 8:18 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> This is two separate questions, with one answer:
>
> Q:  Would parameter names be available for value types?
> A:  I see no reason why the answer for this should be any different than
> for reference classes.
>
> Q:  Could it be turned on by default?
> A:  I see no reason why the answer for this should be any different than
> for reference classes.
>
> In both cases, there's nothing special about value types that should
> interact with parameter names in any non-obvious way; doing otherwise would
> just introduce needless complexity.  Value types are defined by classes
> just as reference types are, can have methods just like reference types do,
> and the treatment of parameter names in methods of value types should be
> identical to those of reference types.
>
> Now, maybe what you really are getting at is that you're asking to revisit
> the "why were they not turned on by default" decision (which was a complex
> decision that involved balancing multiple considerations)?
>
>
>
>
>
>
> On 12/1/2014 2:02 PM, Lovro Pandzic wrote:
>
>> Hello all,
>>
>> I've been monitoring the Valhalla project for some time now and I have a
>> question: will the new parameter names API introduced in Java 8 be
>> available for value types? If so, is there a possibility for it to be
>> turned on by default?
>>
>> One great thing I like about the new parameter names is that it provides a
>> supported way for eliminating the need of JavaBeans setters. See [1] for
>> example. In various libraries and frameworks, setters are often used as a
>> tool for both discovering component names of an object and for injecting
>> those components while constructing it because parameter names of
>> constructors were not available through reflection, at least not until
>> Java
>> 8. This approach goes against simplicity, immutability and only presents
>> boilerplate in the code. Luckily, value types are planned to be immutable
>> so setters are impossible.
>> On the other hand, without setters, the only way for constructing those
>> value types in those frameworks would be to use those constructor if they
>> have parameter names available at runtime.
>>
>> [1] https://github.com/FasterXML/jackson-module-parameter-names
>>
>> Kind Regards,
>> Lovro Pandzic
>>
>>