The future direction: the transition from Java to Kotlin

foreword

Kotlin is ideal for developing server-side applications, allowing you to write concise and expressive code while maintaining full compatibility with existing Java-based technology stacks and a smooth learning curve: Expressiveness: Kotlin's revolutionary language features , such as support for type-safe builders and delegated properties, help build powerful and easy-to-use abstractions.

This is an excerpt from the kotlin promotion website introducing this language. IntelliJ, as a company that understands programmers the most, launched the kotlin language. After using it for a period of time, I think the kotlin completion is worthy of this evaluation.

1. Great for developing server side
2. Expressive
3. Compatible with java
4. Powerful and easy to use

Through this period of exploration and understanding of kotlin, I would like to express my thoughts on the transformation of kotlin to individuals and enterprises.

The first step of transformation: learn java well

If you are a novice with little understanding of the java language, it is not recommended to have a deep understanding of how kotlin works at the beginning.

The kotlin syntax itself is the encapsulation of many writing methods in java, transforming the cumbersome writing method of java into a concise kotlin writing method, and finally transforming kotlin into a java class.

Take a simple example:

val str = user?.id

The above short kotlin statement, converted to java, is:

String str = null
if (user != null) {
    str = user.id
}

In the end, kotlin still has to return to java.

Java itself supports a huge ecosystem. Most enterprises and open source libraries are still developing in Java. It is not easy for kotlin to be compatible with Java itself to the greatest extent.

In the foreseeable future, java is still the cornerstone of the development world and has an irreplaceable position, so as a true kotlin language learner, java is still a required course.

The second step of the transformation: understanding kotlin by heart

For a user who has just come into contact with kotlin, the use of various symbols and keywords is definitely a big resistance.

If you want to quickly understand the real strengths of kotlin, you must understand why kotlin does this?

Why does kotlin use the question mark "?"

The most common and difficult part of writing Java is dealing with null pointers.

The input of a system needs to consider the robustness. must define which variables are nullable and which variables are not nullable , when the variable is empty or not, how to deal with it, upstream The variable that the code gives me is not empty end.

I believe that as long as a programmer who considers the problem comprehensively, there will be such worries when writing code.

The purpose of kotlin is to eliminate programmers' worries.

first purpose of 161ea8b389f5d0 is to directly control the case where the variable is empty or not at the source. , so that programmers can feel at ease knowing that my variable will not be empty when writing code at each step. If it is empty, I already have a solution.

second objective is possibly empty variables, can have a very friendly, simple, readable treatment .

var userName = user?.name //当 user 不为空时将属性 name 复制给变量 userName

user?.let { // 当 user不为空时，打印 name 属性的值
    println(it.name)
}

user?.name?.let { // 当 user 以及 user.name 不为空时，打印 name 的值
    println(it)
} ?: println("name 为空") // 否则就输出 name 为空

user?.name = "kotlin" // 当 user 不为空时，给属性赋值

Here you can pause for a while and think about how to handle such logic in java.

This way of writing is enough to impress any programmer who has dealt with null pointer problems many times in java, or inexplicably encountered null pointer exceptions when the code is running for a period of time.

kotlin absorbing stream

If you are a programmer who has some pursuit of program writing, I believe you will not miss the stream and lambda in the jdk1.8 syntax.

When I want to convert a property of V in List<V> as a key to Map<String, V>, stream already provides a very concise way of writing:

Map<String, Choice> result = choices.stream().collect(Collectors.toMap(Choice::getName, Function.identity()));

Java is already very concise, but every time I want to do such an operation, I flip through the code or search the Internet for usage every time.

After you use kotlin's approach, I believe you will not forget its writing:

val result = choices.map { it.name to it }.toMap()

For some complicated stream writing, you may need to understand how java is converted to kotlin, but in general writing, you only need to delete stream().

It can be said that kotlin has completely absorbed the essence of stream, and on top of this, blue is better than blue.

Forget lombok and get set

Lomok is a supplementary force that cannot be ignored in the java world. It makes the simple get set definition no longer needed by programmers, but at the same time, its direct modification of the class also makes many programmers who use it deeply criticize it.

In the final analysis, it is due to the concept of encapsulation in java, which is to control the exposure of limited fields.

Therefore, in kotlin, there is no longer the concept of get set, only assignment and direct acquisition, only need to use the private , val , var to realize the visible range of the control field.

val name: String? = null // 能够获取，不能修改

var name: String? = null // 能够获取，能够修改

private val name: String? = null // 不可获取，不可修改

@RequiredArgsConstructor , which is also commonly used in spring boot, can be replaced by a simple constructor that directly generates fields.

The annotation of lombok itself does not take effect on kotlin code. When switching to kotlin, removing lombok is also a matter of course.

less is more

When you can understand the three main uses of kotlin and can apply them freely, then you will save at least one-third of the code.

In the world of code, less is more. To reduce redundant code is to buy development time for yourself, to reduce the probability of problems, and to improve the speed of troubleshooting when problems occur.

This may be the real experience that kotlin has accumulated for programmers over time.

Step 3 of Transformation: Practice

When you are successfully attracted by the concise and concise syntax of kotlin, and with the consent of the progressive people in the team, when you want to replace it with kotlin, please note that kotlin is fully compatible with java, which is not only the direction of kotlin's efforts, but also the responsibility of using on the person.

The replacement itself is pleasant, the previous code is shortened line by line in your hands, and the null pointer judgments are being replaced with concise question marks, but the risk is also increasing step by step, and every step of replacement must be done well. In regression testing, no one can predict whether the automatic java to kotlin code converter can be so rigorous in logical reasoning.

in the process of replacing

1. You may encounter java static methods that are not well compatible with kotlin
2. The default method in the java interface cannot be applied in the mapper interface in mybatis
3. various unexpected difficulties

But behind these difficulties, the significance of solving them is far greater than the difficulties themselves, so these are all worthwhile.

kotlin and swift3 in modern languages

The birth of kotlin syntax is not accidental, but the inevitable result of the continuous development of the code.

Comparing kotlin and swift3, you will find that the two are surprisingly similar, perhaps due to some overlap between the designers in the two languages.

But these overlapping points are not the products accumulated by generations of people, and there will always be people who will continue to pursue more efficient, more convenient and faster development methods.

These methods will also be continuously absorbed by modern languages, and these advantages will eventually be retained until the emergence of a new generation of computers.

Outlook for the future of kotlin

Hope the kotlin language can be accepted by more people and more enterprises.

For individuals, it is not necessary to use kotlin for development, but more needs to be accepted is that kotlin summarizes the way of thinking in the design process, and constantly requires himself to improve his original java skills.

For enterprises, reducing the cost of errors, reducing the error rate, and reducing the development time is always the top priority. Understanding the value brought by kotlin and applying it reasonably is the top priority.

At the same time, I also hope that kotlin itself can go a step further in the future, no longer use java as an intermediate language, but can directly achieve it in one step, and have its own writing, compiling, and running system.