You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Stefano Mazzocchi <st...@apache.org> on 2006/12/07 19:32:04 UTC
Re: [jira] Commented: (HARMONY-2130) DaCapo antlr fails on drlvm
Robin Garner (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/HARMONY-2130?page=comments#action_12456374 ]
>
> Robin Garner commented on HARMONY-2130:
> ---------------------------------------
>
> Hi Vladimir,
>
> I'll double check with Steve when I see him tomorrow, but my recollection
> is that we decided that since the benchmark works correctly on 8 or more
> other
> VMs, that the problem is with DRLVM or the Harmony classlib, not with
> DaCapo. Maybe we could add an antlr.jar in the same way as we provide
> xalan.jar.
>
> As far as we can tell, this problem would affect anyone running a version
> of antlr other than 2.7.5.
This is actually a good point, harmony's own internal classes shouldn't
be exposed to the userland classloading space or we'll be in a heap of
trouble later.
Thoughts?
--
Stefano.
Re: [jira] Commented: (HARMONY-2130) DaCapo antlr fails on drlvm
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Stefano Mazzocchi wrote:
> Stepan Mishura wrote:
>> On 12/8/06, Geir Magnusson Jr. wrote:
>>>
>>> We've talked about this before because we knew we'd run into the
>>> problem. I'll see if I can remember what we concluded...
>>>
>>> geir
>>>
>> See[1] - we talked about two approaches: repackaging and 'dedicated class
>> loader' and as I understand we didn't make any decision.
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/%3c6e47b64f0604110115l31496ffflc9bba19bc88756ac@mail.gmail.com%3e
>
> repackaging is doable, but it's a pain in the neck, especially when
> modularity is in place. I would go for the dedicated classloader.
>
Yea, but the repackaging is actually a relatively simple solution to try
first if the classloader solution gets gnarly simply because the only
code in the universe that will be using the class
o.a.h.repkg.org.apache.jakarta.bcel.Foo
will be us. It's a hack, but seems simple and straightforward and
lacking in "magic" that could create nasty bugs or be confusing for
difficult debugging situation.
Lots of options here...
geir
Re: [jira] Commented: (HARMONY-2130) DaCapo antlr fails on drlvm
Posted by Stefano Mazzocchi <st...@apache.org>.
Stepan Mishura wrote:
> On 12/8/06, Geir Magnusson Jr. wrote:
>>
>>
>>
>> Stefano Mazzocchi wrote:
>> > Robin Garner (JIRA) wrote:
>> >> [
>> http://issues.apache.org/jira/browse/HARMONY-2130?page=comments#action_12456374]
>>
>> >>
>> >> Robin Garner commented on HARMONY-2130:
>> >> ---------------------------------------
>> >>
>> >> Hi Vladimir,
>> >>
>> >> I'll double check with Steve when I see him tomorrow, but my
>> recollection
>> >> is that we decided that since the benchmark works correctly on 8 or
>> more
>> >> other
>> >> VMs, that the problem is with DRLVM or the Harmony classlib, not with
>> >> DaCapo. Maybe we could add an antlr.jar in the same way as we provide
>> >> xalan.jar.
>> >>
>> >> As far as we can tell, this problem would affect anyone running a
>> version
>> >> of antlr other than 2.7.5.
>> >
>> > This is actually a good point, harmony's own internal classes shouldn't
>> > be exposed to the userland classloading space or we'll be in a heap of
>> > trouble later.
>> >
>> > Thoughts?
>>
>> We've talked about this before because we knew we'd run into the
>> problem. I'll see if I can remember what we concluded...
>>
>> geir
>>
>
> See[1] - we talked about two approaches: repackaging and 'dedicated class
> loader' and as I understand we didn't make any decision.
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/%3c6e47b64f0604110115l31496ffflc9bba19bc88756ac@mail.gmail.com%3e
repackaging is doable, but it's a pain in the neck, especially when
modularity is in place. I would go for the dedicated classloader.
--
Stefano.
Re: [jira] Commented: (HARMONY-2130) DaCapo antlr fails on drlvm
Posted by Stepan Mishura <st...@gmail.com>.
On 12/8/06, Geir Magnusson Jr. wrote:
>
>
>
> Stefano Mazzocchi wrote:
> > Robin Garner (JIRA) wrote:
> >> [
> http://issues.apache.org/jira/browse/HARMONY-2130?page=comments#action_12456374]
> >>
> >> Robin Garner commented on HARMONY-2130:
> >> ---------------------------------------
> >>
> >> Hi Vladimir,
> >>
> >> I'll double check with Steve when I see him tomorrow, but my
> recollection
> >> is that we decided that since the benchmark works correctly on 8 or
> more
> >> other
> >> VMs, that the problem is with DRLVM or the Harmony classlib, not with
> >> DaCapo. Maybe we could add an antlr.jar in the same way as we provide
> >> xalan.jar.
> >>
> >> As far as we can tell, this problem would affect anyone running a
> version
> >> of antlr other than 2.7.5.
> >
> > This is actually a good point, harmony's own internal classes shouldn't
> > be exposed to the userland classloading space or we'll be in a heap of
> > trouble later.
> >
> > Thoughts?
>
> We've talked about this before because we knew we'd run into the
> problem. I'll see if I can remember what we concluded...
>
> geir
>
See[1] - we talked about two approaches: repackaging and 'dedicated class
loader' and as I understand we didn't make any decision.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/%3c6e47b64f0604110115l31496ffflc9bba19bc88756ac@mail.gmail.com%3e
Thanks,
Stepan Mishura
Intel Enterprise Solutions Software Division
Re: [jira] Commented: (HARMONY-2130) DaCapo antlr fails on drlvm
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Stefano Mazzocchi wrote:
> Robin Garner (JIRA) wrote:
>> [ http://issues.apache.org/jira/browse/HARMONY-2130?page=comments#action_12456374 ]
>>
>> Robin Garner commented on HARMONY-2130:
>> ---------------------------------------
>>
>> Hi Vladimir,
>>
>> I'll double check with Steve when I see him tomorrow, but my recollection
>> is that we decided that since the benchmark works correctly on 8 or more
>> other
>> VMs, that the problem is with DRLVM or the Harmony classlib, not with
>> DaCapo. Maybe we could add an antlr.jar in the same way as we provide
>> xalan.jar.
>>
>> As far as we can tell, this problem would affect anyone running a version
>> of antlr other than 2.7.5.
>
> This is actually a good point, harmony's own internal classes shouldn't
> be exposed to the userland classloading space or we'll be in a heap of
> trouble later.
>
> Thoughts?
We've talked about this before because we knew we'd run into the
problem. I'll see if I can remember what we concluded...
geir