DO NOT REPLY [Bug 36261] New: - [jci] no class could be loaded after a compilation error occured

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36261>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36261

           Summary: [jci] no class could be loaded after a compilation error
                    occured
           Product: Commons
           Version: unspecified
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: major
          Priority: P2
         Component: Sandbox
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: joerg.heinicke@gmx.de


If a compilation error occured it is not possible to get classes again. Always
CNFE is thrown though the compilation error itself has been fixes. The reason is
simple: the store is empty. It gets emptied by the CompilingListener if the
CompilationProblemHandler.getErrorCount() is > 0. And the errorCount field gets
not reset in the CompilationProblemHandlers.

I made a little refactoring to the CompilationProblemHandler stuff:
1. The interface has just the handle(CompilationProblem) method, the counting is
removed.
2. There is an implementation called CompilationProblemCounter for counting the
errors and warnings. The counting is removed from existing
CompilationProblemHandler implementations of course (SoC ;-) ).
3. Though it would be possible to change the JavaCompiler interface to accept
more than one CompilationProblemHandler I decided to do it the implementation
way for the moment: DelegatingCompilationProblemHandler. It is instantiated with
a Collection of CompilationProblemHandlers. In case of CompilingListener it is
an instance of CompilationProblemCounter and the passed CompilationProblemHandler.
Though this solution allows the same flexibility like the mentioned change to
JavaCompiler it might end in a hierarchy of
DelegatingCompilationProblemHandlers. OTOH it simplifies the usage of the
JavaCompiler by avoiding the instantiation of a Collection for even passing just
one CompilationProblemHandler to the compiler instance.
4. LogCompilationProblemHandler renamed to CompilationProblemLogger (it also had
a little c&p bug in it, see the call to LogFactory).
5. ConsoleCompilationProblemHandler renamed to CompilationProblemConsolePrinter.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org