that is not enough info to reproduce the problem. the interesting output
would be to run jruby with:

$ jruby -J-Djruby.debug.loadService=true

which would show how jruby tries to load those bouncy-castle jars whether
they come from the jruby or from the jruby-openssl gem or via jbundler.
apparently they are not loaded at all :(

you are saying it fails on travis but from this I conclude it works on your
machine - is that correct ?

is this by any chance a public/open project ?

Sadly no it's proprietary code, so can't show you the rest of the project, although I could reproduce little sanitised bits of it if you need any specific parts.

The project fails on both my own dev box and Travis in the same way.

I have a ~700 line trace from running jruby -J-Djruby.debug.loadService=true if you want it, there is no mention of bouncy castle or openssl in it though. FWIW the command behaves a bit weirdly, I have to press a key before it starts logging, and it sort of hangs after logging the big trace.

I take the 700 line trace as a next step - maybe it gives some clues what
goes wrong.

Here's the trace: https://gist.github.com/themasterchef/abc3dd3b4696210a2b8f

all I see here is that it ends after loading or while loading the first
gem. it does not even show that jopenssl/load.rb gets loaded.

any minimal Gemfile + Jarfile which produces the error would be helpful,
thanx

Gemfile with most (but not all) of our app's gems stripped out:

source 'https://rubygems.org'

group :development, :test do
  gem 'jbundler', '~> 0.6.4'
  gem 'dotenv-rails', '~> 0.11.1'
  gem "factory_girl_rails", "~> 4.3.0"
  gem "rake" # For the benefit of travis
end

gem 'rails', '~> 4.1.6'
gem "puma", '~> 2.8.2'

platforms :jruby do
  gem 'activerecord-jdbcpostgresql-adapter', '~> 1.3.7'
end

# If I don't leave these in then when I run 'rake spec' it complains about
# resque rake task being missing. Which is interesting because it suggests
# something has managed to load before we hit the DERBoolean error.
gem 'resque', '~> 1.25.2'
gem 'resque-status', '~> 0.4.3'
gem 'resque-scheduler'

group :test do
  gem "rspec-rails", "~> 2.14.0"
  gem 'shoulda-matchers', "~> 2.6.1"
end

Edit: apparently the contents of the Gemfile have almost nothing to do with it! When I used a blank Jarfile the DERBoolean error went away. Suspect something is up in Jbundler and the way that required Java things interact with required (j)ruby things.

Jarfile that caused DERBoolean error (it seems adding even one jar causes the error):

jar 'com.fasterxml.jackson.core:jackson-core', '2.3.0'

Managed to narrow down the error even more. It turns out that using bundle exec rake spec (or just bundle exec rake with the default task set to spec) fails. But bundle exec rspec works!

This is the Rakefile as it stands:

require File.expand_path('../config/application', __FILE__)

Rails.application.load_tasks

task :default => :spec

thanx for the input BUT I was not able to reproduce it and I was NOT able to bundle exec rake spec work in a new scaffolded rails application :(

BUT I remembered I did see something similar before #1549 but can not reproduce this either.

In a new scaffolded Rails app Test::Unit is (or at least was last I used the generator) the default test framework, so 'rake spec' would have no meaning, only 'rake test' would work. But if you installed Rspec-rails and could not do a 'rake spec' then yeah that is concerning

well, bundle exec rspec did run the the scaffolded specs ;) so maybe I did something stupid along the way or maybe it is even related to your problem (just showing it differently) or something else ;)

ok - a clean start again and I got the problem reproduced. it is jbundler and rspec somehow forking/spawning the rspec command.

as workaround add

ENV["JARS_NO_REQUIRE"] = 'false'

to your spec/spec_helper.rb

will fix on jar-dependencies (used by jbundler to require jars)

@themasterchef should be fixed with jbundler-0.7.0

Cool - the spec_helper workaround you posted above is working nicely in the meantime.