Version the JDK EEA set about eclipse-null-eea-augments HOT 8 CLOSED

@vorburger Do you have any idea what bundle of Eclipse generates the EEA files with the ctrl+1 action?

from eclipse-null-eea-augments.

@vorburger Do you have any idea what bundle of Eclipse generates the EEA files with the ctrl+1 action?

That would presumably have to be *jdt.ui.. @stephan-herrmann would know all about that!

from eclipse-null-eea-augments.

I found the code that does it, but it depends on having a binding enabled version of the ADTParse being ready, instead of just a single source file, so not really something that will work with my current idea I'm working on.

from eclipse-null-eea-augments.

@J-N-K This is the current plan I have

1. Create a maven plugin to generate eea files for a given library
   • Adapt code in the eea-all project
   • Operate after the rt.jar or the jmod on the filesystem, not the current running VM's classpath
2. For each class
   • Enumerate all public and protected methods and members
   • Look for the signature in the main EEA file for that class
     • If it exists, copy the null annotation present in the EEA file
     • If it doesn't exist, use the placeholder signature and generate a warning about a missing null annotation
3. Run this process for each Java release supported by this project
4. Generate eea-jars for each version this way

Thoughts?

from eclipse-null-eea-augments.

Sounds good.

The question is if this is really necessary. Originally I also thought we should do that but what differences are really present in the EEAs for different JDK versions? I only found additional methods/classes for later JDK versions, so having EEA present for non-existing entities will not hurt. The only problem would be if a method signature changes, but TTBOMK this is not the case.

from eclipse-null-eea-augments.

I found the code that does it, but it depends on having a binding enabled version of the ADTParse being ready, instead of just a single source file, so not really something that will work with my current idea I'm working on.

For completeness: Class ExternalAnnotationUtil in JDT/Core also provides a few string-based helper methods.

from eclipse-null-eea-augments.

Sounds good.

The question is if this is really necessary. Originally I also thought we should do that but what differences are really present in the EEAs for different JDK versions? I only found additional methods/classes for later JDK versions, so having EEA present for non-existing entities will not hurt. The only problem would be if a method signature changes, but TTBOMK this is not the case.

No it probably isn't necessary. I'm not a fan of having more data that is needed in the files, but for methods that don't exist, shouldn't hurt anything. Guess this can be closed.

from eclipse-null-eea-augments.

Closing

from eclipse-null-eea-augments.