Incident Report 9079511: Java Language Enhancement: Disallow access to static members via object references

[Mahied Maruf]

I would just like to also append abstract class static method
inheritance. Currently, the following patterns are quite common:

	/*package-private*/
	abstract class A {

		public static void example() {
			
		}
	}

	public class B
		extends A {

		...		
	}

	B.example();

and I consider them to be a good and useful element of the language
design. Specifically the case that was demonstrated here of accessing
static methods against a local variable or method argument instance,
that does stick out to look like an antipattern but I would still
prefer to leave it as a warning.

If in the future it actually becomes anomalous to determine what method
was called, it makes more sense to prevent this case. Potentially
breaking programs _only_ without the motivation behind introducing
something (e.g. say when `_` was reserved when lambdas were introduced)
is not very smart and it's better to keep it as a documented footgun.

> David Alayachew said:
> I might consider turning the warning on by default

+1 for this.
It's a strong warning by default in most IDEs as well.

> Tagir Valeev said:
> By the way, this "feature" complicates the static analysis

Then improve your software. Java is a more difficult language to
analyze and I think the incompetence of a piece of software should not
be the motivation for the feature.

Is it really that difficult to analyze?

> There's a false-positive warning at `process(null)`

I would say that this is one case where the nullability analysis should
just be improved, but I also think it's not a false-positive warning
and could genuinely be useful - you generally don't want to be calling
any methods against `null`, even though it would work in theory
(and if the compiler allows it currently, this is now a feature)?

Best regards,
Mahied Maruf <contact at mechite.com>