Java 9: The Good, the Bad, and Private Interface Methods
Java 9 sees some changes and new features added to it, but are they all for the best? See what's in store for you, what might be good, and what might be not-so-good.
Join the DZone community and get the full member experience.Join For Free
java 9 was released a few weeks ago. check the release notes , they include many interesting features. however, i think that not everything is as good as oracle and java adepts seem to picture it . i see three trends in the java world, which are good, bad, and ugly, respectively. let's start with the good one.
the first trend is an obvious improvement of the platform that compiles java, packages jars, and runs the bytecode. it definitely becomes better with every new java release. here is a list of improvements java 9 made, which are very useful, without a doubt:
- jsr 376 : module system a.k.a. jigsaw
- jep 238 : multi-release jars
- jep 158 : unified logging
the platform is obviously becoming more mature. this is a good trend.
the second trend, which i've observed since java 6 , shows that the jdk, which is essentially a collection of classes and interfaces designed, developed, and maintained by oracle , gets bigger with every new release. in java 9 they added and extended, besides others, the following:
- jep 221 , 224 225 , 261 : javadoc processing (extended)
- jep 268 : xml catalogs (new)
- jep 262 : tiff image i/o (new)
- jep 251 : multi-resolution images (new)
- jep 110 : http 2.0 client (new)
- jep 236 : parser for nashorn (extended)
of course, some features must be implemented in the jdk itself, like unicode support ( jep 267 ), platform-specific desktop features ( jep 272 ), spin-wait hints ( jep 285 ), compact strings ( jep 254 ), and the process api ( jep 102 ). their implementation depends on the underlying platform and has to be provided together with the jvm.
but what is http 2.0 client doing in the jdk, together with jax-rs , jpa , jax-ws , jdbc , and many other things that, in my opinion, should stay as far away from oracle as possible? they are not platform specific and they can be, in a much better way, designed by the open source community as independent packages. aggregating them under one monster umbrella brand is a mistake, i believe.
i think that big corporations are only killing the software market, instead of making it better, because of the financial and political motives they expose it to. that's exactly what is happening with jdk. thanks to the oracle monopoly it lacks flexibility and dynamicity in growth. in other words, we're stuck with what oracle and its big friends think is right .
thus, making jdk bigger is a bad trend. instead, i believe, oracle would only benefit from making it smaller, delegating everything that is not platform-specific to the open source community, supporting programmers somehow and promoting open and effective standardization processes on the market.
java was developed by james gosling in sun microsystems in 1995 as an object-oriented language. there were many concerns about this claim of object-orientation and i'm also not sure that java is more oo than it is procedural. however, it is officially object-oriented.
there were many procedural features inherited by java from c/c++, since its first version, including static methods , null , implementation inheritance , etc. it was not a perfect object-oriented language and it was not going to be one, as i understand it. the key idea was to create something that could be written once and ran anywhere . however, the language was a big deal also, not just the jvm. it was simple and sexy.
java 5 made a serious step forward in 2004 and improved the language by adding generics , for-each loop, varargs , and static import. however, annotations and enumerations were introduced, which helped the language to divert from the object paradigm to something completely different and procedural.
java 7 added try-with-resource in 2011, which was a good move, in line with the oop paradigm.
java 8 added lambda expressions in 2014, which was a great feature, but absolutely irrelevant to oop. lambda and streams api turned java into a mix of the object, procedural, and functional paradigms. default methods were also added to interfaces, which turned types into libraries of code. types into libraries! it's even worse than implementation inheritance , if you ask me.
now java 9 made the next "improvement" to interfaces, allowing them to have private methods. private static methods in types! can you believe it? what will be the next step? attributes, in java 10, i guess.
also, let's take a look at what was done to some core classes in the jdk, to understand where the language is heading. just two examples.
factory methods for collections ( jep 269 ). instead of introducing new constructors and allowing us to do this:
...in java 9 they created more static methods and made us do this:
"fewer constructors, more static methods!" seems to be the philosophy of those who introduced this jep. needless to say that this is completely against the very spirit of object-oriented programming. objects must be created by constructors, not static methods, no matter what joshua bloch
. static methods make the moment of operator
usage invisible for us and that's why the code is way less maintainable—we simply don't know exactly what class is instantiated and what the real arguments of its ctor are.
by the way, with cactoos you can do it the right way:
this is oop.
new methods in
. three new methods were added to the already
. now we are supposed to do this, when we want input stream to copy to an output stream:
it's one of the most typical mistakes young oop programmers are making: they make their interfaces big. just because they need more functionality. i guess the
interface segregation principle
is part of the famous
and is many years old. what's wrong with you, oracle? what will the next step be? in java 10 we will also have
? how about
this is oop.
in my opinion, java is getting uglier , and this is a trend. does it mean that it's time to quit? no! no matter how ugly you are, we will always love you java!
Published at DZone with permission of Yegor Bugayenko. See the original article here.
Opinions expressed by DZone contributors are their own.