masesgroup/JNet

Using JNet 1.5.5 some limits or constraints of JNetReflector are raised

masesdevelopers opened this issue · 6 comments

          Using [JNet 1.5.0](https://github.com/masesgroup/JNet/releases/tag/V1.5.5.0) some limits or constraints of JNetReflector are raised:
  • A class containing main method is reflected using JVMBridgeMain<TClass>, but fields and methods are not available; plus it is not possible to allocate it to use dynamic behavior to access fields and mehods
  • Some language keyword, e.g. event, are not replaced with new one if used in the reflected code

Originally posted by @masesdevelopers in masesgroup/KNet#168 (comment)

Other limitations raised are:

  • Iterator<E> shall be managed like it is done for Iterable<E>
  • A class reported to be Listener does not contains nested classes
  • In some packages (e.g. org.apache.kafka.connect.storage) the classes are created, but AllPackageClasses.cs not contains all classes
  • Add a new switch to rename a class which clash with namespace: current feature does not work if the class name clash happens between different JARs or modules
  • When a namespace is avoided (e.g. org.apache.kafka.common.internals) some methods still reports types from that namespace
  • Some Iterable classes (e.g. ConsumerRecords) inherits from Java.Lang.Iterable<K, V> which is syntactically wrong, the correct superclass is Java.Lang.Iterable<ConsumerRecord<K, V>>
  • Some generic return types are not reported in the right way: e.g. KafkaProducer.Metrics() reports Java.Util.Map, it must be like Java.Util.Map<MetricName, Metric>
  • Some where clause are applied, but the constraints are related to the interfaces which are not reported in the class definition, but as operator associated to the class: the conditions break the applicability of where clause

Other limitations raised are:

* In some packages (e.g. `org.apache.kafka.connect.storage`) the classes are created, but `AllPackageClasses.cs` not contains all classes

This issue depends on package name shared between multiple JARs; so when latest JAR is analyzed it overwrites the previous AllPackageClasses.cs file, leaving the some orphan class in the folder

Other limitations raised are:

* A class reported to be Listener does not contains nested classes

Waiting for #137: create empty classes for listener which accepts nested classes

Other limitations raised are:
* Some where clause are applied, but the constraints are related to the interfaces which are not reported in the class definition, but as operator associated to the class: the conditions break the applicability of where clause

Some steps will be done:

  1. associate a C# interface to any JVM Class reported to be an interface
  2. modify the where clause to accept the newly created interfaces, adding the new constraint to be sure the type is the class associated to the interface

Other limitations raised are:

* `Iterator<E>` shall be managed like it is done for `Iterable<E>`

* Some Iterable classes (e.g. `ConsumerRecords`) inherits from `Java.Lang.Iterable<K, V>` which is syntactically wrong, the correct superclass is `Java.Lang.Iterable<ConsumerRecord<K, V>>`

The following piece of code
https://github.com/masesgroup/JNet/blob/44acc282db09b92ddad136faa7bd0eacdefdbff4/src/net/JNetReflector/InternalExtensions.cs#LL903C1-L914C22

does not manage generic Java.Lang.Iterable in the right way, shall be analyzed the GenericInterface.

Other limitations raised are:

* When a namespace is avoided (e.g. `org.apache.kafka.common.internals`) some methods still reports types from that namespace

The problem comes from two main reason:

  1. when a base class is retrieved, if it is a super class it is checked, but if the type is defined from the single interface the type is not checked
  2. if ta type is a generic, it is checked only the outer type, not the inner type(s)