Teenage Sex and What the sun.misc.Unsafe Misery Teaches Us Generally

Lukas Eder wrote an article about the miseries of the proposed drop off of sun.misc.Unsafe. If you have not heard that Oracle will remove the internal sun.misc.Unsafe class in Java 9 then read the article of Lukas and follow some of the links he provides at your discretion. His article is about what we learn from this happening.

sun.misc.Unsafe is a class available in most of the Java implementations delivering some “unsafe” functionality that are not available in other ways. These functions are not part of the specification and are not guaranteed to be available. They just happen to be there and are available via some nasty reflection hack. In other words: you should not use it, but you can. There are some Java tools that help protect you from using the interface but not too heavily.

Other languages, like Perl do not even have that level of protection. In that language there is no ‘private’, ‘protected’ or other access modifier. What is created in a module it is there. You can use an underscore in front of the method to signal that it is meant to be private but that is more a polite ‘please’ than a harsh ‘thou shalt not’. The philosophy there says that you won’t come to my bedroom, not because I am standing there with a machine gun, but because going there would not be nice.

What sun.misc.Unsafe misery teaches us is that it does not work. Sorry to say, but it seems you need to have a gun in your hand to prevent library users invading your bedroom. That is also what Lukas suggests: put all your library internal code into a single package and make all package private.

But there are also other approaches. If you look at Jira and Confluence and the extensions you can write you see a different approach. By natural evaluation Jira started small and the designers probably never dreamed about such a huge developer community writing all purpose extensions to their software. They simply did not define an API at all. There were the jar files, the classes in them and extensions were free to invoke any method of any class more or less. The result: every extension had to be tested against each version of the software and when you had an extension working with one of the versions of Jira it may not work with the next (minor upgraded) version. Atlassian had a long way to define an API that is stable and is “officially” available for extension modules. Do they put everything else into a single package? I do not think so. Instead they listen to their customers, they have developers forum and they do have empowered employees listening on those channels and understand the needs and their API provides features that are needed by the users.

And this is the more appealing approach. If you provide the features that the users of the library need, they won’t bother to go into the bedroom.

If you do not provide the features, they WILL come in. You can not prevent them doing that, just like you can not prevent teenage sex. If you do provide what they need, they will not use forbidden calls no non API classes.

This is actually what Sun and later ORACLE failed to do properly (imho). They did not provide the features and “unsafe” was just there. They warned us many times not to use that, but they failed to tell what to use instead. And now it all is coming apart at the seams. What will be the consequences?

What I see as most probably scenario is the following:

• Java 9 will come out without unsafe.
• Because many libraries make use of the “unsafe” package implementation the industry acceptance of Java 9 will be delayed. The enterprise standard Java version remains 8 (or 7 or 6 in some enterprises) for prolonged time.
• There will be signs of possible market loss for Java that will drive Oracle to give some solution.
• There will be some API developed by Oracle providing a limited set of features (most commonly used features) of the current unsafe feature set.
• Libraries will be modified within few months using the new API.
• Enterprises will skip to the version that supports the new API.

What I do not expect to change is the attitude of Oracle to customers.

We will see how accurate it was in … two to three years?

Advertisement

Why we do not use comments

When I learned PASCAL programming at TU Budapest in 1986 there was a preprocessor developed specially for student code. It stopped the compilation process if the number of inline comments was less than the number of executable code. There was a rule: we had to have at least 50% of the code meaningful comments. 30 years passed and now we fight inline comments. Clean code purists evangelize not to have inline comments at all and have unit documentation (JavaDoc in case of Java) only on the interface. Anything else explaining the implementation has to be self explanatory from the code itself.

That time there were even tools that extracted inline comments into documentation partially including the executable code. Can you recall WEB and TANGLE? That time it seemed to be very exciting to have a language that can be compiled to TeX for documentation purposes and also to PASCAL so the code could be executed. After 30 years we can see that was a dead end street. We do not mix programming and documentation. We rather separate them.

What is the reason for the change of attitude? Computer scientists 30 years ago were “stupid”? Were they advocating something that was and is bad? Or was that good that time and it is good now? Is there something that radically changed in the world and we live in a different world?

