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

[Remi Forax]

On 07/07/2013 07:30 PM, Charles Oliver Nutter wrote:
> 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).

I don't think the whole jsr292-backport needs to be pushed to maven,
you and others only need the jsr292-mock.

Yes, the jsr292-mock doesn't change often, it change once by release,
so there is one version for java 7 and one version for java 8
(Java 8 adds the MethodHandleInfo API, the way to crack constant method 
handles).

I don't know how you generate your mock, but given the number of 
classses/interfaces
in java.lang.invoke, I've not done this job by hand but use a script 
that take a valid rt.jar and
extract the JSR 292 API description from it and recreate a jar using ASM.

Given that there is no need to bundle the backport with the jsr292-mock, 
I propose you something,
you create a project on github under your name, you give me the right to 
push the code
(I will create a textual representation of the API so you will be able 
to re-create the jar without
having the right rt.jar available) and after you are free to do what you 
want with it :)

>
> - Charlie

cheers,
Rémi