On Fri, Oct 8, 2010 at 4:55 PM, Jochen Theodorou <[email protected]> wrote: > Alessio Stalla wrote: > [...] >> >> In fact, I think I managed to reproduce it. I have this structure: >> >> <default package>/ >> Main2.java >> pkg/ >> A.java >> B.java >> >> Main.java has the following main method: >> >> ------------------------ >> public static void main(String[] args) { >> try { >> ClassLoader a = new URLClassLoader(new URL[] { new >> URL("file:///home/alessio/prova1/") }); >> System.out.println("a = " + a); >> a.loadClass("pkg.A"); >> ClassLoader b = new URLClassLoader(new URL[] { new >> URL("file:///home/alessio/prova2/") }, a); >> System.out.println("b = " + b); >> b.loadClass("pkg.B").getMethod("foo").invoke(null); >> } catch(Exception e) { >> e.printStackTrace(); >> } >> } > > in the meantime I did something similar... and got the same result... so it > seems the issue is related to that. Looks like not having package private in > Groovy by default was an even better decision than I always thought of. > > thank you very much... it makes much more sense to me now. > > Especially as I could verify that indeed two class loaders are involved in > the junit test case. So it seems that is the background to this error. > Thanks a lot.
No problem. It has been a nice issue to think about :) In general, I have found that some of the abstractions introduced by javac leak or fall apart in certain corner cases, that are a lot more common when dynamic languages are involved. Peace, Alessio -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
