Mustang Build 92 JSR 269 API Changes

Build 92 of Mustang includes API changes from the JSR 269 public review draft:
  • The Filer methods return JSR 199 objects instead of a Writer or OutputStream. This revised Filer API gives clients more flexibility over how a file is written. There is also a getResource method to non-destructively read the contents of an existing file.
  • Annotation processing is supported on package-info files, which can hold package annotations. While classes and interfaces (and their contents) are the most commonly annotated entities, packages can be annotated as well so the annotation processing API should consider those annotations too. More broadly, the new API can also accommodate any additional kinds of entities that will be able to be annotated in future language versions (like superpackages in Dolphin?).

There are small code deltas to adapt existing annotation processing code to use the new API. For Filer uses:

  • The return type of createSourceFile was changed from Writer to JavaFileObject.
    Replace filer.createSourceFile() // Pre-build 92
    With filer.createSourceFile().getWriter() // Build 92 and later
  • The return type of createClassFile was changed from OutputStream to JavaFileObject.
    Replace filer.createClassFile() // Pre-build 92
    With filer.createClassFile().getOutputStream() // Build 92 and later
  • The createBinaryFile method was removed; its functionality can be gotten from createResource. The Filer.Location enum was removed and JavaFileManager.Location is used instead.
    Replace filer.createBinaryFile(loc, pkg, relPath) // Pre-build 92
    With filer.createResource(javaFileManagerLoc, pkg, relPath).getWriter() // Build 92 and later
  • The createTextFile method was removed; its functionality can be gotten from createResource.
    Replace filer.createTextFile(loc, pkg, relPath, charsetName) // Pre-build 92
    With filer.createResource(javaFileManagerLoc, pkg, relPath).getWriter() // Build 92 and later
    Or new OutputStreamWriter(filer.createResource(javaFileManagerLoc, pkg, relPath).getOutputStream(), charsetName) // Build 92 and later
For RoundEnvironment uses:
  • The getSpecifiedTypeElements method returning a Set<? extends TypeElement> was replaced with getRootElements returning a Set<? extends Element>.
    Replace roundEnv.getSpecifiedTypeElements() // Pre-build 92
    With typesIn(roundEnv.getRootElements()) // Build 92 transition
Whether or not it is reasonble to wrap getRootElements with ElementFilter.typesIn depends on the circumstances and what the processor is trying to do. Using the new API, processors should handle annotations on any kind of element. If a processor is only examining classes and interfaces, applying the typesIn filter is reasonable. If other kinds of elements need to be processed as well, the getKind method can be used to find out what an element is or a visitor can be written to implement element-specific or kind-specific operations.
Comments:

Post a Comment:
Comments are closed for this entry.
About

darcy

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll