Sorry but Java doesn't have operator overloading. That's builtin operator behavior. Method overloading isn't a feature of polymorphism. It's a separate feature. Polymorphism is a trait of an object where it can appear as a single base type but can have a completely different implementation in a subclass. E.g. public void method (List<String> list) { //... } method(myArrayList); method(List.of( "A" , "B" , "C" ); Notice that method accepts two different object types both of which implement the List interface. Yet treats them as the same type due to inherited traits. That's polymorphism. It's always in runtime. ArrayList will define the method get so the compiler must define it as a virtual call. That means that runtime needs to invoke the right implementation of that method.

Also check out Lightrun which we make. It lets you debug production right from within your IDE! Works for both WebStorm (all applicable JetBrains IDEs) and VSCode.

Great post! Also I think the reason is to make it a bit more consistent with the behavior of the primitive types. I would also add that the JVM can then do some pretty cool optimizations to Strings seamlessly thanks to that...

segun osiki I've been a Java developer since the first beta 27 or so years ago. I'm not sure what's the best way since I took a path that isn't common. I wrote JVMs both at Sun and independently as part of my startup. I think curiosity and keeping up is the thing. Accepting that we can't possibly know everything is also important. I learn a lot about Java all the time despite all of my experience...

Nicely said! One additional piece of information to include would be the three types of threads through Java's history: Green - the first version of Java had green threads. Which means the process itself was single threaded and simulated "real threads". This meant the CPU cores weren't used effectively. Native - Very early versions of Java moved to native threads which means one Java thread == OS native thread. This means the CPU cores can be used properly but it also means you can't create too many threads... OS threads have a cost. Virtual - With project Loom which is now in preview Java introduces a new type of thread: virtual. Which merges these two concepts. You will have what is effectively a green thread on top of an OS native thread. This way threads become very cheap but also use the CPU cores completely. There are some nuances here but the scale and elaborate nature of this feature are unique to the JVM. It's a pretty spectacular feature.

Good luck! FYI new versions of Java also have the record data type which is a more concise syntax. They also have the var syntax which keeps type safety and more concise code.

Great questions! Let's address them one by one. I discuss security in-depth in this article . The gist is that you never expose or connect to production. It works the other way around which is an important distinction. It means any surface area to attack is significantly reduced/removed. I'd also like to add that Lightrun is used on Fortune 50 companies, banks, etc. where security and performance requirements are very extreme. Snapshots work pretty much like a breakpoint would. Only they don't stop. This requires a bit of a mind shift. For obvious reasons you can't use a breakpoint in production since a server might get stuck in the middle of debugging. Performance is always impacted. We measured Lightrun and found that when no actions are used the overhead is on the scale of 0.5% and when actions are added it's around the 7% overhead for a system under heavy load. Lightrun throttles action when they take too much CPU and you can tune the amount of CPU allocated to it. The default is pretty conservative so you shouldn't feel a performance impact regardless of what you do.

Circumventing the Java language rules via reflection isn't "really" mutability. By that measure immutability is impossible in the JVM. If your app was running under a security manager it would fail in runtime in any version of the JVM which is why String is immutable. This is actually enforced by the TCK since string mutability can be used for various attacks by untrusted code.

Great post and very similar to the workshops and talks I give on the subject . I focus on Java but the principals I discuss are universal.

Nicely said. For future posts it would be great to discuss caching based on a key and clearing a cache. Those are pretty amazing and very useful.