Joseph D. Darcy's Sun Weblog

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. (2006-07-24 16:30:54.0) Permalink