maybe we need some option to not load any jars

[kares]

... to allow users to suply BC jars from somewhere in the CP

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/5075042-maybe-we-need-some-option-to-not-load-any-jars?utm_campaign=plugin&utm_content=tracker%2F136995&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F136995&utm_medium=issues&utm_source=github).

[jeffgran]

👍

[camlow325]

👍 In Puppet Labs' Puppet Server product, we have this same need - to supply our own newer BC jar because we have other code in our app that needs a newer version than what is bundled in JRuby by default. We're currently working around this by explicitly requiring 'jar-dependencies' and setting the JARS_NO_REQUIRE environment variable to "true" since later jopenssl versions don't require 'jar-dependencies' automatically. We'd like to have a more direct way to specify that jars not get loaded which doesn't involve having to exercise 'jar-dependencies' directly. What actually does the jar loading is an implementation detail that we don't really care about directly as we're mostly concerned with just turning it off.

[mkristian]

jar-dependencies should be used to load the jars if the gem is available -
it comes as default gem with jruby-1.7.16+ or so. otherwise the control of
those jars depends on whether I require 'jar-dependencies' before
loading jopenssl or not.

[kares]

think it makes sense even with jar-dependencies around, since jruby-openssl is kind of a must gem in all thinkable (and non-thinkable) use-cases due how the Ruby the eco-system relies on require 'openssl'

actually have an embed use-case of my own starting several Rubies (JRuby is custom built and gems are packed up for isolation) ... lately I found myself wanting to experiment with a custom built BC jar. think I'll go for a (unofficial) -Djruby.openssl.load.jars=false system property

[mkristian]

jar-dependencies already has a way to pick jar versions and the next release will have a way to tell not to load jars - i.e. decalre them provided. my point here is not so much the extra system property but that the gem ignores jar-dependencies when the gem is available (like via jruby itself). and with 9k there will be a similar situation with snakeyaml jar which is used for psych (via require 'yaml') so we need a common way to load or not to load such jars. dito with jline-2.11jar from readline.

[kares]

my point here is not so much the extra system property but that the gem ignores jar-dependencies when the gem is available (like via jruby itself).

we decided previously not to load jar-dependencies explicitly since that is something the user should do, so I guess that is what you're referring to (otherwise we're using it when it's already loaded).

and with 9k there will be a similar situation with snakeyaml jar which is used for psych (via require 'yaml') so we need a common way to load or not to load such jars. dito with jline-2.11jar from readline.

understand the concern to have a common API ... and we do have a great one (jar-dependencies) but I'm against forcing a require 'jar_dependencies' on require 'openssl' the user should be smart enough to do so when he's about to start changing which .jars to use

[mkristian]

well, let's wait until not requiring jar-dependencies really loads two different version of BC into the jruby-classloader.

FYI readline and psych do require jar-dependencies before loading their jars. with Jars.lock you can just declare you jars there and on first require_jar it loads all those jars or/and marks them as "loaded". so I guess I understood the decision differently - regarding the post_install hook when installing jars. but never mind - I will keep my mouth shut since I expressed my point already.

BTW at lookout we have an application which shares quite big number of jar between a java application which launches a rack application sharing basically half the dropwizards framework. jar-dependencies will allow to avoid jar with different version in the same classloader hierarchy.