Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: JRuby 1.1.5, JRuby 1.2
-
Fix Version/s: JRuby 1.4
-
Component/s: Java Integration
-
Labels:None
-
Environment:when using a different version of jodatime with buildr
-
Testcase included:yes
-
Number of attachments :
Description
jruby.jar contains a version of joda-time. if an application uses a different version of jodatime, jruby loads the version from jruby.jar first.
an example is a project using buildr and jruby which contains a new version such as 1.6 of joda time as a dependency. the project will not compile if it uses methods that are not in the old version such as
org.joda.time.Duration.standardHours(long);
http://joda-time.sourceforge.net/api-release/org/joda/time/Duration.html
an easy fix would be to move the jodatime classes in jruby from org.joda.time to jruby.org.joda.time for example. this can be done in eclipse in seconds. the patch will be somewhat large ofcourse.
output of buildr package:
–
compiling joda:hello into /home/erlang/joda/hello/target/classes
/home/erlang/joda/hello/src/main/java/Hello.java:4: cannot find symbol
symbol : method standardHours(long)
location: class org.joda.time.Duration
org.joda.time.Duration.standardHours(1l);
^
1 error
–
the attachment is a buildr project that will not compile.
This should be done by jarjar in build.xml, as it is for the org.objectweb.asm classes:
I've done this when incorporating JRuby in a couple of projects and encountered no problems.
Might also want to consider doing this for other jars folded into JRuby, though I'd test first to make sure nothing breaks. jarjar seems to pick up class names represented in strings, but might miss something screwy like MY_PACKAGE_BASE + ".subpackage".