running processor on file that has unsupported annotations and annotaions without processors results in brokem message file:

< warning: compiler message file broken: key=apt.warn.AnnotationsWithoutProcessors arguments=test.apf.C,D, {1}, {2}, {3}, {4}, {5}, {6}, {7}
---
> warning: Annotation types without processors: [test.apf.C, D]
3c3
< warning: compiler message file broken: key=apt.warn.AnnotationsWithoutProcessors arguments=test.apf.C, {1}, {2}, {3}, {4}, {5}, {6}, {7}
---
> warning: Annotation types without processors: [test.apf.C]
Err out did not match.
Posted Date : 2008-08-01 00:30:29.0

N/A

This is a regression introduced during the ongoing work on javac diagnostic (in particular by CR 6720185). The problem described in this CR is relatively simple: the APT's Bark class doesn't update the Log's diagnostic formatter. As such, the default diagnostic formatter is used for generating the diagnostic output. Unfortunately the default formatter cannot localize apt messages, as its Messages object doesn't contain the apt resource bundle list.

Solution: the Log's formatter should be updated to a new diagnostic formatter the stores the correct Messages object.

This is quite easy to do - I did it and the problem disappeared as expected. But this made me quite worried for a number of reasons:

1) What is/should be the relationship between the Log's diagnostic formatter and the DiagnosticFactory's formatter? Currently those are two different objects; not sure that this is the right approach. We could have the Log to update the DiagnosticFormatter's formatter so that the two references point to the very same object (the one created in Log).

2) There's a scary initialization loop in APT's Bark. Log gets initialized on its own during APT startup and then it basically gets re-initialized when an instance of Bark (that subclasses Log) get created. When Bark has been created there are two live Log objects, a javac-like Log and an apt-specific Log (Bark). This means two diagnostic factories, two diagnostic formatters (actually four of them, since, as I said, factories and logs don't share the same formatter object). Lot of error-prone replication - at least in my opinion.

3) Is there any other tool (javap, javah, and so on) that could have been broken in a similar way? I.e. does each tool define its own Log's subclass? Or, rather, this is a setting that only occurs within apt, given its closeness to javac? I tried to look inside javap and I found that javap handles all the diagnostic-dependent code internally, with no dependency from Log; this would mean no problem! Can I assume this behaviour for all the other tools? Is my guessing about javap correct?

4) The code handling ResourceBundle(s) in AbstractDiagnosticFormatter is not good enough. In particular, in line 134 of AbstractDiagnosticFormatter.java there is a dangerous call to Messages.getDefaultBundle(); I added this call when we decided to introduce Formattable arguments; since the toString() of a Formattable argument accepts a ResourceBundle I need to pass one from the diagnostic formatter when the formatter has to format a formattable arg. The problem is that the formatter stores a Messages object and that this object doesn't expose the bundles that it uses internally (actually there is a list of bundles). But, even with Messages exposing the bundles, the toString(ResourceBundle) method of a Formattable arg would still be problematic, as a tool like javap creates a Messages object with two ResourceBundles in it, and one should look at both in order to localize a given key.
Posted Date : 2008-08-06 15:27:20.0

Only apt has a "Bark" like wrapper around Log.  No other javac-related tools has the same awkward architecture.  I'd recommend changing apt as little as possible to work when interfacing to the improved javac message reporting.
Posted Date : 2008-08-07 17:22:40.0