harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-2130) DaCapo antlr fails on drlvm
Date Fri, 08 Dec 2006 01:46:22 GMT
On 12/7/06, Stefano Mazzocchi <stefano@apache.org> wrote:
> Vladimir Strigun (JIRA) wrote:
> >     [ http://issues.apache.org/jira/browse/HARMONY-2130?page=comments#action_12456467
]
> >
> > Vladimir Strigun commented on HARMONY-2130:
> > -------------------------------------------
> >
> > Robin,
> >
> > Unfortunately I can't say that I agree with you. Yes, antlr benchmark works correctly
on more that 8 VMs, but the reason that benchmark finished abnormal on DRLVM is antl.jar in
bootclasspath of VM. So, if I correctly understand the behavior of the bench will be the same
on other VM's with antlr.jar bootclasspathed. As far as I can see from build file of Dacapo,
you download antlr sources, patch it (the main point here is removing of System.exit() call
from main method of Tool class), build it and use run Tool class during benchmarking.
> > I've suggested to add additional method to AntlrHarness class that allows to avoid
usage of main() function. In that case benchmark passes on VM with antlr bootclasspathed.
Of course, version check should be done prior to execution.
> >
> > What do you think about it?
>
> I'm sorry, but this argument is defective.
>
> Sun does ship xerces and xalan bootclasspathed and to avoid
> interference, they moved the packages.

Sun may do this, but IBM doesn't. I don't know about Java 5 distros,
but with IBM Java 1.4.2 JREs, the xerces and xalan classes weren't
changed and do cause interference.

-Nathan

>
> If we provide something that our own internal machinery depends on, we
> either shield it and avoids it showing in the userland classloading
> area, or we change the package and make it 'our own' stuff.
>
> Asking any program to adapt to our own behavior (whatever that is and
> for whatever technical reason) is wrong and against basic
> interoperability principles.
>
> *any* program that runs on RI should run, unmodified, on harmony.
> Anything else is a bug and needs to be fixed, somehow.
>
> So, we can be clever and write a classloader that understands who is
> calling and provides 'virtual' classloading zones (but I'm not sure this
> can be made compatible with the java spec) or we bytecode-rewire the
> packages of the libraries we bootclasspath.
>
> Asking others to change is not an option.
>
> --
> Stefano.
>
>

Mime
View raw message