Could we add a lint warning for when the type parameter name overloads an existing type name?

[David Alayachew]

Whoops, I meant core-libs, not client libs. I always mix up the 2.

Copy pasting below, so that people don't have to read the butchered version
that pipermail spits out.

Hello Amber Dev Team, Client Lib Team, and Compiler Dev Team,

In the vein of smoothing the on-ramp for beginners, one of the biggest pain
points I have found when tutoring beginners is when they start to learn
generics, and then do something like this.
import java.util.*;

public class abc
{

    public static void main(final String[] args)
    {

        final Map<String, Integer> cache = new HashMap<>();

        final int result = updateCache(cache, "abc", 123);

        System.out.println(result);

    }

    public static <String, Integer> Integer updateCache(final Map<String,
Integer> cache, final String key, final int value)
    {

        return cache.put(key, Integer.valueOf(value));

    }

}

$ javac abc.java
abc.java:21: error: cannot find symbol
                return cache.put(key, Integer.valueOf(value));
                                             ^
  symbol:   method valueOf(int)
  location: class Object
1 error

This type of error is the worst because it sends them on the wildest goose
chase. They start coming up with the most eldritch deductions as to what
could possibly be wrong, and they start actively unlearning stuff that they
know to be true. When I finally show them what is wrong, it's already too
late because (1) they start doubting the foundations because the "clearly
correct" solution doesn't work for a non-obvious reason, and (2) they
usually picked up some incorrect assumptions along the way that neither of
us have realized yet.

And the worst part is that, if you removed the "Integer.valueOf", and then
changed the third parameter to be final Integer value instead of final int
value, then the code compiles and works as expected. So, the student can
actually go pretty far before code starts breaking. That is the absolute
worst because they start turning this style of coding into a habit and then
when it finally blows up, all of their progress has to be undone. They feel
defeated, they hate the feature, they lose motivation, and now I have to
work triple time to rebuild all of that. It's a terrible time for everyone
involved.

Could we add a lint option that turns this into a warning? Basically says,
if you put an alias for a parameterized type that also happens to be an
exact match for an already imported class, throw a warning upon compile?
Then, this issue can be caught at compile time the second that they
introduce it. When they ask me about the warning, I can immediately explain
the problem, and this entire fiasco is avoided.

Finally, I also type up this email because this can be kind of easy to miss
when you are quickly cycling back and forth between students, trying to
make sure everyone is good. I don't have that many now, but back when it
was double digits, I distinctly remember falling into this pothole multiple
times.

Any thoughts on this feature?

Thank you for your time and consideration!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240414/093d41ca/attachment-0001.htm>