I like ever since I encountered it both in and in . When I switched to the , it happened when Java still had to gain . Applying an event-driven paradigm with that version of Java felt out of place and unelegant. But ever since I find myself slowly returning to event-driven choices.

For instance, after a HttpResponse is returned from a web server, I check the status code: if failure, then run failure method, else run success method. I can do that with an if statement. Using an if statement means that I have to query the status code. I can also do it with a Consumer and Runnable: onSuccess(action, otherwise). The status code still gets checked, but now that gets done in the appropriate place: the response checks it, or the code checks itself.

We see hints to this model in 's class, with its (Consumer) method, and its (Consumer, Runnable) method.

And it's a shame that we can't apply this model to Strings or anything else implementing an isEmpty() method: the Java won't let us most of its core classes.

It feels easier to implement this in a -based language like .

It's a shame that you can't subclass String. This was by design, just so nobody would try to extend it.

But that was extremely short sighted: Subclassing String, even just to give it a new name would allow us to have wonderful classes for validation:

Class PhoneNumber extends String;
Class Address extends String;

And so on. String dependent methods would work normally, and business logic would do its magic.

But nooo, make String final. 🙄


@rick_777 Indeed. And I won't be the first Java developer who found a need to facade the String class with a custom implementation just to be able to apply type semantics.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!