> From: Eric Bresie <[email protected]>
> Date: June 14, 2019 at 6:59:43 AM CDT
> To: Jan Lahoda <[email protected]>
> Subject: Re: Re: Re: remove annotation in NetBeans..
>
> FYI this is the javac compatibly change I was mentioning which believe comes
> as of java 9
>
> http://openjdk.java.net/jeps/182
>
> Eric Bresie
> [email protected]
>
>> On June 14, 2019 at 12:20:59 AM CDT, Jan Lahoda <[email protected]> wrote:
>>> On Fri, Jun 14, 2019 at 2:45 AM Tim Boudreau <[email protected]> wrote:
>>>
>>>> On Thu, Jun 13, 2019 at 2:22 PM Jan Lahoda <[email protected]> wrote:
>>>>
>>>> On Thu, Jun 13, 2019 at 7:29 PM Tim Boudreau <[email protected]>
>>> wrote:
>>>>
>>>> I believe I know what problem this is supposed to solve, and I don't
>>> think
>>>> it is related to what you are describing. The problem is rather this:
>>>> imagine someone has written an annotation processor for JDK 8, with the
>>>> knowledge of the JDK 8 Java lang model. That's good. Now, in some future
>>>> version of Java, the model is enhanced to cover the language features. It
>>>> is unclear whether the processor can handle the new model correctly or
>>> not.
>>>> It may (and it is easily imaginable) pass vacuously, which may mean the
>>>> compilation may pass without any errors or warnings, but the processor
>>>> didn't do what it was supposed to do (e.g. create a META-INF/services
>>>> registration). That is a fairly bad situation, IMO: no warning, but
>>>> incorrect output produced.
>>>>
>>>> In other words, the Processor.getSupportedSourceVersion() returns the
>>>> highest model version the processor can safely handle.
>>>>
>>>> Maybe the exact implementation of this check could be better, but I don't
>>>> think we could say it is "useless".
>>>>
>>>
>>> Oh, I understand the reasoning. But the Java language model is API or it
>>> isn't? If javac goes and changes it and breaks a lot of annotation
>>> processors, I think enough users of them would scream bloody murder that
>>> that change would be unlikely to make it into the JDK. I've written enough
>>> annotation processors that I will certainly be one of them.
>>>
>>
>> Of course, the changes are as compatible as possible. But, as the Java
>> language evolves, the model evolves as well, correct? Most processors can
>> (hopefully) handle most of the changes, but, as the processor can do
>> whatever it likes, it is difficult to say that all processors are fine.
>>
>>
>>>
>>> Seriously, what this implies is that, if you are an annotation processor
>>> author, you didn't know it but you are married to making a pointless update
>>> to your annotation processor with every JDK release until the day you die,
>>> or perfectly will look like it's broken to all its users. That's insane.
>>>
>>
>> Not necessarily - if you are sure the processor can handle the new models,
>> simply return SourceVersion.latest() from
>> Processor.getSupportedSourceVersion().
>>
>>
>>> Is there a real world example of this happening? If not, then this is a
>>> "but someday, somebody might need this" feature, and we both know those are
>>> a bad idea.
>>>
>>
>> The model does evolve in practice (default interface methods in 8, modules
>> in 9, etc.).
>>
>> Breakages of annotation processors are hopefully rare, but consider for
>> example our ServiceProviderProcessor (which handles the @ServiceProvider
>> annotation). I doubt it works correctly (or even can work correctly) when
>> compiling a named module. But when compiling for the unnamed module, it is
>> fine even for (currently existing) JDK 9+.
>>
>>
>>>
>>> Here's how supportedSourceVersions() *should* be used by javac: Not as a
>>> "this annotation processor may be broken, warn the user" notification, but
>>> as a signal to javac *that it needs to expose the model to that annotation
>>> processor using the API available to javac in the JDK of that source
>>> version.* In other words, this should be a hint to javac about the types
>>>
>>
>> That sounds nice, but what is the JDK 8-like model for a module-info?
>>
>> Jan
>>
>>
>>> the annotation processor expects; and perhaps deprecate / delete
>>> compatibility layers for older JDKs on a schedule. Making this the
>>> annotation processor author's problem, or worse, the annotation processor
>>> user's problem, is the worst possible solution.
>>>
>>> If the compiler is going to break its API, it should not be other people's
>>> problem to deal with it. And it certainly shouldn't be making people jump
>>> through hoops to fix warnings that it *might have* when it actually hasn't.
>>>
>>> So, yeah, I get the reasoning, but it is the wrong solution to a problem
>>> that has yet to actually exist, yelling at people to do something because
>>> it might.
>>>
>>> -Tim
>>>
