Introduction
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.
Over the last 15 years, the Java language and the JVM has been greatly improved. The JIT compiler, the apparition of the generics, the auto-boxing, soon (cross the fingers) the lambdas… All that features have contributed to the success of Java. But what is next? How to make Java better?
Through my experiences, I had the opportunity to work with several programming languages. This include C#, C/C++, PHP, Javascript, Groovy, ActionScript 3, Scala and some others… In many of these languages, I have found some features that made me say “that is f***ing awesome!”. Some of those features were not applicable to Java (different programmation paradigm, different way of thinking) while others were completely applicable. Also in some of these languages (mostly in PHP…), I have seen things that made me say “OMG! That’s crap!”… But that is a different story!
In each part of this serie, I will present one feature that does not exist in Java and explain why it should (or not) be in Java, the possible issues to deal with, etc…
Do not hesitate to post ideas of improvement, even the craziest/irrealistic one! I do not pretend myself to have perfect solutions, I just try to open the discussion.
Properties accessor
erie 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.
Accessing fields of an object through a transparent accessor is definitely THE feature I miss in Java.
What is it?
In Java, we use to use getters and setters which allow to access a property of an object. I will not speak of the benefits of having getters and setters instead of having public fields, I assume that you are aware of that… In other languages (C#, AS3, …), you can declare explicitly the getter and setter of a property and use them as if you were using a public property. My favorite syntax is the one ActionScript3 :
//Object Declaration
public class MyObject {
private var _myProperty:String;
public function get myProperty():String {
return _myProperty;
}
public function set myProperty(value:String):void {
_myProperty = value;
}
public function get firstLetter():String {
return _myProperty.substr(0,1);
}
}
//Usage
var o:MyObject = new MyObject();
o.myProperty = 'A value'; //Set the property using the setter
trace(o.myProperty); //Print the value return by the getter
trace(o.firstLetter); //Print 'A'
The Java syntax suggestion
Since I consider the ActionScript 3 syntax very convenient, I think that the Java syntax should be very similar. It would require to add new modifiers : get and set.
public class MyObject
{
private String _name;
public get String name() {
return name;
}
public set void name(String name) {
this.name = name;
}
}
//Usage
MyObject o = new MyObject();
o.name = 'My name';
System.out.println('print entity : ' + o.name);
Benefits
- Using an accessor is transparent. The encapsulation is made implicit. The caller does not know if it is calling a public variable or an accessor.
- Better OO style programming : From an external class point of vue, an object now really has public methods and properties, while before it was only public method.
- Refactoring the code to change all direct accesses to the fields of the object is a peace of cake, you just have to change the class concerned, not all read/write calls.
- No need anymore to have the JavaBean conventions on getter and setter. Some librairies relied on the fact that accessors of
myPropertyare called[get|is|set]MyProperty. Now the accesors are no more defined by convention but by contract. We can have a method on the classClasswhich retrieve the accessor (getGetters(), getSetters()). Once again, a big OOP enhancement.
Drawbacks
- It would require to change the naming convention of the object fields since the method and the property could have the same name. There’s no doubt that the JVM could allow that the property and the method have the same name, it is more a readability issue.
Implementation and Issues
Implementing this feature would require to add two new keywords (get and set) to the Java language. That is a bad things for the retro-compatibility but that is not a big problem. It would need to use the “-source” command-line option as it has been done before when the assert keyword has been added in Java 1.4.
This change would also require to modify the JVM specification, and so the java compiler, to add the two new modifiers. Those two new modifiers are needed in the class file in order to identify, using the reflection, the getters and setters of a class.
I believe that this feature would be an awesome improvement of the Java language. As all major improvements, it requires a lot of work. If one day I feel ready enough to submit a JSR, that will definitely be this one!
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 (ReentrantLock, ReadWriteLock, 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!
Reference: Java SE 11 : Moving Java Forward – Part 1 : Introduction, Java SE 11 : Moving Java Forward – Part 2 : Properties accessor, Java SE 11 : Moving Java Forward – Part 3 : Thread Safe compilation checking from our JCG partner Tibo Delor at the InvalidCodeException blog.
private String _name;
underscore, brrrr….
That the thing with the accessors, it needs to change the naming convention. The underscore is the convention in AS3, C# and a other of java-like languages. I don’t think that’s ugly, that is just a convention…