Language feature proposal: Partial Java types

[Stephen Colebourne]

There are definitely use cases for a feature like this. For example,
Joda-Beans [1] adopts the source code generation approach to beans.
This results in classes that are 90% autogenerated code:
Mutable, with setters as well as getters:
https://github.com/JodaOrg/joda-beans/blob/v1.0/src/test/java/org/joda/beans/gen/SimplePerson.java#L43
Immutable, with getters and builders:
https://github.com/JodaOrg/joda-beans/blob/v1.0/src/test/java/org/joda/beans/gen/ImmPerson.java#L52

This approach ensures good Javadoc and debugging, because the classes
are just standard Java source files. It also allows genuinely
immutable classes (because they can be final). But it is far from
ideal, and partial classes, or the ability to generate into the same
source file, is really what is needed here. However, desirability does
not create engineering development time within Oracle.

(The choice of using annotation processing to generate an
implementation - as per the AutoValue or Immutables projects - is one
option, but we felt the trade off of having real Java source code was
preferable, providing the class can be regenerated without losing
logic added by the developer. Joda-Beans also provides abstraction
over properties, which isn't provided by those other projects.)

Just to note that value types in a future JDK may provide some of what
is needed here for "immutable beans" (though not all). But Brian Goetz
has also noted that large value types may behave in a different way to
smaller ones that fit in registers.

Stephen
[1] http://www.joda.org/joda-beans/


On 21 November 2014 08:02, Gunnar Morling <gunnar at hibernate.org> wrote:
> <TL,DR: Being able to split up the source code of one Java type into
> several parts would allow for the implementation of "soft keywords" to
> emulate language features via code generators>
>
> Hi,
>
> At Devoxx last week, Brian gave indications that properties are unlikely to
> be added as a Java language feature [1], one of the reasons being that
> several competing ideas exist how "properties" should look like.
>
> As a work-around, the required boiler-plate code can be generated using
> annotation processors (see e.g. Joe's post at [2]). That approach is
> limited though by the fact that the JSR 269 API is not meant to modify
> sources. Only additional sources may be generated, e.g. a super-class with
> getters/setters. Projects such as Lombok [3] try to fill the gap by
> altering the AST via internal APIs. This works, but it bends the usage of
> annotation processors quite a bit.
>
> I therefore would like to suggest the addition of partial types to the Java
> language. Similar to what's possible in C# [4], that'd allow the source
> code of one Java class/interface to be split up into several source files.
>
> That way, annotation processors (and other tools such as IDEs) could
> generate amendments to classes by creating additional parts which all
> together form the resulting type. The following shows an example:
>
>     // this part is hand-written; e.g. in src/main/java
>     @Partial
>     public class OrderLine {
>
>         @Property private String item;
>
>         // ...
>     }
>
>     // this part is generated; e.g. in target/generated-sources
>     @Partial
>     public class OrderLine {
>
>         public String getItem() { return item };
>         public void setItem(String item) { this.item = item };
>     }
>
> The @Partial annotation (or a specific keyword) denotes that the OrderLine
> class comprises of several parts. The @Property annotation is a custom
> annotation, triggering a corresponding annotation processor which generates
> the second part with the getter/setter for the property.
>
> Partials would be a compile-time only feature. The compiler would have to
> consider all the parts of a class; At runtime, the OrderLine class would
> exactly look as if it was given in one source file.
>
> Partial types would allow for the implementation of "soft keywords" to
> emulate language features via code generators. Examples are properties,
> property "literals", delegates etc. Instead of baking all these things into
> the language, projects could have their own notion of such concepts if they
> wish.
>
> I believe partial types would be in the spirit of JSR 269, as one still
> would not modify existing sources, but rather add new sources. The
> developer would see all the source code of a class, so there is no mismatch
> between the sources and the AST. IDE tooling could provide linking and easy
> navigation between all the parts of one class.
>
> I'd be very interested in any feedback on this. Would it be worth pursuing?
> If so, I could try to work on a more specific proposal and/or prototype
> implementing this feature.
>
> Thanks,
>
> --Gunnar
>
> [1] http://blog.joda.org/2014/11/no-properties-in-java-language.html
> [2]
> https://blogs.oracle.com/darcy/entry/properties_via_annotation_processing
> [3] http://projectlombok.org/
> [4] http://msdn.microsoft.com/en-us/library/wa80x488.aspx