Implementing lombok.val in the lombok-intellij-plugin

Avatar
Permanently deleted user
Created

Hi all,

I'm working on the lombok-intellij-plugin as a pet project. I've managed to implement the support for the @Wither annotation but I'm struggling with the one of 'val'. Let me describe the problem ; say we have the following source code :

import lombok.val;

class TestVal {
  void aMethod() {
    val aVar = "sometext";
  }
}


At the moment, intellij idea is quite logically highlighting the 'aVar' variable as erroneous. Indeed, its type is explictly declared as 'lombok.val' ; however, it is assigned a value of type 'java.lang.String'.

What the plugin needs to do to resolve the issue is thus to assign to 'aVar' the type of its assignment expression but at the same time to keep the 'val' word as the textual description of that type - i.e the aspect of the source code should not be affected by the type substitution.

My first and awkward attemps at implementing such a behaviour have been unsuccessful. At best, I've been able to replace the type of a local variable but never without simultaneously changing the text representing it.

Any thoughts about the way to achieve the desired effect ?

Thanks,

Grégoire Neuville.

Votes

0

Share

4 comments
Avatar
Dmitry Jemerov
Created

There is no API at the moment that would allow you to accomplish what you need.

0
Avatar
Permanently deleted user
Created

Ouch... Thanks for the answer anyway ! Two more questions if you don't mind :

  • Will there ever be an API supporting this or is the lombok.val stuff too much of a corner case ?
  • Would a minimal support be conceivable ? I'm thinking at :
    • suppressing the 'type mismatch' error through an inspection tool
    • implementing the type substitution at the reference level (to get back to my example, any further reference to 'aVar' would be considered having the type 'String')


Thanks,

Grégoire Neuville.

0
Avatar
Dmitry Jemerov
Created

- Our support for the Java language is designed to support, well, the Java language. The language as transformed by Lombok is simply not Java any more. We can add an extension point to support this particular case, but it would not have any use outside of the Lombok scenario, and I don't think that implementing perfect support for Lombok is high on our priority list. (My personal opinion is that, once you go that far in the direction of mutilating Java, you will get much better bang for the buck by switching to an alternative JVM language.)
- Suppressing the "type mismatch" error might be possible through the current API (see the HighlightErrorFilter interface). For anything else, there is no API.

0
Avatar
Permanently deleted user
Created

> - Our support for the Java language is designed to support, well, the Java language. The language as transformed by Lombok is simply not Java any more. We can add an extension point to support this particular case, but it would not have any use outside of the
> Lombok scenario, and I don't think that implementing perfect support for Lombok is high on our priority list.

Fair enough.

> My personal opinion is that, once you go that far in the direction of mutilating Java, you will get much better bang for the buck by switching to an alternative JVM language.

I agree... and wish I could.

> Suppressing the "type mismatch" error might be possible through the current API (see the HighlightErrorFilter interface). For anything else, there is no API.

Thanks for the pointer and for taking the time to answer my questions,

Grégoire Neuville.

0

Please sign in to leave a comment.