Java Bits

Java primitives Problem

Nuwan Zen
3 min readSep 4, 2021

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

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

The != and == 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 String class.

Cloning Objects

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 Cloneable.

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.

--

--

Nuwan Zen

Sometimes A software Engineer, sometimes a support engineer, sometimes a devops engineer, sometimes a cloud engineer :D That’s how the this life goes!