Hi Edwin,
First, to make my goal clear: ideally, I'd like to be able to set my
classpath--or specify options to javac, I don't much care which--in such a
way that I can compile an arbitrary class. So here's the experiment I
tried:
- I set xercesImpl.jar, xml-apis.jar and xml-xalan\java\src on my
classpath.
- from xml-xalan\java, I did
javac -sourcepath d:\xml-xalan\java\src -d ./
src\org\apache\xalan\templates\FuncKey.java
Under Sun JDk 1.3.1, this works like a charm. Under 1.4.1, it blows up
with 63 error messages, of the kind indicating that javac is still refusing
to look beyond the JVM's compiled classes if it doesn't have to.
Perhaps there's some way of modifying this solution to enable a Ant to
build Xalan under 1.4; that is a less general problem after all. But, for
me, evidence still indicates that excluding all knowledge of xalan from
javac seems to be the only way to go. So I'll still advocate the solution
we adopted in Xerces for the IBM JDK, which at least solves the specific
problem of an entire build (though of course not the general problem of
building an arbitrary class).
Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
|---------+---------------------------->
| | Edwin Goei |
| | <[EMAIL PROTECTED]>|
| | |
| | 10/07/2002 07:09 |
| | PM |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc: Neil Graham/Toronto/IBM@IBMCA, Gopal Sharma <[EMAIL PROTECTED]>
|
| Subject: Re: can Xalan be compiled under JDK 1.4.x?
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
Edwin Goei wrote:
> [EMAIL PROTECTED] wrote:
>
>> Hi Gopal,
>>
>> Thanks for the suggestions; they both do indeed work.
>>
>> But this still doesn't seem to be a very good situation: To compile a
>> modern version of Xalan, I first need a compiled version of modern
Xalan.
>> i.e., as soon as I make a change which would be incompatible with the
>> current Xalan jar I'm using on the bootclasspath or as the target of the
>> java.endorsed.dirs property, I've got to use an older JDK to build a new
>> jar. Then I can return to 1.4.x and use this new jar for additional
>> compilations/tests.
>>
>> Because of the way Sun JDK's are packaged--with everything including
>> Xalan
>> and the kitchen sink in rt.jar--I've come to the conclusion that no good
>> solution exists on this platform. In JDK's that are packaged with
>> different components in different jars, it'll be possible to exclude the
>> appropriate jars from javac's bootclasspath so that it will be
>> possible to
>> dynamically build entirely new Xerces/Xalan jars without reference to
>> pre-existing ones. It's just unfortunate that Sun JDK's aren't packaged
>> differently.
>>
>> Can anyone else see any workaround? Anybody know whether this is how
Sun
>> JDK's will always be packaged?
>
>
> After reading this thread in xalan-dev, I think I understand the issue.
> I would suggest as a workaround to use the -bootclasspath option of
> javac and prepend the *new* xalan classes before rt.jar.
Actually, after trying it out myself. I believe, what you actually want
is to use the -sourcepath option of javac, along with the -d option.
See for example,
http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/javac.html#searching
for more details. This will cause javac to look for *newer* versions of
the *source* instead of using old precompiled versions.
BTW, I haven't been following this thread and I have noticed other
replies since my last post. I will reply to those separately.
-Edwin
