Table of Contents
For years, Java has been the staple of Android development but times change and now Kotlin seems to be a new rising star. Some developers believe that Kotlin will soon replace Java completely while others claim that Java is here to stay.
So what’s the truth and which programming language is better? In this article, our Java specialist compares Java and Kotlin and discusses the pros and cons of both.
Java and Kotlin: a quick overview
Java was first introduced back in 1995, and since then, has seen lots of changes and transformations. Now it’s among the top programming languages in the world and is suitable not only for web and mobile development but also for reactive programming and machine learning.
Kotlin, on the contrary, is a new kid on the block. In 2017, Google announced first-class support for Kotlin during the “Google I/O” and since then, the language skyrocketed in popularity. Many developers claim that Kotlin is a valid replacement for Java due to its functionality and interoperability. One of the biggest advantages of Kotlin is the fact that the language is suitable for JVMs and is 100% Java-interoperable.
So why exactly do so many people believe that Kotlin is a new Android development standard if both languages have their pros and cons? Here are some of the biggest advantages of Kotlin over Java.
No more null pointers
Named as a billion-dollar mistake, the null pointer exceptions cost many companies lots of time and money as they attempted to fix these exceptions or avoid them in code.
With the Optional type boxing, Java tried to overcome this problem in its latest releases. But in my opinion, this just adds more complexity and boilerplate code. Turns out, it might be easier to use the good old conditional null check.
Keeping this issue in mind, Kotlin was designed as a null-safe language. The language incorporated the inherent null safety which successfully prevents developers from fixing the potential null-related issues. The only possible reasons for null pointer exceptions in Kotlin may be:
- An explicit call to throw NullPointerException(),
- Some data inconsistency related to initialization,
- Use of the !! operator.
No raw types
The usage of raw types in Java can lead to spoiling type integrity of a collection and therefore to the occurrence of exceptions. Joshua Bloch, a former Google software engineer, even recommends to not use raw types in code because of this issue.
Unlike Java, Kotlin doesn’t have raw types. The type of the collection should either be always defined explicitly (when passed as a parameter) or detected by a compiler when initialized.
Arrays are invariant
This is another problem with Java which can lead to spoiling the data integrity. The arrays in Java are designed to be covariant. So the following code is possible:
Integer[] myInts = {1,2,3,4};
Number[] myNumber = myInts;
What is wrong with that code? In fact, if we always use the Integer type we will be fine. But if we try putting some other type inside a collection we will have an ArrayStoreException during the runtime because the compiler doesn’t know the actual type of the variable.
myNumber[0] = 3.14; //attempt of heap pollution
In Kotlin arrays are invariant so the compiler will not allow such assignment.
No checked exceptions
The benefits of checked exceptions are a rather arguable topic. Take a look at this code:
Appendable append(CharSequence csq) throws IOException;
This exception is placed here because one of the implementations of the Appendable interface can use IO (the author implements Appendable as well). That means that for all other implementations of the append method (like StringBuilder, console, etc.) we should wrap this call with try {} catch {} block. The other way is to add throws IOException to each method signature in the call chain. This seems unnecessary and affects code readability in a bad way.
Kotlin doesn’t have checked exceptions and therefore you don’t need to add redundant try catch blocks and throws signatures.
Smart casts
In Java, you have to use the instance of operator and then explicitly cast type. Kotlin provides the is operator instead and the compiler casts objects automatically:
fun demo(x: Any) {
if (x is String) {
print(x.length) // x is automatically cast to String
}
}
Concise code
It goes without saying that brevity is a key to productivity. If we look at Java, the boilerplate code is still a big issue even though it tends to have a high level of readability. As for Kotlin, it combines brevity with readability and allows developers to write code in fewer lines if compared to Java.
Kotlin drawbacks for consideration
Even though Kotlin seems to be more efficient and high-performing than Java, it has certain drawbacks that are to be addressed. They are:
- Ambiguous compilation speed: many developers claim that they observed fluctuations in Kotlin code compilation speed. While it might be really fast, it might also be really slow so you can never know.
- No primitive types: Kotlin completely lacks the primitive types that Java has and that can guarantee memory footprint and better performance.
- Small community: since Kotlin is a relatively new programming language, its community is still rather small so you will not get much support and assistance in case you face a new issue.
- A small number of Kotlin developers: if you have a big Kotlin project ahead, get ready to spend some time on finding experienced and professional Kotlin developers since the language has not gained big traction yet.
Java vs Kotling: functionality comparison
Both languages have rich functionality and are designed to help developers code in a faster and more efficient manner. At the same time, both languages have certain features that are not present in the other. Let’s have a closer look.
Java features that Kotlin does not have
Even though the list is not too long, it’s still worth mentioning:
- Primitive types
- Static members
- Wildcard types
- Non-private fields.
Kotlin features that Java does not have
As for Kotlin, the list of brand-new features will be longer:
- Inline functions
- Null safety
- String templates
- Singletons
- Smart casts
- Extension functions
- Range expressions
- Companion objects
- First-class delegation.
And that’s not even a full list.
The business benefits of deploying Kotlin
We’ve spoken about the benefits of Kotlin over Java but how exactly does Kotlin benefit one’s business?
Faster development
Because Kotlin is known for its brevity, it, therefore, requires less time for developers to write code and check it for bugs and errors. This, in turn, allows faster time-to-market and is a big benefit.
Higher quality of applications
No null pointers, fewer lines of code, an array of features that ensure seamless performance – Kotlin takes really good care of the app’s quality. As well, the minimal number of code lines leaves less space for bugs and errors which is a plus as well.
Cost-saving
First, Kotlin ensures robust and high-quality performance which means saving money on debugging. Second, Kotlin is fully interoperable with Java so the integration of Kotlin does not mean you will need to revamp your whole ecosystem.
Java 19: An Overview of the Main Features That JDK 19 Brings
Should you choose Kotlin or Java?
I’d say you should choose both. Java, without a doubt, is a backbone of thousands of flawless applications in dozens of domains, such as healthcare, education, e-commerce, or telemedicine. With the help of Java, developers can create responsive and user-friendly apps that will display a high level of quality and security.
On the other hand, Kotlin is a really hot trend and in order to be a good developer, one needs to be aware of modern trends. Even if you are not going to fully switch from Java to Kotlin, you might at least try to implement it partially and see how it turns out. Maybe you will become a Kotlin evangelist or stay loyal to Java – only practice and time can tell.
At SoftTeco, we have over 12 years of experience with Java development so we are confident in the Java products that we develop. However, we are also open to everything new so we will for sure introduce Kotlin to our projects and see what works best for a specific project.
Comments