You are viewing an old version of this page. View the current version.
Compare with Current |
View Page History
Rationale
Java deployments increasingly rely on modularity services such as OSGi. In addition, packages such as NetKernel etc would like languages to behave as services. Clojure should behave well in such environments.
Plan
- Fix misfeatures that are broken in the face of modularity
- add-classpath
- all-ns?
- Add features to make Clojure a better language-as-service
Issues
- No standards for modularity of dynamically-generated code
- Most systems focus on the dynamic loading of statically compiled code
Work in Progress
Clojure-contrib modularization
Work-in-progress on the "modules" branch. BUILD IS SUCCESSFUL.
Each major namespace group gets its own module.
Every module depends on a "parent" module that specifies which version of Clojure to depend on, and configuration for compile/test/build.
Library authors can override this on a per-module basis.
The "complete" module includes all other modules as dependencies and can build a clojure-contrib "uberjar."
A full build takes over seven minutes on an 8-core, but individual modules can be built independently.
Java 7 / Jigsaw
Java 7 will NOT include JSR 294 (superpackages) or JSR 277 (Java Module System).
Project Jigsaw is an OpenJDK endeavor. It is "focused narrowly upon the goal of modularizing the JDK," and "will not be an official part
of the Java SE 7 Platform Specification."
Java EE 6
Clojure works fine in Glassfish 3 (a Java EE 6 application server). Dynamic loading, eval, everything works.
OSGi
Clojure does NOT work out-of-the-box in Equinox (OSGi implementation from Eclipse). Loading the clojure.lang.* Java classes works fine,
but initializing the Clojure runtime fails with "java.io.FileNotFoundException: Could not locate clojure/core__init.class or clojure/core.clj on classpath."
The Clojure plugin for Eclipse works around this by using an Eclipse-specific feature called "plugin buddies."