History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: JRUBY-2750
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Peter K Chan
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
JRuby

JRuby AOT compiler should produce version information

Created: 04/Jul/08 12:03 AM   Updated: 06/Oct/08 11:54 PM
Component/s: Compiler
Affects Version/s: None
Fix Version/s: JRuby 1.1.5

Time Tracking:
Not Specified


 Description  « Hide
Currently, the JRuby AOT compiler does not output any kind of version information in the produced class files. This makes it difficult to debug, if a ruby.rb file, compiled by an earlier AOT compiler to ruby.class, is loaded by a later and incompatible version of the JRuby runtime.

A specific use case from my project: I have some ruby files that are library dependencies (such as optparse.rb or Active Support), and I pre-compile them to be loaded as a lib.jar. Without version information and compatibility check, it will be difficult to determine any runtime error, if I upgrade to a later and incompatible JRuby runtime, while still using the lib.jar compiled by an earlier version.

This may also be useful for generic pre-compilation of popular Ruby libraries, such as active_support.jar or rails.jar, which can then be deployed or released without each user having to pre-compile their own copies (more work will be needed, but compiler version information will be a necessary feature to ensure safe usage of older released compiled JRuby class files).

My suggestion is for the compiler to output its version information in the produced class files. At runtime, the JRuby runtime will consult the version information and check to make sure that the loaded code is compatible with its' own version. If the loaded file is not compatible, an appropriate exception can be thrown (rather then the current way of various Java linkage error with no indication that they are due to JRuby version compatibility).



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Charles Oliver Nutter - 06/Oct/08 10:51 PM
Adding a version number turns out to be a little trickier than I'd hoped, I can't just make it a normal field, because I'd have to load the class to read it. I could probably stuff it into the other metadata for the class, but it's cumbersome and would slow down compiled script loading (since I'd essentially be parsing the class twice).

Peter, would having the logic that loads script classes catch a LinkageError and report a better error message for it be acceptable? Do you have an example of the error you saw?

I will keep looking at how I can embed some data into the class file without adding a lot of overhead.


Peter K Chan - 06/Oct/08 11:48 PM
Providing version information serves the purpose of warning user to recompile scripts and to the runtime about how to provide compatibility. Compatibility is important, but the AOT compiler needs to be stable first, before it makes sense to support several vesions. For now, the real issue is warning the user to recompile scripts.

There needs to be an official policy on the status of AOT compiler support. I am content with no version information in the class file, as long as there is an official statement stating that, so that I don't waste hours figuring out why there is a LinkageError.

As for the actual mechanism, there are several ways that I can think of:

  • Put version in a class field.
  • Put version in the file name (e.g. optparse.jruby2). This could be an issue if defineClass is not available.
  • Have the compiled script depend on a version-specific method (e.g. JRuby.require_version_1_1_6). Perhaps parse the error message for the version dependency.
  • When encountering LInkageError, wrap the message with a hint that scripts may need to be recompiled.

Charles Oliver Nutter - 06/Oct/08 11:54 PM
We will add some kind of version information to compiled scripts. I have a few suggestions from Peter and Eugene Kuleshov on how to do it.