Hi

 

I've developed two "impossible" tests, which shows "fake" circularity errors. One test is more simple and use SecurityManager. The other is a bit more complex and uses custom ClassLoader. You can find them in attachment.

 

Thanks.

Pavel Afremov



On 10/17/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
The scenario I described earlier is impossible. Resolution of any class
referenced in some other class is performed by class loader, which loaded
that other class. So, no chance to load "A" and referencing class loader
(UCL) with this UCL.

Sorry for confusion.

Regards,
   Pavel.

P.S. Still there are concerns why lazy resolution should be supported by
JITs. But it is absolutely another story.

On 10/17/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
>
> IMO we shall be between BEA and SUN: to work if both RI work, to fail if
> both RI fail and discuss each test in details if only one RI passes.
>
> On 10/17/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> >
> > On Friday 13 October 2006 08:04 Alexey Varlamov wrote:
> > > I'm curious, if we enable "controlled" recursion in classloading -
> > > will it resolve this kind of issues completely? I'm pretty sure it
> > > would resolve at least some scenarios - like the one Pavel described
> > > for gc.Finalizers or a case of classloading initiated within
> > > SecurityManager.checkPermission() which we also faced not once.
> > > "Controlled" recursion here means counting depth of recursion and
> > > allowing at least 1 recursive iteration. I've seen some tricks in
> > > URLClassLoader which assume such ability, but they do not work with
> > > DRLVM.
> >
> > I think it is different. URLClassLoader is system class which is loaded
> by
> > bootstrap, so no recursion happens for classes which it itself requires
> to
> > be
> > loaded when it is being compiled.
> >
> > > For the pure user code scenario Pavel suggested above, there may be
> > > some nuances leading to truly endless recursion, but still we need to
> > > look at particular test first.
> >
> > It is not endless but it is definitely more than 1 level deep. If user
> > sets up
> > his own class loaders, compiling them may trigger loading some of the
> user
> > classes which are in turn loaded by class loaders set up by user. Shall
> we
> > then throw "NoClassDefFoundError: Class loading recursion limit reached.
> > Please rewrite your code"? :)
> >
> > --
> > Gregory Shimansky, Intel Middleware Products Division
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Mikhail Fursov
>
>


Reply via email to