Hello Laurent, thank you for your interest. 2009/1/23 Laurent PETIT <laurent.pe...@gmail.com>
> Hello Gaetan, > > I'm one of the core developers of clojuredev, an open source project whose > goal is to provide clojure support for the Eclipse IDE. > What you say below is interesting, please see what I have noted inline --> > > 2009/1/23 gaetan <gaetan.mor...@gmail.com> > >> >> Hi everybody, >> >> I am working in a software company specialized in Eclipse based >> product development (and member of the Eclipse Fundation). We are very >> interesting in clojure features and we plan to use it in some of our >> products. I am currently working on clojure integration in OSGi >> Bundles in order to embed code in Eclipse plugins. As mentioned in >> some posts the biggest problems is class loading. Indeed in OSGi each >> bundle has its own class loader and class loading is not based on the >> application classpath or on the current thread class loader. >> Consequently, it is very difficult to make clojure work with java code >> and to use OSGi visibility and dependencies system inside clojure. > > > For mere mortals like me, could you explain the problem via an example ? > (I understand there is a problem, I don't exactly understand what it really > is) > > Concerning clojuredev, we provide clojure as a separate plugin, which > exposes everything to plugins that depend on it. > Currently, clojuredev plugin is successful in calling clojure core > functions defined in clojure plugin, as well as loading new functions and > namespaces from clojuredev plugin. > I will try to give an example (I hope it will be understandable). First has you may now in OSGi (and therefor in Eclipse) each bundle declare its dependencies toward others in the MANIFEST.MF file. If you are developing a bundle "a" that needs a class in a bundle "b" you have to update the MANIFEST.MF file of "a" to said that it depends on "b" and "b" has to export the package that contains the class (this information is in the MANIFEST.MF file of b). Under the hood, each bundle has its own class loader that is fully aware of the dependencies and export of the plugin. So in the example above, at runtime the class loader of "a" will be able to use the class loader of "b" (thanks to the dependency declaration) and this one will be able to load the class for an external bundle (thanks to the export declaration). Now if you want to use clojure code in your OSGi instead of java. First you will embed clojure core in a specific bundle called "c". You write a clojure lib in "a" that use another clojure lib in "b". What will happen? To load code of "b" the lib in "a" will use the "use" (or "require") function of clojure core. This function use a specific class loader (called DynamicClassLoader) that use the class path of the bootstrapping thread. However this class path is not aware of the bundles inside the application and so the clojure class loader will not be able to find the lib in "b". Another case is if you want to use clojure code in "a" that use java code in "b". In this case clojure code use the "import" function of clojure core. This function use the Class#forName method that is based on the caller class loader. In this case the caller is clojure core and so its class loader is the class loader of "c". As this class loader as no dependencies toward "b", it will not be able to load the java class. As you can see the problem is a little tricky :-). That's why I think the best way to use clojure in OSGi bundles is to enable clojure to use bundles' class loader, it is flawless and understandable as it mimics java behavior. To do this I use clojure namespaces. In the example above the clojure lib in "a" must have a namespace that start with "a" so the clojure class loader can find and use the class loader of bundle "a" to load its dependencies. > > >> I >> think the best solution is to use bundles class loader inside clojure >> class loading system. I developed a proof of concept that uses a new >> class loader that extends clojure.lang.DynamicClassLoader with bundle >> class loading capability. To know which bundle use to load classes or >> script file the class loader uses the current namespace which has to >> reflect the bundle name (this is the java convention for bundles). In >> order to use this new class loader I had to modified >> clojure.lang.RT#baseLoader and makeClassLoader and >> clojure.lang.core#import. Moreover to test this I made a experimental >> Eclipse Builder that enable AOT compilation of mixed clojure and java >> plugin. So far it seems to work well: clojure and java interact >> seamlessly and it is very fun to interact dynamically with an Eclipse >> instance! >> >> I had some questions to the clojure community: >> * Whether it is possible to overload clojure class loading without >> introducing dependencies in clojure's core? >> * If their are some people interested in this application of clojure? >> (I can made my sources available) > > > We currently don't have made the AOT version of the eclipse builder, so if > you could publish what you've done so far that would be great, because we > could work on it, or it could give us some hints to make our own. > > Is it possible for you to publish it, maybe via the EPL, which seems to be > the 'defacto' Open source license to use when creating code around clojure ? > No problem I will release the code under EPL. However you must be aware that it is a proof of concept and there is a lot of things to fix and re-factor. I just have one question what is the best place to share the code ? > Regards, > > -- > Laurent > > >> Moreover I will made a post on Eclipse E4 project mailing list (work >> on the future of Eclipse) as they are very interested in dynamic >> languages. >> >> BR, >> >> Gaetan >> >> >> > > > > > Cheers, Gaetan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
