Yes, that's basically it. To save ourselves future pain moving to JSR292
or just refactoring our call-path, all the Java-implemented Ruby methods
are bound via generated method handles. So a method on RubyString might
look like this:
@JRubyMethod(name = {"[]", "slice"}, reads = BACKREF, writes = BACKREF)
public IRubyObject op_aref(ThreadContext context, IRubyObject arg1,
IRubyObject arg2) {
The op_aref code will then be bound to Ruby method names "[]" and
"slice", will be marked that it sets and gets the backref variable in
the caller's scope, and will expect to get exactly two arguments,
raising an error otherwise. These method handles are generated during
compilation, before RubyString has been compiled, using ASM to output
bytecode directly. There's another phase that runs after compilation to
generate "populators" that bind to these classes by name (rather than
using Class.forName for everything) and install them in their
appropriate classes.
The advantage this has given us is that since the annotations are used
to generate code, we can just tweak the generator once and never have to
fiddle with the methods themselves. Also, if you want extra arguments to
be passed along, like ThreadContext here, just add them to the signature
and the generated method handle will pass them. Finally...our generated
handles are quite a bit faster than reflected ones.
Jim White wrote:
> We're talking about source-level pre-processing, which is to say
> pre-bytecode.
>
> An example problem is stuff that constructs the classpath which the
> compiler expects to be set before it is called, as with dependency
> managers. Naturally that is a little bit of chicken-and-egg problem if
> your configuration for the dependencies is in the source.
>
> I'm guessing Charlie is doing something so Java code can integrate with
> JRuby source without fussy interfaces-and-staged-build stuff, much like
> the integrated Groovy & Java compilation in groovyc (which does it with
> autogenerated stubs then calling javac).
>
> Jim
>
> Ted Neward wrote:
>
>> Have BCEL or ASM or any of the bytecode toolkits taken up the slack on some
>> of this yet?
>>
>> Ted Neward
>> Java, .NET, XML Services
>> Consulting, Teaching, Speaking, Writing
>> http://www.tedneward.com
>>
>>
>>
>>> -----Original Message-----
>>> From: jvm-languages@googlegroups.com [mailto:jvm-
>>> [EMAIL PROTECTED] On Behalf Of Charles Oliver Nutter
>>> Sent: Sunday, July 20, 2008 12:07 PM
>>> To: jvm-languages@googlegroups.com
>>> Subject: [jvm-l] Annotation processing without Sun dependency
>>>
>>>
>>> Ok, I've got a problem. In JRuby 1.1.3 we started using a compile-time
>>> annotation processor to pre-generate a bunch of code. This has helped
>>> startup time, since before we did this processing at runtime using Java
>>> reflection classes, and just using those classes increased both memory
>>> and startup time.
>>>
>>> But the problem is that in order to an offline annotation processing,
>>> we
>>> need to use Sun-specific APIs for the "apt" tool, and need a reflection
>>> API that doesn't cause/require the classes to be loaded, since the code
>>> we're generating will depend on things that have not been compiled yet.
>>> So we're using the com.sun.mirror classes for the annotation processor
>>> and all the reflection.
>>>
>>> Obviously this means a build-time dependency on a Sun JDK, since
>>> annotation processing has not yet been standardized. This complicates
>>> folks on non-Sun JDKs keeping up with JRuby trunk, since they can't
>>> build it. The dependency does not extend to runtime, however.
>>>
>>> So my questions:
>>>
>>> Is there a third-party annotation processing tool/library we could use
>>> instead?
>>>
>>> - Charlie
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
