Java SE 11 : Moving Java Forward – Part 3 : Thread Safe compilation checking

This serie of article presents how, in my opinion, the java language should evolve to keep being a top choice language. It also presents some features, sometimes already existing in other language, that I love but that cannot (or should never) be part of Java, for some reasons that I will explain. I would really love to transform some of those ideas into JSRs one day.

Thread Safe compilation checking : What is it?

It is the ability to check that your program will not have issues due to multi-threading. As far as I know, no programming language provide this functionality (If you know one, please let me know!).

What is the problem?

Develop a program that runs in several threads is easy, develop something that won’t have any weird bugs due to that thread mechanism is far more difficult.

Why concurrent programming is hard?

Because, to make a good multi-thread application, you have to be very careful and to know perfectly the Java language and the API : avoid deadlocks, know when to use the volatile keyword, know what is (or not) thread safe.

The other difficulty is that testing/debugging a multi-thread application is very hard. You can spend several days wondering why in your huge database you have this row with a weird date value… To finally realize that your co-developper (of course not you, since you are a java guru ;) ) has used a SimpleDateFormat object shared by several thread… (BTW, if you didn’t know: yes, SimpleDateFormat is not thread safe)

What is the solution?

The thread safe compilation checking! It would make the development so much easier if you had a warning telling you “At line 36: Not Thread Safe code. Usage of a non thread safe method SimpleDateFormat.format”.

Why It is impossible

Usage of non thread safe APIs

At the moment, the only way to know if the libraries/APIs you are using are thread safe is to read Javadoc or the source code. So, the compiler has no way to know if what you call is, or is not, thread safe. By transitivity, if you are not using any kind synchronisation mechanism,  it has no way to know if your code is thread safe or not since you are using those libraries.

One solution to this issue could be to create a @ThreadSafe annotation to annotate classes and methods. That way, any element annotated with @ThreadSafe would be considered as thread safe by the compiler. Of course all the APIs you use needs to be annotated correctly… Apart from the compilation checking thing, I think that such an annotation would be great to make the APIs clearer.

The Reflection API

The Reflection API is an other issue. Since the execution flow is determined during the runtime, the compiler cannot know what methods will be called and so cannot determine if what is going to be executed is thread safe.

The compiler needs to know the context

The compiler has no way to know if what you are developing is going to be executed in a thread safe environment or not. For example if you are developing a bean that is going to be injected everywhere by your favorite CDI framework, the compiler cannot know it.

In other words, the compiler knows less than you and so cannot determine if what you are programming needs to be thread safe or not. Let’s say you are programming a controller for your J2EE application; If you don’t annotate your controller with the hypothetic @ThreadSafe annotation, the compiler won’t ever complain. The problem is that your controller have to be thread safe! If you don’t annotate correctly with @ThreadSafe what had to be thread safe, you will have issues…

The different locks mechanism

If the only way to synchronize your threads was the synchronized keyword, it would be easier for the compiler to determine if a piece of code can be run concurrently or not. Unfortunately that is not the case! You have several way to ensure that your code will be executed only in the right context (ReentrantLockReadWriteLock, manual locks using a file, a socket, an object, a counter etc…). To me, this only reason makes the “thread safe compilation checking” impossible to implement. If the compiler is not able to spot  the synchronisation mechanism, it cannot know anything about thread safety!

Conclusion

Thread safe compilation checking would definitely be a killer feature. But to me, it is impossible to implement, even partially, and that’s probably why I have never seen this feature in any languages.

If you have any ideas of a solution or if you know any language that does it, even partially, let me know!

 

This entry was posted in Java Core and tagged , . Bookmark the permalink.

One thought on “Java SE 11 : Moving Java Forward – Part 3 : Thread Safe compilation checking

  1. Hi,

    for me currently the more promising approach seams dynamic tracing not static checking. I developed a tool http://vmlens.com which does exactly this. It finds data races by looking for fields which are accessed by more than one thread without synchronization. The next step will be to implement deadlock detection.

    Regards
    Thomas

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>