tag:blogger.com,1999:blog-18772002.post7314596262499164018..comments2023-12-06T19:00:46.094+00:00Comments on OSGi Blog: iJAM, Formalized Class LoadingJürgen Alberthttp://www.blogger.com/profile/02725834158183495837noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-18772002.post-1938527783207854112007-11-05T08:56:00.000+00:002007-11-05T08:56:00.000+00:00Looking further I saw that the example code shows ...Looking further I saw that the example code shows that java.* and javax.* are coming from the parent.<BR/><BR/>This will have very interesting effects because javax.xml requires the use of org.xml.sax, where does that one come from?<BR/><BR/>In OSGi, the framework must set up export statements for the runtime. This allows packages to come from the boot classpath but it also allows these packagesPeter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-36104617802328366012007-11-05T08:50:00.000+00:002007-11-05T08:50:00.000+00:00You are right that they search first in the "Java'...You are right that they search first in the "Java's core library", I missed that. <BR/><BR/>1. The Java core library is not defined in the paper. Is this everything rt.jar? Everything that starts with java.* and javax.*? Extension libraries? For a formal paper, this is very undefined. And one of the key things with a module system is to be able to override javax.* packages.<BR/><BR/>2. I do not Peter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-18201542439348314042007-11-01T12:01:00.000+00:002007-11-01T12:01:00.000+00:00I'm a bit puzzled by your comment"Therefore the pr...I'm a bit puzzled by your comment<BR/><BR/>"Therefore the proposal to first<BR/>search for all classes in the<BR/>module first is clearly wrong, <BR/>any class in java.* must come <BR/>from the system class loader."<BR/><BR/>I do not find such a statement in<BR/>the paper. - Especially in section<BR/>"3.1 Class definition lookup<BR/>functions" they clearly state, <BR/>that they fullfill the Unknownhttps://www.blogger.com/profile/09062891360187112325noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-55251257139459551992007-10-18T12:13:00.000+00:002007-10-18T12:13:00.000+00:00I am not sure if Java developers dismiss this loca...I am not sure if Java developers dismiss this local first strategy out of hand immediately. The JSR 277 strategy is slightly, but not much better. I think it is the siren song of simplicity.<BR/><BR/>Kind regards,<BR/><BR/> Peter KriensPeter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-22345418929364180542007-10-18T06:37:00.000+00:002007-10-18T06:37:00.000+00:00The JBI specification, back in 2005, already inclu...The <A HREF="http://jcp.org/en/jsr/detail?id=208" REL="nofollow">JBI specification</A>, back in 2005, already included support for selecting between parent-first or self-first class loading strategies. Parameterization of boot-classloading was also included in the spec. A JBI runtime can also be viewed as a kind of service component container, not as flexible as OSGi class loading mechanisms but Unknownhttps://www.blogger.com/profile/10980462180960275989noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-20331071250619079392007-10-17T21:40:00.000+00:002007-10-17T21:40:00.000+00:00When I saw iJAM pop up in the InfoQ feed in my RSS...When I saw iJAM pop up in the InfoQ feed in my RSS reader I of course went over and had a quick look. As soon as I realised that they were proposing self-first I dismissed it out of hand. That might have been harsh, but it seems like such a simple and obvious thing to get wrong that I wouldn't be surprised if other Java developers dismiss it in a similar way.<BR/><BR/>I backed away pretty Chris Brindhttps://www.blogger.com/profile/15060997991535798622noreply@blogger.com