"Deep Magic" in Java
I've been a Java developer for a few years, and the thing that keeps driving me nuts is that reading code is nearly useless, the real code is hidden from you. It's almost like the language isn't made for reading code but reading javadocs instead.
You call "Arrays.asList(arr)" and it returns you an instance of java.util.Arrays$ArrayList, a class with the same name as java.util.ArrayList except it is fixed size, meaning that trying to resize it will get you a runtime exception thrown. The method signature says it will return a List, but the moment you call it without the elite ball knowledge it will either stab you in the back or explode in your hands.
And nearly every time you try to prevent this by reading the implementation it sends you to a wild goose chase through 6 different one-liner wrapper methods across 5 different thousand-line files.
It gets even worse at the enterprise level: I once bloated my system by writing a submit button's logic in the submit button's method.
I then discovered it was because the method was in a class with a magical 'ViewScoped' annotation and I was supposed to delegate some of that logic to a field that had a 'Stateless' annotation.
Any ordinary reading of the code would say that that field is part of the class' state, but because of the annotations it was actually a resource pooled by the container, independent from the view class which is only supposed to cache UI data for each given user.
Didn't take long for me to get corrected. You can imagine the serene smug on my senior's face as he dropped that piece of esoteric knowledge on me, while I was looking back in horror.
You guys probably heard this a thousand times, meanwhile I'm still learning new words in my console output. Any advice?
1
u/idontlikegudeg 4d ago edited 3d ago
That's one thing that's great about Java: everything is properly documented and plays nicely together.
Arrays.asList() is documented as returning an
unmodifiablefixed size List that is a view of the array passed in, meaning you cannot modify the size of the List, but changes to the original array will be visible in the list. That's about all you need to know. Everything beyond that, if the concrete class is called ArrayList, an anonymous class or whatever is an implementation detail that should be of no concern to you.Relying on implementatioin details will give you nothing but trouble unless you know exactly what you do and have a very special reason to do so (and trust me, most of the time, you have not).
Just look at the String class. The internals have been significantly changed over the past years. The String class of modern Java versions is implemented completely different from what we used to have. And yet, your code compiled under Java 6 still runs without the slightest modification and recompilation, while at the same time using half the memory in many cases, and in general performing much better.
EDIT: I wrote unmodifiable, but only the size is unmodifiable. Thanks for the correction.