Small property support.

[Joe Darcy]

Greetings.

As previously stated

    http://blogs.sun.com/darcy/entry/guidance_measure_language_change_size

properties are almost certainly out of scope for Project Coin.

This proposal lacks sufficient detail for full evaluation.

On 03/18/09 05:26 AM, Ruslan wrote:
> PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0
>
> AUTHOR(S): Ruslan Lazukov
>
> OVERVIEW
> Create infrastructure for using properties in Java, but make it small 
> change for becoming part of Java 7.
> I suggest to use synthetic sugar for properties in Java 7.
>
> FEATURE SUMMARY:
> Lack of properties in Java make developers to create a lot of solutions 
> for solving this issue.
> But issue can be solved only from language level.
>
> MAJOR ADVANTAGE:
> Solve lack of Java property support, but this solve will be small not 
> medium size.
>
> MAJOR BENEFIT:
> Improve check ability of java code. Improve readability of code.
> Code become less error prone.
>
> MAJOR DISADVANTAGE:
> Developer should understand how properties work - the same as enhanced 
> for-each.
> For-each are synthetic and real code are hidden from developer.
>
> ALTERNATIVES:
> No; Every solution need to change language.
>
>
>   

[snip]

>
> DETAILS
> SPECIFICATION:
> Main problem of Java property support in Java 7 is that Sun want to 
> create solution at one step.
> But also Sun do not have enough time and resources to do this for Java 7.
>
> My suggestion is to split "property" into many steps, and make some of 
> them in Java 7.
>
> We can use documentation created for HUGE property support, and write 
> code only in java compiler.
> All other stuff like changes in Reflection API - stay for next 3-5 years 
> (for Java 8 release).
>
> HUGE property support described here 
> http://docs.google.com/Doc?id=dfhbvdfw_1f7mzf2
>   

As previously stated, "If a proposal does not cite chapter and verse of 
the JLS for parts of its specification, that is a good indication the 
proposal is too vague." 
(http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000196.html)

This specification section is both too vague and not self-contained; the 
full information must be sent to the list and not be present only in 
external documents.

> I suggest implementation of language changes without Property object, 
> changes in Reflection API and necessity to sit
> and wait 5 years for time when Java code become more readable.
>   

Adding language features properly requires coordination of changes 
throughout the platform; that cannot easily be done piecemeal.

>
> COMPILATION: How would the feature be compiled to class files?
> No additional support necessary in class files.
>   

As explained in the form's text and as done by previous proposals, like 
this one

http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000001.html

this section is for the details of the compilation or desugaring.

> TESTING: How can the feature be tested?
> The same way as for-each.
>   

That makes no sense at all.

> LIBRARY SUPPORT: Are any supporting libraries needed for the feature?
> No, not for Java 7.
>
> REFLECTIVE APIS:
> No, not for Java 7.
>
>
> OTHER CHANGES:
> No, not for Java 7.
>
> MIGRATION:
> No migration needed.
>
>
> COMPATIBILITY
> BREAKING CHANGES:
> All existing programs remain valid.
>
> EXISTING PROGRAMS:
> The semantics of existing class files and legal source files and are
> unchanged by this feature.
>
> REFERENCES EXISTING BUGS:
> I think that there is a lot of bugs in Sun bug-tracking system.
>   

Yes, and you are supposed to find those bugs as part of submitting the form!

-Joe

> URL FOR PROTOTYPE (optional):
> Document about HUGE property that Sun presented to developers
> http://blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf, 
> page 27.
>
> Also Sun (probably) developers create a lot of documentation how 
> property should be supported from language level.
> That documents have to be used to implement this proposal fast and easy.
> HUGE property support described here 
> http://docs.google.com/Doc?id=dfhbvdfw_1f7mzf2
>
>
> WBR, Ruslan.
>
>
>
>