Javac not trying to recover unresolved parameterized types

[Jan Lahoda]

Hello,


I''ve filled:
https://bugs.openjdk.org/browse/JDK-8338678


Thanks,

     Jan


On 20. 08. 24 16:40, Mickael Istria wrote:
> OK, thank you.
> Should I open such issue through https://bugreport.java.com/bugreport/ 
> ? I tried to submit an issue there about a month ago and didn't 
> receive any feedback at all (no confirmation, no followup...). Is this 
> service still the recommended one for such report or is there 
> something else you recommend?
> Thanks in advance
> Mickael
>
> On Tue, Aug 20, 2024 at 4:04 PM Vicente Romero 
> <vicente.romero at oracle.com> wrote:
>
>     Hi,
>
>     I think this is probably more a feature request than a bug but in
>     any case please file an issue and assign it to myself,
>
>     Thanks,
>     Vicente
>
>     On 8/19/24 12:02, Mickael Istria wrote:
>>     Hi all,
>>
>>     As part of our work to allow Eclipse JDT to use Javac as backend,
>>     we noticed that in case of unresolved parameterized types, the
>>     compiler doesn't generate a nice recovered TypeSymbol with
>>     interesting data (such as the name) that can be used later.
>>     For example, my latest issue is that code like
>>     ```
>>     class K {
>>       Regular reg;
>>       Parameterized<Object> par;
>>     }
>>     ```
>>     where neither Regular nor Parameterized exist, make Javac produce
>>     a "recovered" symbol for `Regular` (at least the ErrorTypr stores
>>     the "Regular" name) when asking for the tsym of `reg` VarSymbol,
>>     while it doesn't produce anything useful for `Parameterized` when
>>     asking for the tsym of `par` VarSymbol. In this later case, the
>>     symbol points to `noType` which isn't usable by the IDE to
>>     generate a minimal DOM object.
>>
>>     In comparison, ECJ generates a recovered type binding for
>>     `Parameterized`, which can be later used by some refactorings as
>>     if the type were existing. Such refactorings that work with ECJ
>>     backend cannot work with the Javac backend because of the symbol
>>     being unusable.
>>
>>     We're currently adding a bunch of workarounds in many places to
>>     handle this case, but we'd obviously rather prefer if Javac can
>>     come with such smartness out of the box.
>>
>>     So this behavior in Javac seems to me like a small issue or
>>     limitation in Javac. What do you think? Is this "problem" already
>>     known? Should this be reported as a bug? Does it make sense to
>>     expect Javac to provide such recovery for parameterized types to?
>>     Should we try to fix it?...
>>
>>     Thanks in advance for you guidance
>>     -- 
>>     Mickael Istria
>>     Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for
>>     Red Hat <https://developers.redhat.com/>
>
>
>
> -- 
> Mickael Istria
> Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red 
> Hat <https://developers.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240820/68ce8366/attachment-0001.htm>