Modern Java complains about "raw types" when types such as Class or Enum are used; those should perhaps nowadays be spelled Class<?> and Enum<?>. Would you like a pull request for such a change?

Hi,

I noticed that jitescript fails to build if the dependency on asm-all is replaced by asm-debug-all. Here is the error displayed:

src/main/java/me/qmx/jitescript/MethodDefinition.java:[58,36] error: incompatible types: ArrayList<VisibleAnnotation> cannot be converted to List<AnnotationNode>
src/main/java/me/qmx/jitescript/FieldDefinition.java:[25,34] error: incompatible types: ArrayList<VisibleAnnotation> cannot be converted to List<AnnotationNode>

This error doesn't happen with asm-all because the classes are stripped from the debug symbols and the generic signatures.

Maybe VisibleAnnotation should extend AnnotationNode so the list contains the type expected?

Support for annotating classes, methods, and fields in DSL.

This change only supports 'visible' annotations. Only annotations with RetentionPolicy.RUNTIME will work.

Change to allow access flags to be set on classes with a default of ACC_PUBLIC. The ACC_SUPER access flag is always set.

Other changes:

• Adding child classes
• Default constructor visibility
• Some tests around class/constructor visibility

Hi, I had added ppc64le(Linux on Power) architecture support on travis-ci in the PR and looks like its been successfully added. I believe it is ready for the final review and merge. The travis ci build logs can be verified from the link below. https://travis-ci.com/github/kishorkunal-raj/jitescript/builds/191745974

Reason behind running tests on ppc64le: This package is included in the ppc64le versions of RHEL and Ubuntu - this allows the top of tree to be tested continuously as it is for Intel, making it easier to catch any possible regressions on ppc64le before the distros begin their clones and builds. This reduces the work in integrating this package into future versions of RHEL/Ubuntu.

Please have a look.

Regards, Kishor Kunal Raj

Also, all instance variables except for arity and returns are now final.

Note that in the version I copied over, the class itself is also final. Not the case here.

Followup to a discussion on IRC (freenode, channel `#dynjs).

I have taken on me to kickstart parboiled "1" development again, since it has halted two years ago, and have created grappa.

Basically: you write parsers in Java and create your parser with:

final MyParser parser = Parboiled.createParser(MyParser.class);

This does the following:

• create a ParserClassNode containing the bytecode of MyParser);
• create a name for the new class, since the instance returned is a class inheriting your parser class;
• for each RuleMethod in the ParserClassNode, that is, methods defined in the base class returning a Rule, perform a given number of transformations; those transformations are defined here.

When you have a look at the classes defined here, what they all do (on the byte code copy) is to generate bytecode which is appended/prepended to the existing method bytecode.

And that is done using raw ASM...

Having googled around, I stumbled upon this library when watching a video on YouTube by the author of JRuby mentioning this library; but I don't see how I can use this library to modify existing bytecode?

An example of what I mean is here.

I know I'll have to modify this code one day (when I go Java 7 I want to go indy); but right now, I am looking for a library which can make it easier for me to generate that kind of "bytecode set", and there are many; a lot more such code extracts are available in the enclosing package. Can JiteScript help me here?

The CodeBlock's return property was only set for reference types but not for primitives. This is rather not very consistent and is confusing for people relying on the property to be set.

There might be some greater meaning to this descision but to me it seemed as if this property was simply forgoten for the primitive return opcodes. At least, this surprised me, so I guess it might surprise others, as well.

Bumps junit from 4.8.2 to 4.13.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

I don't know Java well, so I'd just like to leave this as a suggestion, without judgement:

Our static analysis suggests a change at https://github.com/qmx/jitescript/blob/master/src/main/java/me/qmx/jitescript/VisibleAnnotation.java#L34, to change value.getClass() to value.getDeclaredClass(). The former returns some derived class for enums that declare methods, whereas the latter returns the actual enum type.

I'm not sure if that's correct, but it was flagged as an error-prone pattern.

Hey @qmx! I've added a simple DSL block for generating lambdas more easily, mostly because I find the multiple invokedynamic arguments required for lambdas is tough to get my head around.

In a nutshell, lambdas require the following:

• Functional interface type, method, and signature
• Optional specialization of the functional interface method signature
• The number and types of the arguments to capture off the stack
• The method to delegate the lambda to

Using this information, the relevant invokedynamic instruction is created to delegate into the implementation method.

Caveats: The lambda block test (JiteClassTest#testLambda) is only run on Java 8. The test method exits if not running Java 8. I've taken steps to ensure Java 8 isn't required when using jitescript by coding all JDK 8 class names as strings. Is there a better way to manage the test given the JDK version constraint? :S

Examples:

• JiteClassTest#testLambda
• Lambda for partial function application
• Lambda for curried function