Kotlin has summarized the results of investigating what Java has improved, focusing on I'm not good at Java
, including why Java has become such a language specification.
・ I like Java, but I haven't used Kotlin at this time. (So the content may be thin) ・ What kind of language Kotlin is, grammar, etc. are mentioned a lot elsewhere, so I will not mention it here.
Isn't Java the most believer language among server-side programmers? Thought is sublime and does not accept beginners. Unlike other languages that have become object-oriented in the middle, they do not allow strange loopholes. Designing in this language is irresistible for engineers who like to think logically, right? (Lol)
However, there are many people who don't like Java because it has its drawbacks. And, after all, very few people want to use it privately (crying) So, at the study session I'm doing, I checked if there were any people using Java privately, and as expected, even one out of 15 people didn't use Java (crying). However, there were three people using Kotlin. From there, I became interested in Kotlin and decided to investigate.
First of all, Java is a nice place for me, but it looks like this.
How have these been improved! ??
First, you need to know why Java writes all getters / setters. I didn't understand it very clearly, but when I looked it up, there were various opinions. ・ To hide member variables and make them safe -To make it possible to monitor changes to member variables (make room for processing) I wasn't convinced by these, and it seemed that I could define it in public, but this is the correct answer that I finally arrived at. -Member variables cannot be overridden in subclasses! So wrap it in a method and override that method if you want the subclass to change its behavior.
This is now a property in C #, ruby, swift. So you don't have to write Getter / Setter. Properties can be overridden in subclasses. You can also abstract and force implementation in subclasses.
It seems that it is the only method adopted only in Java. Exceptions thrown by a method must be explicit as part of the method's syntax, and the caller must handle it or throw it above.
public FileInputStream(String name)
throws FileNotFoundException
This has the following benefits:
Many languages and mechanisms treat exceptions as run-time, and you don't know what exceptions will occur until they actually occur, and whether they can occur from this process in the first place. Especially in the case of Java, since you can understand the types of exceptions, you can expect a lot of exception recovery. [Source: Rethinking inspection exceptions](http://qiita.com/Kokudori/items/0fe9181d8eec8d933c98#java%E3%81%AE%E6%A4%9C%E6%9F%BB%E4%BE%8B%E5 % A4% 96)
However, this is now said to be a mistake and has not been incorporated into other object-oriented languages that represent C #.
The meaningless catch clause is mass-produced and actually deteriorates the quality of the program. Source: The Scalability of Checked Exceptions
Checked exceptions are gone and caller handling of exceptions is no longer enforced.
Occurs if you use variables before the instance is created.
//Run-time error for Java
String s = null;
s.length(); // java.lang.NullPointerException
This can't be helped, right? I thought, but modern languages have a mechanism to secure this. Reference: null unsafe languages are no longer legacy languages
In Kotlin, if it can be Null, it will be specified at the time of declaration, and if it can be Null, it will result in a compile error unless it is checked first.
//Variable?Null can be set in the attached declaration.?Null setting is not possible without it.
val s: String? = null
s.length //Compile error: only safe (?.) or non-null
↓
//OK writing
val s:String? = null
if (s != null){
s.length // OK
}
As you know, Java has eight primitive types (boolean, char, byte, short, int, long, float, double), which have wrapper classes for object types.
Why are there variables of primitive type? Java has taken many of its ideas from C ++. Primitive type variables are one of them. And, by incorporating this, I was happy that I aimed at the influx of existing C ++ programmers. In addition, primitive types seem to have the advantage of high processing speed. Reference: Primitive Types Considered Harmful
Reference source: Unknown defect of Java
-It is necessary to properly use the processing while being aware of whether the variable being handled is a primitive type or an object type.
⇒ [Example] Primitive types can be compared with ==
, object types use .equals ()
, etc.
-In order to pass a variable of primitive type to a method that takes an object type as an argument, it is necessary to convert it to an object type once, which wastes memory.
There are no primitive types in Kotlin. (However, it can be said that some of the convenience of primitive types has been lost.)
That's all, but for the time being, I had the impression that the parts that I personally couldn't say were almost improved.
If I have Java, I would love to use Kotlin.
Recommended Posts