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