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
