Java: Type aliases support annotation processing tool (APT)? -

i never worked type aliases, concept seems useful feature adding semantics on same-typed objects , defending common typos.

let's say, there void foo(float volume, float weight). it's ok if it's invoked this: foo(v, m), foo(m, v) not obvious typo. void process(iterable<file> javapath, iterable<file> classpath) can use case. unfortunately there no type aliases in java, , workarounds true overkill:

• aggregating single field class (boxing primitive object; object in object having reference; more complicated serializing/deserializing rules)
• extending 1 class 1 (like how create variable type alias in java - impossible primitives; classes may final or have inaccessible constructor).

so both of them have drawbacks , runtime/performance cost.

as far can see, in java, runtime-based "type aliasing" might replaced compile-time checks, @notnull , @nullable processed. there static type-alias checkers/apt tools featuring support constructions void foo(@volume float volume, @weight float weight), checker verify such "type safety" @ compile time , require passed variables/constants , literals annotated (at declaration , call sites respectively)?

---

this question has been raised because i'm working on java-source code processing tool can use multiple back-ends (currently, jdt only). long want jdt-agnostic, have business objects types, methods , fields. despite, lose lot of information coming jdt ast, best current approach tool use of strings (it allows perform analysis that's enough scope of tool). methods void process(string type, string field, string method) confusing, i've created type, field , method represent domain objects , jdt-agnostic. they're fine, don't expect them extended in future (all of these 3 types have single private final string name; field + had override hashcode/equals , tostring). led me idea of type-checking apt once again. long it's ok process raw data, enough have void process(@type string type, @field string field, @method string method) (i still use single object).

if problem looks ambiguous when call foo(v,m) people may mistakenly wrote foo(m,v) without warning or visible clue of error, may use fluent-builder-like pattern:

(code not tested, wrote demonstrate idea)

public class myclass {     public class foostub {         int volume;         int weight;         public foostub withvolume(int v) {             this.volume = v;             return this;         }         public foostub withweight(int w) {             this.weight = w;             return this;         }         public int run() {   // or call getresult() or whatever want             assert.notnull(volume);             assert.notnull(weight);             return foo(volume,weight);  // calling method of outer class         }     }      public int foo(int volume, int weight) {   // hide if want         return volume * weight;     }     public foostub foo() {         return new foostub();     }  } 

by doing so, caller can do

myclass myobj = ....; int result = myobj.foo().withvolume(a).withweight(b).run(); // same result = myobject.foo(a,b);