Dennis is right, these classes have snuck into jsk-platform.jar, they're not in there in Jini2.1
Because these classes aren't preferred, they'll be resolved in the application loader, simply because they're present, annotated or not. ----- Original message ----- > Hi Dennis: > > I’m not sure I follow you - why would they not be annotated? > jsk-platform goes in the application’s class loader, so either it’s > annotated with a CodebaseAccessClassLoader or with the java.rmi.codebase > property. > > Are you sure you’re not thinking of jsk-policy.jar? That normally goes > “one level above” the application’s class path (since it has to control > the security), so wouldn’t get a codebase annotation. But that jar only > contains the policy provider. > > Cheers, > > Greg Trasuk > > On Apr 26, 2014, at 5:21 PM, Dennis Reedy <dennis.re...@gmail.com> wrote: > > > > > On Apr 26, 2014, at 254PM, tras...@stratuscom.com wrote: > > > > > What is the rationale for inclusion/ exclusion ? > > > > Classes that are loaded by the system classloader never get annotated > > with a codebase. These classses were in jsk-platform.jar. The class in > > question are the net.jini.lookup classes, they are service attributes: > > > > net/jini/lookup/entry/Address.class > > net/jini/lookup/entry/AddressBean.class > > net/jini/lookup/entry/Comment.class > > net/jini/lookup/entry/CommentBean.class > > net/jini/lookup/entry/EntryBean.class > > > > These need to be in jdk-dl.jar (which they were, but they would never > > have a codebase since they were loaded by the system classloader). > > Peter asked me to help him modularizing qa_refactor, this was > > something I spotted. > > > > Dennis >
