Language feature proposal: Partial Java types

Gunnar Morling gunnar at hibernate.org
Fri Nov 21 08:02:22 UTC 2014


<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


More information about the discuss mailing list