X

Musings on JDK development

Mustang Build 92 JSR 269 API Changes

Build 92 of Mustang includes API changes from the JSR 269

http://blogs.sun.com/roller/page/darcy?entry=jsr_269_in_public_review">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.







    Replacefiler.createSourceFile()
    // Pre-build 92
    Withfiler.createSourceFile().getWriter()
    // Build 92 and later
  • The return type of createClassFile was changed from OutputStream to JavaFileObject.







    Replacefiler.createClassFile()
    // Pre-build 92
    Withfiler.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.







    Replacefiler.createBinaryFile(loc, pkg, relPath)
    // Pre-build 92
    Withfiler.createResource(javaFileManagerLoc, pkg, relPath).getWriter()
    // Build 92 and later
  • The createTextFile method was removed; its functionality can be gotten from createResource.









    Replacefiler.createTextFile(loc, pkg, relPath, charsetName)
    // Pre-build 92
    Withfiler.createResource(javaFileManagerLoc, pkg, relPath).getWriter()
    // Build 92 and later
    Ornew 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>.







    ReplaceroundEnv.getSpecifiedTypeElements()
    // Pre-build 92
    WithtypesIn(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.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.