jsr292-mock in Maven; coro-mock, unsafe-mock available

[Charles Oliver Nutter]

jsr292-mock:

Ok Rémi, it's decision time :-)

We *need* to get jsr292-mock into maven somehow for JRuby's new build,
so we don't have to version the binary anymore. We'd be happy to help
set up the maven pom.xml AND get a groupId set up via sonatype's maven
service, or we could just start pushing the artifact under a groupId
we own (com.headius or org.jruby). Ideally we'd agree between all
users where to put it and handle (as a team) getting artifacts pushed.

I'm right in thinking this does not change often, right? Unless
there's visible API changes in 8, the same artifact will probably get
pushed once and not change for a long time.

It's up to you (Rémi) and other users whether we should also push the
jsr292-backport to maven. We're not using it in JRuby right now.

unsafe-mock and coro-mock:

I have pushed two new artifacts to maven: com.headius.unsafe-mock and
com.headius.coro-mock.

unsafe-mock is basically just JDK8's Unsafe.java in artifact form. You
would set up your build to fetch it, stick it into bootclasspath, and
compile. The intent is to provide a full Unsafe API for compilation
only; you must detect in your own code whether certain methods are
actually available at runtime. We created this artifact because we use
the new JDK8 "fences" API (when available) for our Ruby instance
variable tables, but did not want to require JDK8 to build JRuby.

coro-mock is a mock of the latest coroutine API from Lukas, provided
in artifact form for the same reason. Since the API does not exist in
any release JDK, just adding to classpath/dependencies will allow
compiling against it. We use it for the Fiber (microthread) library in
JRuby (though I'd bet coro does not work anymore...still need to get a
JSR going for that).

- Charlie