Java primitives Problem
The most important types in Java are the primitives. And primitives do not fit well in OOP.
Auto boxing has been introduced in Java 5 to help us deal with this problem, but auto boxing as severe limitations in terms of performance, and this is related to how thing are evaluated in Java. Java is a strict language, so eager evaluation is the rule. The consequence is that each time we have a primitive and need an object, the primitive has to be boxed. And each time we have an object and need a primitive, it has to be unboxed. If we rely upon automatic boxing an unboxing, we may end with much overhead for multiple boxing and unboxing.
Other languages have solved this problem differently, allowing only objects and dealing with conversion in the background. They may have “value classes”, which are objects that are backed with primitives. With this functionality, programmers only use objects and the compiler only use primitives (this is over simplified, but it gives an idea of the principle). By allowing programmers to explicitly manipulate primitives, Java makes things much more difficult and much less safe, because programmers are encouraged to use primitives as business types, which is total nonsense either in OOP or in FP.
Method vs function
One huge difference between using a method and using a function is parameter evaluation time. In Java, one can write a method taking some arguments and returning a value. Is this a function? Not at all. A method can’t be manipulated in any other way than calling it, and this implies that its arguments will be evaluated before the method is executed. This is a consequence of arguments being passed by value in Java.
Functions are different. One may manipulate functions without evaluating them. And one has complete control over when the arguments are evaluated. And if a function has several arguments, they may be evaluated at different time.
Default values are the values assigned to instance variables in Java, when no initialization value has been explicitly set.
Instance variables (i.e., those declared at the class level) have a default value of
null. Local variables (i.e., those declared within a method) do not have a default value, not even a value of
null.Checking an uninitialized local variable object for a value (including a value of
null) will result in a compile-time error.
Using the equals() Method
== equality operators are used to compare the memory locations of two objects. To compare the contents of two class objects, the
equals()method from class
Object can be used or overridden. When the
equals() method is overridden, the
hashCode()method should also be overridden.
In a string, the
equals() method compares two strings, character by character, to determine equality. This is not the default implementation of the
equals() method provided by the
Object class. But the overridden implementation provided by
Cloning results in another copy of the object, not just a copy of a reference to an object. Cloning is usually very complex, so you should consider a copy constructor instead.
In shallow cloning, primitive values and the references in the object being cloned are copied. In deep cloning, the cloned object makes a copy of each of its object’s fields, recursing through all other objects referenced by it. A deep-clone method must be defined by the programmer. For a class to be cloneable, it must implement the interface
Java Identity Function
Function.identity() Returns a function that always returns its input argument. using
Function.identity() instead of
x -> x might save some memory
Validate Access Tokens Locally or Remote?
“I need all of the securities!” depends on the factors like ease of use, cost, and performance.
The biggest downside to validating a token locally is that your token is, by definition, stale. It is a snapshot of the moment in time when your identity provider (IdP) created the token. The further away you get from that moment, the more likely that token is no longer valid: it could have been revoked, the user could have logged out, or the application that created the token disabled.
Remotely validating tokens are not always ideal, either. Remote validation comes with the cost of adding latency in your application, as you need to add an HTTP request to a remote server every time you need to validate the token.
You could validate more sensitive operations remotely and all other requests locally. For example, when updating a user’s contact information, you may want to validate the token remotely, but when viewing the user’s profile information, validate locally.