• Type: Bug
• Component: core-libs
• Sub-Component: javax.lang.model
• Affected Version: 7

• Priority: P2
• Status: Closed
• Resolution: Fixed
• OS: generic
• CPU: generic

• Submitted: 2009-08-28
• Updated: 2012-03-22
• Resolved: 2011-03-08

JDK 7
7 b114Fixed

EVALUATION (Issue 1.) There is a minor related but separable problem that JavaCompiler.genEndPos is not being propogated between rounds and should be. This affects the ability to get tree positions in some circumstances. The default is true if you're using -Xjcov or have set a diagListener in 199, so in those cases, you're OK. It may also get preset to true in JavacTaskImpl, but if that is the only reason it is true, then you're not OK on subsequent rounds. Solution: Propogate genEndPos between instances of JavaCompiler in JavaCompiler.initRound. Now on to doc comments. There are multiple issues here. Doc comments are enabled by calling DocCommentScanner.preRegister(context). This registers a Context.Factory<DocCommentScanner.Factory> in the context that will create DocCommentScanner.Factory when needed. (Issue 2.) The preRegister mechanism assumes a single context. This is not the case when annotation processing is active, so factories that are preRegistered in the initial context do not get used in subsequent rounds, leaving the default impl to be used in subsequent rounds. Although the problem comes up specifically for DocCommentScanner.Factory, this is a general problem for any client extending javac functionality by using the Context mechanism. I tried automatically copying factories between rounds, but that doesn't work because with the current definition of Context.Factory, they are bound to a specific context. This is because the Factory make() method does not take a Context, the instance of the factory is assumed to know the context to be used. There are two possible solutions: change the signature of Context.Factory.make to take a Context, or provide a new alternative Factory2 class to be used that has the required signature. Whichever solution is used, this enables Factory(2) objects to be propogated from one context to the next during anno processing. I've got proof-of-concept using a new Factory2 class, and it works OK. (Issue 3.) Even with a fix for 2, Elements.getDocComments does not work in all cases. In particular, it works for JSR199 invocation, but it doesn't work with javac from the command line. The problem is the deferred use of DocCommentScanner.preRegister inside JavaCompiler.initProcessAnnotations. It is being called too late. The constructor for JavaCompiler gets the ParserFactory, and the constructor for ParserFactory gets a ScannerFactory, and that is before DocCommentScanner.preRegister is invoked. Before proposing a fix, here's a history lesson. Doc comments used to be handled by Scanner, in javac.parser, but only used by javadoc. The, it was split out into DocCommentScanner, and actually moved to com.sun.tools.javadoc. But since doc comments are an important part of javac modelling, DocCommentScanner got moved back into javac.parser, but the custom DocCommentScanner.preRegsiter mechanism remains. Since doc comments are important, I think they should be supported in a first class way by Scanner.Factory. This means that the Scanner.Factory newScanner methods should take a boolean keepDocComments parameter, and this will be used by Scanner.factory to select an appropriate impl of Scanner. This means that DocCommentScanner.preRegister will go away. This also means we don't need to fix Issue 2 as part of this work, and it implicitly fixes Issue 3 as well. By analogy with similar changes to Parser, I'd also propose that we move Scanner.Factory to a new top level class ScannerFactory. This saves us initializing the Scanner class unless it is going to be used. 22-09-2010 EVALUATION Warning: The doit.sh script in the attachment is not complete -- it refers to missing source files and refers to absolute filenames like /home/ss144514/jdk_test/jdk170_PITs and /java/sqe4/tools/... 18-09-2010