Why I love Kotlin

At avisec we decided to use Kotlin when we started to rewrite our backend service. This has proven to be a very good decision. Here are my top 10 reasons why I do love Kotlin:

  1. Data classes eliminate a lot of boilerplate code.
  2. The nullability support of the compiler forces you to think about nulls everywhere. This reduces the number of NullpointerException related bugs to a minimum.
  3. The lambda syntax is very, very lean.
  4. No more guessing which functional Java interface to use.
  5. The standard library provides is a great help.
  6. The IntelliJ support is seamless.
  7. Java and Kotlin integrate both ways – you can start writing Kotlin code in Java projects today, no big deal.
  8. Return values are supported for most (?) structures: if, try/catch, when
  9. Assign default values to parameters and used named parameters when calling functions.
  10. Generics in Kotlin are more powerful than in Java.

Let’s hope the current adoption rate of Kotlin continues and it will become a widely used alternative for Java on the JVM.

Java startup parameters

The following Java startup parameters should be used (and the values adjusted) when running a Java process on a server.

-Xmx1G
-Xmx4G
-XX:+UseG1GC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-Xloggc:Gc.log
-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=10 
-XX:GCLogFileSize=100M

When a Java process starts, it overwrites an existing GC log file. I would recommend to either use a timestamp in the filename or use the %pid placeholder.

If you want to use JMX, also add the following parameters:

-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.port=1888
-Dcom.sun.management.jmxremote.authenticate=false

Functional Interfaces in Java 8

With Java 8, the concept of Lambdas was finally added to the language specification. Often you’re using Lambdas on the fly without assigning them to a variable.

List<String> names = Arrays.asList("Arthur", "Marvin", "Zaphod");
names.stream().forEach(name -> System.out.println(name));

However if you want to save a Lambda into a variable and pass it as a method parameter or use it later, you need to pick the applicable type.

public static void main(String[] args) {
  List<String> names = Arrays.asList("Arthur", "Marvin", "Zaphod");
  Consumer<String> print = name -> System.out.println(name);
  applyToAllNames(names, print);
}

private static void applyToAllNames(List<String> names, Consumer<String> print) {
  names.stream().forEach(print);
}

Here is the list of the Interfaces you might use from the Java API:

  • Runnable // nothing
  • Supplier<T> // a return value
  • Consumer<T> // a parameter
  • BiConsumer<T, U> // two parameters
  • Function<T, R> // a parameter and a return value
  • BiFunction<T, U, R> // two parameters and a return value
  • UnaryOperator<T> // the parameter and the return value have the same type
  • BinaryOperator<T> // two parameters and a return value of the same type
  • Predicate<T> // a parameter and a boolean return value
  • BiPredicate<T, U> // two parameters and a boolean return value

InformIT presents all those Interfaces using a nice table in the article “Java SE 8 for the Really Impatient: Programming with Lambdas“.

 

Linux kills a process when when starving memory

I recently observed a rather strange problem with randomly dying Java processes under heavy load. The vital clue to this problem was hidden in /var/log/messages as shown below:

Feb 1 12:26:31 mysuperserver kernel: Out of memory: Kill process 30595 (java) score 252 or sacrifice child
Feb 1 12:26:31 mysuperserver kernel: Killed process 30595 (java) total-vm:13698324kB, anon-rss:8226564kB, file-rss:0kB, shmem-rss:0kB

It turns out that Linux may decide to kill a process when the system runs out of memory. It may make sense to cap the memory limit (-Xmx) of any Java processes running on the system to a value that sums up below the server’s available memory.

Jaan Angerpikk explained this problem in great detail, follow the link below to read more on this matter.

https://plumbr.eu/blog/memory-leaks/out-of-memory-kill-process-or-sacrifice-child