In 2025.1 it appears the internal code for type checking expressions etc. has changed, particularly as related to the new classes in com.intellij.java.codeserver.highlighting. For example, error highlighting wrt ExpressionChecker class used with JavaErrorVisitor makes it impossible to override behavior–because it is pretty much hardwired now.
Perhaps the classes in that package, such as ExpressionChecker, can be made non-final? Additionally, would be nice if the checkXxx() methods could be made protected instead of package-private. Generally, it would help a lot if the XxxChecker classes were more subclass friendly. It still involves hacking to accomplish what I need, but subclassing de-escalates the extreme spot I’m in at the moment.
My use-case involves the manifold plugin, which supports operator overloading for Java. Prior to recent changes in 2025.1 it was possible to override this behavior with custom type resolvers and highlighter. Now it’s impossible without resorting to extreme hacks.
The classes like ExpressionChecker are considered to be implementation detail and should not be exposed for direct use or inheritance (they are even not exposed outside of the package to other parts of Java plugin). In general, we are moving towards having more final classes, as uncontrolled inheritance from the plugins prevents us from evolving the platform: it becomes incredibly hard to change anything without breaking the plugins.
If you need to suppress some highlighting errors, you may implement com.intellij.highlightErrorFilter extension (see com.intellij.codeInsight.highlighting.HighlightErrorFilter). Starting from 2025.2, there will be also com.intellij.lang.java.javaErrorFilter extension (com.intellij.java.codeserver.highlighting.JavaErrorFilter), which is more convenient, as you get more context about an error.
If you like to report new errors, you can create your own annotator or an inspection.
In general, if you develop a support for a new language, it’s advised to write error highlighting from scratch, rather than reusing the internals of the existing one.
Is your plugin published in the JetBrains plugin repository? We usually try to preserve the compatibility with published plugins. I don’t remember any broken plugin alerts connected to this refactoring. Sorry if I’m missing something.
@Tagir.Valeev Thanks for your reply. After digging into this more I found I could indeed change my strategy to use HighlightInfoFilter.
Looking forward to JavaErrorFilter, I hope I can filter based on message id, rather than fumbling with raw text. Thanks for the info!
Re JetBrains plugin repository. Yes, it’s published there, but it didn’t break, assuming “broken” means compile errors. However, the semantic changes in IJ broke my highlightVisitor impl, which subclasses and replaces IJ’s HighlightVisitorImpl. Basically, the recent changes in 2025.1 prevent overriding methods such as visitPolyadicExpression as a means of truly replacing IJ’s impl–doing so now has zero net effect.
Anyhow, as you suggested it is still possible to filter the errors that don’t apply, which I will happily do now. Thanks.