Re: javac issues

[Vaclav Barta]

Michael Cook wrote:
> Vaclav Barta <address@hidden> writes:
> > Michael Cook wrote:
> >> this approach seemed to work well enough.  for speed, i used
> >> a heuristic to scan the .class files (i just searched the raw
> >> .class file looking for any byte sequence that looked like a
> >> class name that might correspond to our sources).
> > OK, that makes sense - every existing dependency is found, and
> > there shouldn't be that many false positives... But did your
> > script handle Unicode characters in class names?
> it handled all of the unicode characters that appeared in our
> sources. :-)
That I believe :-) - but if we're talking about a reusable
solution, why not push it a bit, just for fun?

> > Here's an excuse to exercise Perl Unicode support... :-)
> actually, the script /was/ written in perl.
> > As I come to think about it, do we actually need to parse the
> > whole .class file? Isn't the list of used class names already
> > in some kind of a symbol table? I must read that JVM spec one
> > of these days...
OK, I did read a a few sections, and it *is* simple - I made 
a working prototype (in Java) of a specialized class file parser
outputting all class names mentioned in that file in a couple of
hours (it's simple because all strings needed by the class are in
the constant pool, which is conveniently located (almost) at 
the start of the file - you don't need to parse any code at all).

> i think i was finding two kinds of strings:
>   Lcom/bar/baz;
>   xxcom/bar/baz
> where xx was two binary characters indicating how many bytes
> followed.  i think the latter corresponds to string literals in
> the "const pool", and the former...well, something else.
Right, the "modified UTF" (I dislike modified "standards") format
used by Java. The best reason to write my parser in Java - I'd say
parsing that correctly is about as complicated as the whole rest
of the parser, and in Java it's simply a call to library function
(debugged one, too - at least for the common cases).

> out of 1600 source files, i did have only one false positive.
> still, the scanner seemed pretty cheesy.
I would be concerned about classes in the default package - I know
people shouldn't be naming their classes "x", but people do
lots of things they shouldn't (and then they want me to maintain
it)... But well, it's just a false positive...

> a better solution would probably been to have used jikes as the
> compiler, and to use its +M option to generate dependency
> information as a side effect of compiling the code.
Ee, if I went to project manager and said "we should use this
and that Java compiler, because it cooperates with this and that
build tool", I don't think she would take it kindly... :-) IMHO
our project's setup is complicated enough without using compiler
and runtime from different providers - how do you ensure it
doesn't break anything?

        Bye
                Vasek