You can clone with
The target is Ruboto, but most environments don't need truffle.
Is space the problem? Or something else?
Are you looking for a way to build a jar without the Truffle classes? That should be easy enough to do in the source code, but I don't know a lot about how to conditionally include or exclude classes in Maven.
You could also just literally remove everything under org.jruby.truffle from a jar file and it should not cause any problems until you try to use a Truffle feature. If it does I can correct that.
What is Truffle in general? It's described on the wiki https://github.com/jruby/jruby/wiki/Truffle. Or are you asking what I mean by 'a Truffle feature'? I mean a feature that uses the Truffle library, and the Truffle backend in JRuby.
Truffle is already managed as a normal dependency for building things like jruby-core, but the Truffle backend, the bit in JRuby that uses Truffle, isn't a separate library. It's going to involve some (carefully reviewed and checked for time and space regression) changes to the rest of JRuby, so it's not a separate project.
Hi @chrisseaton !
The size of the distribution is an issue. Also the number of methods in the distribution.
We are currently removing classes from the jruby-jars jars before adding them to Ruboto packages. This has worked OK until now.
With the org.jruby.truffle included, the jruby-core.jar has over 65535 methods, which is currently the limit for an Android package.
Just removing the org.jruby.truffle package results in a load error on org.jruby.Ruby which references the org.jruby.truffle package directly.
We would like to continue to use the binary distribution to leverage as much of the upstream JRuby packaging as possible. If this is not possible, we must resort to package form the JRuby source code, but this is undesirable since we would need another distribution channel for these packages. We use the jruby-jars.gem now, which works very well.
My main idea now is to continue to offer getTruffleBridge in org.jruby.Ruby, but let it return a java.lang.Object which clients would need to cast to org.jruby.truffle.JRubyTruffleBridge.
Do we need an instance of JRubyTruffleBridge for each JRuby runtime? If not, we should get it from a factory inside the org.jruby.truffle package. If an instance is needed per JRuby runtime, we could still get it from a factory in the org.jruby.truffle package. We would just have to supply the runtime when getting the instance.
I would like some input from headius/enebo on how we should organise this. I think there are many parts of JRuby that we should be able to not activate at runtime, and we should be able to remove them from the distribution for uses cases that don't need them. Last I talked to enebo he mentioned that that modularisation was a key goal for JRuby 9000.
@donv Ah of course, Ruby won't work if the class doesn't exist at all. I will take a look at this and make it safe to remove the class entirely - probably via making the bridge an interface that becomes the only class you leave in. I'll get back to you soon.
@chrisseaton nice! Being able to build JRuby normally and then just remove the org.jruby.truffle package would be ideal.
As of 998161f you can now remove all the Truffle classes without problem. There is a single stub interface (a handful of methods) in the org.jruby package that stays.
You can then remove Truffle from any JRuby jar:
zip -d jruby.jar org/jruby/truffle/*
If you use the complete jar you'll probably also want to:
zip -d jruby.jar com/oracle/truffle/*
If you then attempt to use a Truffle feature from that jar you'll get a UnsupportedOperationException that says Truffle has been removed.
Try that out and let me know if that's enough for you.