I was thinking about this recently and came to the conclusion that the answer is: A bit of both. The word “stupid” is a bit harsh and rude, but stating that computer scientists did not know as much as they do today is agreeable. After all that is development. If the knowledge remained the same it would mean we are at the point where we were 30 years ago. We learned a lot of things related to computer science. Many of these things are related to human science, and should belong to the area of psychology or something alike. That is one side of the dish.

30 years ago comments were demanded. Today we say that comments are bad among other reasons because they become outdated and misleading. 30 years ago the mantra was to keep the comments maintained along with the code and keep it up to date. Easy to say, but people tend not to follow that advice. For a while you can push the mantra and you can try to force people to keep their comments up to date but that is as futile as forbidding sex for a teenager. It is like trying to command gravity to stop and walk home dry while the raindrops float above your head. Human works differently and you can not alter human mankind. What is the solution we seem learned in 30 years? Adapt practice to what human can and will do.

If comments get outdated and misleading then it is better not to have any. On the other hand we need something to compensate for the loss of the feature comments provided. What we aim now is readable code. And this is the other side of the scale. This is something that changed in the world. We have new programming languages and new tools. If you were required to create readable code in FORTRAN or COBOL so that there is no need for inline comments you would be in trouble. Thus there was the strong push to comment. Those days the comments compensated for the language shortage and the outcome average was better including the misleading comments than naked code.

Today we have Java, Scala, C#, Go, Swift, Ruby, Python. All modern languages (sorry for those I missed) that make it possible to express the behavior and implementation in a readable and concise format that does not need comments. We also use unit tests, something that was unknown 30 years ago, which is more a documentation of the implementation than test. We use code to document, and ever less documentation going from waterfall towards agile. I hope that this is a good direction for some time and I look curious to the future.

Reasons to stay up-to-date and your tasks to help the senses

When you work in an enterprise environment you face many times applications implemented using outdated technology. And most of the developers agree that it is bad. It is bad not only because nobody loves to work with outdated technology but also because it is not good for the enterprise. Outdated technology is never so flexible as the new one, always has more development, maintenance and lost opportunity cost. You certainly have hard time to find an eclipse plugin for the actual version that supports struts 1.0 When there is some bug in the system you are less lucky to find a solution on open source boards. New environments produce easier to use user interface and are more flexible to develop features to follow the ever changing business needs.

All these seem evident and still enterprise environments usually contain a huge load of outdated software. Why? The reason is that change needs demand and the demand many time is lacking. A very good model for corporate change is from Kotter and it says that the first step out of eight steps for change is “sense of urgency”. If there is no sense then there is no action. There may be a need, but if people do not feel the urgency they will not change.

I recall an old story when I was working for Digital Equipment Corp. and we were requested to do a USA export training. We did not feel the urgency no matter how well it was explained why it is important for the company. On a day when the deadline was only a few days ahead I, who have not done the online training yet, got an eMail from the country manager: “Dear Peter, This training is mandatory. You or your successor will do the training. Sincerely: Ferenc” At that point I sensed the urgency.

There are other examples, like global warming, environmental pollution or me being overweight, all that will some time cost something more than just jobs or money.

Why did I tell this story? Because the situation in enterprise IT is similar. There is urgency for updating the technology, but there is a lack of sense. We pollute our environment with outdated technology, we face ever increasing (warming up) maintenance costs, more bugs that are harder to fix and many times a fix just causing other problems.

Technology people are in the position to help the senses. Albeit not exactly the same way as our country manager was doing. Those that are aware of the urgency should make documentation, presentation or any other effective way of communication to deliver the knowledge to those that should have the sense (of urgency) and to raise awareness.

If you are a good developer you should be able to communicate this to the business people. You can convince them to update the technology or else you will face dramatic change in the economy of the company. It may cost jobs and it may cost the enterprise in the long run. That is a problem. Not a tragedy, but a problem. If the company is on the decline and the shareholders decide to squeeze the last drops out of it but are reluctant to invest, the decision not to upgrade to a newer technology may be absolutely reasonable. On the other hand, as a developer you may not want to work there. On the other hand if the company is not on decline but the shareholders still decide not to invest into technology then actually the company is on decline. It is just that they are not aware of it. And again as a developer you may not want to work there.