3 ms·
It would seem that one of the JSR 376's key goals is to provide a saner way to manage dependencies than the Java classpath. See also: http://wiki.osgi.org/w/im
by dj-wonk 11y ago
It would seem that one of the JSR 376's key goals is to provide a saner way to manage dependencies than the Java classpath.
See also: http://wiki.osgi.org/w/images/thumb/e/e2/Classpath.jpg/500px-Classpath.jpg http://wiki.osgi.org/w/images/thumb/e/e2/Classpath.jpg/500px...
- needusername 11y agoThey say that but I don't know anybody who actually uses classpath (java -cp). Most people use a custom class loader, container and module system. In addition Oracle cops out of versioning. So I'm not sure who they are targeting.
- acveilleux 11y agoThe folks you work with seem to be more diligent than a lot of enterprise java folks I know. Explicit classpath is useful in deeply silo'd enterprise environment to get around multiple dependencies on incompatible versions of the same 3rd party jars. Often introduced while under the guns and then kept because maintenance dollars go elsewhere.
- HiYaBarbie 11y ago> Most people use a custom class loader, container and module system. Huh? That sounds like a lot of work reinventing the wheel. Could you give me some details on how that's arranged?
- needusername 11y agoThe most extreme example is probably WildFly that has just the JBoss Modules JAR in the class path. That sets up class loaders for the modular service container that in term sets up class loaders for all the deployments. Every Java EE server (even Tomcat) sets up its own class loaders. So does Jenkins/Hudson, Maven, all RCP platforms, even applets. It's really rare to find applications where all the code is in the class path.