Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limitations reflection apis #486

Open
CoenRijsdijk opened this issue Dec 9, 2020 · 10 comments
Open

Limitations reflection apis #486

CoenRijsdijk opened this issue Dec 9, 2020 · 10 comments

Comments

@CoenRijsdijk
Copy link
Contributor

CoenRijsdijk commented Dec 9, 2020

Related to #344
We are currently working on further implementing LibGDX in our backend. LibGdx uses reflection, arrays and generics together.

We ran into some problems about missing methods, but we could implement them by ourselves. Refers to commit: squins@464f287

A issue research branch is available where we researched this: https://github.com/squins/Bytecoder/tree/libgdx-reflection-requirements

We encountered some missing methods and collected them in a main class.

How hard would it be to implement them?

We have some questions about TClass:

  • why is @EmulatedByRuntime used with getName, does this have to do with the AOT compiler?
  • why is @EmulatedByRuntime not used for getComponentName?

Could you document Bytecoder annotations, for example @EmulatedByRuntime, to understand how to adapt with Bytecoder?

@CoenRijsdijk CoenRijsdijk changed the title Limitations Class and (Object) Limitations reflection apis Dec 17, 2020
@mirkosertic
Copy link
Owner

mirkosertic commented Jan 4, 2021

  • Reflective field access can be implemented, see Implement reflection API for class and instance fields #344
  • Typed arrays are tricky, and are also not supported by the Bytecoder runtime. Internally a String[] is treatened as Object[],and no further type checking is processed
  • Annotations will maybe never be supported for reflective access.

My bet is the libGDX JSON unmarshaller depends a lot on Reflection API. So we either have to support the full reflection API, replace the unmarshaller, or provide a custom implementation replacing ClassReflection and ArrayReflection on a per project basis, with hard coded classes etc. Maybe this can be done by a code generator.

@mirkosertic
Copy link
Owner

Good news! I've merged the first implementation of reflection API support for the Bytecoder JavaScript backend. Please take a look at https://github.com/mirkosertic/Bytecoder/blob/master/core/src/test/java/de/mirkosertic/bytecoder/core/ReflectionTest.java to see the supported APIs and usecases.

@CoenRijsdijk
Copy link
Contributor Author

CoenRijsdijk commented Jan 13, 2021

@mirkosertic Great! Thanks a lot!

If I want to run the ReflectionTest, what is the best way to do this?
What I tried earlier:

  • mvn test -Dtest=ReflectionTest, I waited for 10 minutes and it keeps giving me compile feedback in the output screen, so how to run it properly?
  • Just run the test, but since we are using Java 8, when we imported Bytecoder, an error appears:

image

would it be solved if we use java 14/15?

@mirkosertic
Copy link
Owner

I am using OpenJDK8 here, IntelliJ as IDE. Basically rebuild the project and run the ReflectionTest class should do the trick.
Please make sure the jaba8-compile Maven profile is active. The mentioned error is maybe caused by other active profiles that add the compiler flags, which are only supported in Java9+

@keesvandieren
Copy link
Contributor

Hi Mirko, thanks for the work you've done! Really huge amount 👍

We have tried it out in our branch, see: https://github.com/squins/Bytecoder/tree/issue-research

Somehow the ReflectionTest is passing, but in our Main class it is not working. Maybe we have something wrongly configured in bytecoder-maven-plugin in the pom.xml?

@mirkosertic
Copy link
Owner

Hey!

I investigated your example, and I see the problem!

The ATO compiler does currently only include fields in the reflection field list which are statically referenced somewhere in the scanned dependency tree of linked classes. Because "staticField" is only referenced by reflection, and not by explicit JVM bytecode instructions, it is not included in the list of linked fields, and hence not included into the generated reflection metadata.

@mirkosertic
Copy link
Owner

I've pushed some fixes to the master branch. Would you please rebase your branch and give it a try? Also, please add the reflection configuration file bytecoder-reflection.json to the root of your classpath (src/main/resources) with the following content:

{
  "com.example.Main$BaseClass": {
    "enableClassForName": true
  },
  "com.example.Main$ReflectionTarget": {
    "enableClassForName": true
  },
  "com.example.MyClassWithField": {
    "enableClassForName": true
  }
}

@CoenRijsdijk
Copy link
Contributor Author

CoenRijsdijk commented Jan 26, 2021

Thanks! It works fine!

Unfortunately I forgot to report this, we can fix it locally ofcourse (not the right way), but could you implement it next release?
image

@CoenRijsdijk
Copy link
Contributor Author

Oops and another 😅
image

@CoenRijsdijk
Copy link
Contributor Author

I have 2 more bugs, hope you can fix it 😃, thanks in advance!
image (1)

image (4)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants