On Mon, Jul 13, 2009 at 8:40 PM, Stuart Sierra<the.stuart.sie...@gmail.com> wrote: > > Hi folks, > I agreed to talk about Clojure at Philly Lambda on July 21st. I'm > working on a presentation about modularity -- packaging, library > management, ClassLoaders, that sort of thing. I want to cover some of > the popular library managers out there (Rubygems, CPAN) and what it's > like on the Java side (Maven, Ivy). I especially want to look at the > Java module-loading frameworks like OSGI and Java EE. > > So I'm asking for suggestions of things you think I should research, > especially any Clojure integration stuff that people are working on. >
Note: I wrote recently some other rather lengthy mails related to the topic: [1], and to a lesser degree [2] and [3], the contents of which are only partially reproduced here. They might provide some additional food for thought. IMHO classloaders et al. and the associated practices are a huge advantage that the JVM platform has over most of the other language ecosystems out there. It sounds very obscure and the advantage is usually lost on small projects that don't have a lot of dependencies, and therefore not a lot to manage. But as soon as you really start to leverage the ecosystem of libraries around the JVM, the benefits of the classloading mechanisms start to show. I would go as far as to say that the strong JVM ecosystem is only possible because of these mechanisms and how they are exposed. Because if you don't have the possibility to reuse code in a painfree manner, then there's not lot of incentive to actually make your code reusable. I'm used to Java development with Maven, Ivy and/or any of the major IDEs, where all the dependencies are managed and configured per project (in a textfile that's checked into your SCM). I was pretty puzzled when I tried to have a similar setup in Python and it wasn't obvious how to do it nor could I find a lot of material on how to achieve it (for Python the keywords are zc.buildout and virtualenv. Also note that the criticism applies to a lot of languages, not just Python). In the 'standard' configuration or practice, dependencies are installed into a system wide PATH (very bad), or at least a user wide PATH (still quite bad). This gets you very quickly into trouble as it's basically not possible to switch back and forth between code that depends on different versions of the same library, because the different versions of the same library cannot coexist. That makes your environment extremely fragile, as you cannot check all your configuration into your SCM. That means that there's some manual configuration necessary to setup a development environment specific to a certain version of the code (You cannot just switch between the release branch to fix some bugs and your development branch which depends on another version of the dependency). In Java you have that problem potentially as well, but you never see it advocated to drop some jar into JAVA_HOME/lib, which would be the equivalent. But so far we still have only one single classpath at runtime. What if you have several levels of dependencies (favorite example: Hibernate)? If you're using a library X that depends on library Y and your code depends on Y but in a newer version, then you're out of luck with a global path. You can only hope that Y v2 is backwards compatible with v1 and that you can replace it safely. What if you have two commercial dependencies that both depend on Y but in different versions, and only guarantee their SLAs with the certified versions of the dependencies? Checkmate. This is where OSGi starts to shine. You can have multiple versions of the same dependencies at runtime (that's arguably only one thing that OSGi does, and the rest is very interesting as well). For more examples, including runtime manipulation of the classpath for code reloading while in the REPL, check [1]. Also some sophisticated technologies that deal with bytecode transformation have been built on the foundations of classloaders and the JVM bytecode format. Aspect oriented programming (AspectJ), code coverage tools (EMMA), transaction & clustering systems (e.g. Terracotta [2]), Profilers (probably all of them), etc. all hook into the classloading mechanism (unless they are transforming ahead of time on the classfiles only). Before the 1.5 release of the JVM, classloaders were the only hook point, now you can write against JVMTI [4] and supply an agent to the runtime to transform the code, but the basic mechanism is still the same. All the topics you mentioned for your talk are on my plate. I assume that it's going to be increasingly important for all languages hosted on the JVM to have a good integration story, just to be able to leverage the vast amounts of code available. Unfortunately, I don't have anything to show for (yet) in Clojure. But I'm very interested in the discussion. I know at least the state of the JVM regarding the mentioned technologies reasonably well, so if you have more concrete questions, just shout. Hope that the above helps in some way for your talk... Cheers, Daniel [1] http://groups.google.com/group/clojure/browse_thread/thread/6198db7d82610293/4735838f330df3d6?hl=en&q=#4735838f330df3d6 [2] http://groups.google.com/group/clojure/browse_thread/thread/417ba3d62f5137e4/70a25aa89e1ddfda?hl=en&q=#45a6c00c47483046 [3] http://groups.google.com/group/clojure/browse_thread/thread/46a3f30fb3d2807b/895b02b26241305e?hl=en&q=#895b02b26241305e [4] http://java.sun.com/developer/technicalArticles/J2SE/jvm_ti/ --~--~---------~--~----~------------~-------~--~----~ 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 Note that posts from new members are moderated - please be patient with your first post. 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 -~----------~----~----~----~------~----~------~--~---
