[3315] in java-interest
Re: Java Compiler
daemon@ATHENA.MIT.EDU (Arthur van Hoff)
Tue Nov 7 15:51:49 1995
Date: Tue, 7 Nov 1995 09:32:54 -0800
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
To: java-interest@java.Eng.Sun.COM
Hi Steve,
> I am hacking the java compiler (in beta) to accept standard ByteArrayStreams
> as input and output. The output side is trivial. I am having problems with
> theinput side. It seems that the way BatchEnvironment is setup in the compiler
> (and the Environment part of the parser) is to associate an env with a file
> instance. If I overload this behavior and feed both the environment and parser a
> ByteArrayInputStream things go fine until I compile. However the SourceClass
> (which does the actual compile) wants to cast the associated environment object
> (gotten through Object>>getSource I guess) to File. This gives an invalid
> class cast exception. So my question is, given the non-existence of documentation
> on any of these classes.. what is the best way to take an inputstream and
> generate byte-codes? Thanks in advance.
I don't know what sources your stuff is based on since we haven't release the
beta sources yet, so it is hard to answer this question.
Anyway, the classes in sun.tools.javac for the front end of a file oriented
compiler. It was not designed to compile from straight input streams, so you
are likely to run into some problems. What you should do instead is create
a seperate package that defines its own Environment subclass that defines
all its own source class representation. If you get it to work with minor
modifications to the wun.tools.javac package, then send me the changes and
we'll add them our sources.
Have fun,
Arthur van Hoff
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
