On Tue, 6 Jan 2026 15:29:44 GMT, Andy Goryachev <[email protected]> wrote:
>> You can put them on INFO to avoid introducing new problems (and seeing what >> can be fixed when you are nearby). Even though raw warnings are usually >> harmless, there are instances where code thinks the type is X when it is >> actually Y; fixing raw warnings problems will uncover those. We should >> definitely not be using more raw code, as that's basically reverting to Java >> 1.4 days. > > I might disagree here: if we are not planning to fix these thousands of > warnings, the warning should be disabled. > > I do want to point you to a problem (unrelated to this PR) - if you try to > edit CssParser (a simple whitespace change for example), you'll always get > these in Eclipse, quite annoying: > > > Description Resource Location > Cannot infer type arguments for ParsedValueImpl<> CssParser.java line > 3029 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java line > 3219 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java line > 3272 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java line > 3287 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java line > 3612 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java line > 3656 Yeah, it is just a difference of opinion in the ECJ compiler and javac. It can probably be written slightly differently so it compiles properly under both. Also, I did fix a lot of those, but that PR died. Fixing ParsedValue however is IMHO a waste; that thing should never have had generic arguments in the first place; it is a classic example where adding generics costs more than it benefits. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1990#discussion_r2666145064
