UIBInder validation of super interface methods

[seamusmac]

If you import the following project into eclipse.
You will see that the ui.xml file contains a validation error when it should not.

https://github.com/seamusmac/gwt-invalid-xml

[seamusmac]

I spent a little bit of time trying to figure this out, but it seems to be quite a difficult one given that its related to generics. I don't know JDT too well, and couldn't figure out how to resolve Type 'T'

The line
https://github.com/gwt-plugins/gwt-eclipse-plugin/blob/master/plugins/com.gwtplugins.gwt.eclipse.core/src/com/google/gwt/eclipse/core/uibinder/UiBinderUtilities.java#L405 returns null for the type T which is why it shows a validation warning in eclipse

@branflake2267 any idea if its possible to resolve the generic type? or if there is some sample code I could look at somewhere as a basis?

[branflake2267]

Nice job looking into it.

I found this, it may be of interest.
https://stackoverflow.com/questions/17297308/how-do-i-resolve-the-actual-type-for-a-generic-return-type-using-reflection

[branflake2267]

I remember there being some Java Utils, not sure they fit this job, but there may be some utilities available somewhere. I always have to start looking around to confirm.

[seamusmac]

Cool, I didn't think to really use reflection. I was trying to use the JDT api as much as possible.
There is the JavaModelSearch util class in there, but nothing for generics, unfortunately

Do you want me to try with the reflection based approach then?

[branflake2267]

I think you could use whatever works. That said, you're heading in the right direction, thinking about using what's available. You can only use the libraries available on smallest installs or target machine. If you're running a target you're safe to test using the dependencies. It's safe to use reflection because it's part of the Java api. You can add libraries in the manifest for use as well. I think there may be an older guava library loaded on the classpath if that makes it easier to use some higher level utility to get the job done. Anyway running debugging against the target makes it hard to add a reference to a library that wouldn't be on an end user machine. But if you don't have all that set up, keep it simple to start. Or I can provide directions on how that might be done.

[seamusmac]

Some credit goes to @stephan-herrmann for answering my question related to JDT on this.

See https://stackoverflow.com/questions/49117612/eclipse-jdt-core-resolve-generic-return-type-for-parameterised-super-method

[stephan-herrmann]

Please keep in mind that all code in "internal" packages of JDT may change without notice. As the development of support for Java 9 showed, this is more than a theoretical risk, changing method signatures etc is a reality, necessary for keeping pace with the evolution of Java. On stackoverflow I intentionally said "For further inspiration you may want to look that the internal method ...". In this particular case I would actually recommend to copy the relevant method(s) into your own code. The amount of code to copy should be low (it's all coded against public API) - compared to the risk of breakage.

[branflake2267]

Good point, I've already seen breaks because of internal api usage.

[stephan-herrmann]

JDT has a rich API, so that access to internal methods should not be necessary. If for whatever reasons this API is not sufficient for your needs, it's always a good idea to file a request in our bugzilla - hoping that we can always find some solution avoiding any access to internals.

[seamusmac]

I didn't really look at the package when I coded the solution for this bug. I was trying to make the change as small as possible and rather that copying code from JDT, I tried to use what was available.

If you want me to copy the code in question here to remove the internal package dependency, let me know and I can submit another PR.

Is the PR that was merged, already in the snapshot build or ?

[branflake2267]

It's merged, but haven't staged it. But after looking at it again, it looks like it's setting the parser to Java 8, do you know if that will be a problem for folks using Java 7?