I don't think disallowing this would be great either. To me the easiest solution would be to simply make package accessible method inhabit a totally different namespace (one for each package). This corresponds much better with people's intuition about package private members, I believe.
The only complication is a package that contains both package private and public (or protected) methods with the same signature. You can make a case that this should be disallowed. Another option would be to use two vtable slots in this case (one public slot and one package slot). Regards, Jeroen > -----Original Message----- > From: jvm-languages@googlegroups.com [mailto:jvm- > langua...@googlegroups.com] On Behalf Of Attila Szegedi > Sent: Friday, November 11, 2011 00:27 > To: jvm-languages@googlegroups.com > Subject: Re: [jvm-l] Package protected and virtual/non-virtual dispatch > > Sorry, I just came across this post now, and couldn't help but wonder: > shouldn't the correct JVM operation here be to refuse to load p2.A with > IncompatibleClassChangeError? > > After all, the source code as such is rejected by the compiler, because > the visibility of Z.foo() was reduced in the subclass A. > > If you trick it into compiling (by removing the "public" modifier from > p1.Z before compiling p2.A, then only recompiling p1.Z with "public" > added back in), I think the JVM should just refuse to load the class > with IncompatibleClassChangeError, isn't that right? > > Attila. > > On Oct 19, 2011, at 4:55 AM, Jeroen Frijters wrote: > > > John Rose wrote: > >> Alex Buckley has been diligently tracking this and dozens of other > >> small defects in previous versions of the spec. The results can be > >> seen in the Java SE 7 Edition of the JVM Specification. This is in > >> JSR 336's Final Release (Annex 3) and at > >> http://download.oracle.com/javase/cmn/spec_index.html. It has a > >> modest little section called "5.4.5 Method overriding", which > >> documents the behavior you are asking about. > > > > Thanks for the link. > > > > Maybe I'm misunderstanding what it says, but I'm thoroughly confused > by HotSpot behavior: > > > > package p1; > > class Z { public void foo() { } } > > > > package p2; > > class A extends Z { void foo() { } } > > > > package p3; > > class C extends A { void foo() { } } > > > > Here A.foo clearly overrides Z.foo and according to my understand of > 5.4.5 C.foo should not override A.foo. > > > > Now the weird part, on HotSpot when C has class file version 51 C.foo > does override A.foo, but for earlier class file versions it doesn't. > > > > It looks to me as if the spec documents the pre-7 HotSpot behavior. > > > > Regards, > > Jeroen > > > > -- > > You received this message because you are subscribed to the Google > Groups "JVM Languages" group. > > To post to this group, send email to jvm-languages@googlegroups.com. > > To unsubscribe from this group, send email to jvm- > languages+unsubscr...@googlegroups.com. > > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > > > > -- > You received this message because you are subscribed to the Google > Groups "JVM Languages" group. > To post to this group, send email to jvm-languages@googlegroups.com. > To unsubscribe from this group, send email to jvm- > languages+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com. To unsubscribe from this group, send email to jvm-languages+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
