|[ANN] compilerMonitor email@example.com (Erik Ostermueller) (2004-02-27)|
|From:||Erik Ostermueller <firstname.lastname@example.org>|
|Date:||27 Feb 2004 22:12:34 -0500|
|Keywords:||tools, available, Java|
|Posted-Date:||27 Feb 2004 22:12:34 EST|
I thought this tool might interest the group.
The CompilerMonitor is an open-source tool that makes a record of all
compiler errors generated by Sun's 'javac' executable. Instead of
calling javac directly, invoke javacM, which will invoke Sun's javac
installed on your hard disk. When you invoke javacM, it will behave
just like javac, but it does more.
1) It puts copies of the compiler error messages into
text files in a pre-configured location on your hard
2) It stores a copy of source files that didn't
compile (say HelloWorld.java) in the above
3) Say you fix the compiler error in HelloWorld.java
and kick off javacM again. javacM remembers that
HelloWorld.java just failed compilation. In an effort
to record precisely how you fixed the error, javacM
stores a copy of the newly fixed source. When you
compile cleanly one time after another, javacM doesn't
archive anything -- which means zero over head w/
Why would anyone want this functionality?
A usability professional could use this tool to
discover how a programmer interacts with the compiler.
Observed in the right environment, you could address
a) Which error messages are seen most frequently?
b) How long does it take the developer to understand
what each error message is telling him/her?
c) Which messages are easier/more difficult to
d) When a developer goes to fix a compiler error, what
information must he/she first hunt down that _could_
have been supplied by the compiler error message?
Answering these questions could help us to build
compilers that make developers more efficient.
Return to the
Search the comp.compilers archives again.