Bug 365463 – JRuby's Ant fails to call javac

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description James Le Cuirot 2011-04-30 22:03:19 UTC]

It is common for javac to be invoked directly through Ant. JRuby makes it possible to do this using Ruby code. For some reason, this isn't working on Gentoo and despite digging quite deep into the issue, I have not been able to determine why.

One package affected by this is dev-ruby/weakling. It provides a Rakefile that invokes Ant but Rake is not to blame as you can also trigger the same error like so.

# jruby -e "require 'ant'; ant.javac :srcdir => 'ext'"
-e:1: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
Compiling 2 source files
org/apache/tools/ant/taskdefs/compilers/CompilerAdapterFactory.java:127:in `getCompiler': org.apache.tools.ant.BuildException: Unable to find a javac compiler; (NativeException)
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK.
It is currently set to "/opt/icedtea6-bin-1.9.7/jre"
	from org/apache/tools/ant/taskdefs/Javac.java:1088:in `compile'
	from org/apache/tools/ant/taskdefs/Javac.java:906:in `execute'
	from org/apache/tools/ant/UnknownElement.java:291:in `execute'
	from sun/reflect/NativeMethodAccessorImpl.java:-2:in `invoke0'
	from sun/reflect/NativeMethodAccessorImpl.java:57:in `invoke'
	from sun/reflect/DelegatingMethodAccessorImpl.java:43:in `invoke'
	from java/lang/reflect/Method.java:616:in `invoke'
	from org/jruby/javasupport/JavaMethod.java:508:in `invokeDirectWithExceptionHandling'
	from /usr/share/jruby/lib/ruby/site_ruby/shared/ant/element.rb:48:in `call'
	from /usr/share/jruby/lib/ruby/site_ruby/shared/ant/ant.rb:144:in `javac'
	from -e:1

It seems that tools.jar is not in the classpath, despite an upstream patch that appears to successfully add it. I have checked the value of $CLASSPATH in the Ruby code just before it tries to invoke javac and it is definitely there. But I have also rebuilt Ant to tell me the value of java.class.path just before the point of failure and that simply returns :. I even tried setting the classpath in other ways. It's like the classpath mysteriously disappears somewhere between the Ruby code and the Java code, despite it all being executed within a single java instance.

I am using jruby-1.5.6 and ant-core-1.8.1. Presumably this works on other distros but it may be worth checking. I'm not going to go that far though as I was only investigating this for graaff.

[Comment 1 Alistair Bush (RETIRED) 2011-05-01 01:29:32 UTC]

This potentially could be caused by how we are currently packaging jruby.

I know of other cases whether the behavior of gentoo-jruby is different to upstream-jruby.   I have attempted (and failed) to discover the cause of these issues, whether by the splitting of dep (upstream jruby jarjar everything into single jar) or the replacement of these deps with system ones.

Either way I couldn't get the thing to work.  jruby ebuild fails on running unit tests that pass when building from direct upstream sources.

This at least was the status from 1.5.2 which was stablised for some ungodly reason.  I don't expect it to have changed tho.

[Comment 2 James Le Cuirot 2011-05-01 09:50:17 UTC]

All the tests were passing when I worked on 1.2 with the help of a couple of patches but those haven't been applied to 1.5. I guess they're no good anymore.

[Comment 3 Hans de Graaff 2011-05-01 16:41:18 UTC]

(In reply to comment #1)

> This at least was the status from 1.5.2 which was stablised for some ungodly
> reason.  I don't expect it to have changed tho.

I'm sure I had something to do with that, since maintaining multiple ruby targets is quite hard when all target's aren't stable.

Looking forward, I think it makes most sense do the following:
- stable 1.5.6 in a couple of weeks time
- work on 1.6 and try to fix these issues there

I'm not sure if it makes a lot of sense to try and fix this in the 1.5 series, given the amount of time already spent on it.

[Comment 4 Alistair Bush (RETIRED) 2011-05-02 06:50:16 UTC]

(In reply to comment #3)
> (In reply to comment #1)
> 
> > This at least was the status from 1.5.2 which was stablised for some ungodly
> > reason.  I don't expect it to have changed tho.
> 
> I'm sure I had something to do with that, since maintaining multiple ruby
> targets is quite hard when all target's aren't stable.
> 

Think it was also required for netbeans and it would have been a shame to delay stabilizing netbeans because of jruby.  I remembered seeing the stable bug and really should of commented on it about what issues were outstanding.

> Looking forward, I think it makes most sense do the following:
> - stable 1.5.6 in a couple of weeks time
> - work on 1.6 and try to fix these issues there
> 
> I'm not sure if it makes a lot of sense to try and fix this in the 1.5 series,
> given the amount of time already spent on it.

Yeah sounds like a good idea :)

[Comment 5 Ralph Sennhauser (RETIRED) 2012-05-29 12:41:16 UTC]

Could this have been triggered by the old launcher not handling spaces in arguments?

Please test with recent jruby.

[Comment 6 James Le Cuirot 2012-06-03 10:28:27 UTC]

I'm a little hazy on this. weakling emerges with jruby now but I think it always did. I seem to recall that graaff was looking to build it a different way. If I run the command I gave in the original post, it still fails but with a Ruby backtrace instead of a Java one, which is potentially helpful. What I also seemingly overlooked back then is the "jre" directory mentioned in the output. That looks like the culprit but what is setting JAVA_HOME to the jre directory and why? That doesn't normally happen, right?

Perhaps JAVA_HOME does not point to the JDK.
It is currently set to "/opt/icedtea6-bin-1.9.7/jre"

[Comment 7 Volkmar W. Pogatzki 2023-07-17 14:18:56 UTC]

JRuby is gone since commit https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-java/jruby?id=4d2320d2211626e2af70cfa8dae5b0bd1faf1541. Closing.