Why I Like The Verbosity of Java
Java is too verbose, they say. You can find comparisons of Hello World programs that take 2 lines in ruby and 10 lines in Java, and in order to read a file you need 20 lines in Java and just 1 in php.
Even though the examples are often exaggerated (for example counting imports), it is true Java programs requires more lines of code. But this is not a bad thing at all. On the contrary – it is something I actually like. In fact, it is not about the verbosity of the language – apart from anonymous classes-insteadof-closures, there is nothing else that the language is too verbose about. It is about the core libraries. So – I like the way the core libraries are written in terms of verbosity. Two examples:
- take the java.io. package. Reading and writing files, streams, etc. It is a bit hard to graps, and in the beginning you copy-paste long snippets of code to simply read a file. But it forces you to understand the abstraction of streams and readers. Other languages have simply: var contents = readFile("path") Cool, but you are never forced to understand how the I/O management works. What happens if reading fails? Is partial reading of the file sufficient for you? Can you nagivate the file? Should you close resources or they are automatically closed? You don’t need to answer these questions for a hello world program, but you will need to know about them pretty soon. And the less-verbose languages hide them from you and postpone this “abstraction revelation”.
- the servlet API. At first it looks to have some hairy classes and interfaces. But soon enough you realize how the whole thing works – not only in Java, but the general lifecycle of an http request. Because you need a Servlet object, and request and response objects, and output streams to write to, you understand the whole request-response cycle. I have a personal example here. I’ve been writing PHP for one year (in school). Then one month of Java and servlets made it completely clear for me how the whole thing works. PHP was very easy to use – $_GET['foo'], session_start() and a bunch of HTML in between. So I didn’t bother to understand the underlying mechanics. Java forced me to.
You may argue that – fine, it forces you to learn these important concepts and abstractions, but it should also give you an easy way to acomplish things. But if the core libraries themselves had these options, all the tutorials would show these options, and the lower-level APIs would be forgotten. So the solution is – 3rd party libraries. Apache and Google give you these. With guava and apache commons you have all these one-liners. FileUtils.readLines(..), Joiner.on(",").join(array), etc. But you don’t start with these libraries, and you learn how things function on a slightly lower level – a level that you will be required to know anyway.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)





Comments
Philippe Rostai... replied on Wed, 2012/01/11 - 2:52am
Ramasubramanian... replied on Wed, 2012/01/11 - 5:10am
Pavel Tavoda replied on Wed, 2012/01/11 - 6:20am
I have to say only. Java is great language. I can write everything with it. System utilities, GUI, web applications. Small application, huge application, libraries, toolbox, ... . Java is wonderful and will be hard to find better general language than this.
Thanks you for this article.
Andrea Del Bene replied on Wed, 2012/01/11 - 7:26am
I couldn't agree more with this: "apart from anonymous classes-insteadof-closures, there is nothing else that the language is too verbose about."
The abstraction introduced by streams and readers may be "verbose" but is a perfect example of good design choices.
Moreover with Java 7 we have a new fantastic java.nio.file package which solves much of "verbosity" problems.
The Nonhacker replied on Wed, 2012/01/11 - 10:37pm
David Whatever replied on Thu, 2012/01/12 - 2:53am
I disagree. Other languages like ruby or python expose just as much as the low level system to you; they just happen to also try to make you more productive. As soon as you need to read files in more than one place in a program, whats the first thing you do? You create a readFile method. However, your readFile may be significantly slower due to things like a lack of knowledge of block size, using inappropriate data structures for saving the data.
The knowledge you need to make many of the decisions around how to read from a file are not going to be found in javadoc, you will either be reviewing posix/win32 internals or other people's java code trying to scour insight out of their source
Dirk Estievenart replied on Thu, 2012/01/12 - 4:25am
Victor Cisneiros replied on Thu, 2012/01/12 - 8:04am
Adrian Engler replied on Thu, 2012/01/12 - 10:51am
It depends - of course, it may make sense to understand a bit more about accessing files and web requests/responses. There may be situations in which it is appropriate to use the readers / writers / streams in java.io directly. However, in many cases, we perfectly understand how that works, but just want to handle a simple case quickly and then Java with just the standard libraries is too verbose.
On the other hand, I don't think this verbosity is a big problem. Just use Guava or libraries from Apache commons, and the contents of a file can also be read into a list with one simple line of code. Many of the comparisons that show that Java is alledgedly too verbose in comparison to other languages would loose much of their force if "Java" is meant to be Java plus Guava or Apache Commons, and for many programmer in practice that is Java. With the exception of closures, which will be added in Java 8, I don't see a problem. It might be a slight disadvantage that the contents Guava or Apache Commons are not directly in the standard library, but it practice, this is not a problem, and competition (e.g. between Apache Commons and Guava) can always be good.
Bob Jones replied on Thu, 2012/01/12 - 10:59am
in response to: proutt
Adrian Engler replied on Thu, 2012/01/12 - 11:00am
Bob Jones replied on Thu, 2012/01/12 - 11:01am
in response to: bitstorm
Andrea Del Bene replied on Fri, 2012/01/13 - 7:40pm
in response to: bootz15
Why? I've said that an I/O based on Streams and Readers is extremely flexible and well designed. However this is a general solution and I agree that until ver. 7 Java lacked of a standard library to easily manipulate files.
But the lack of a library doesn't make a language "verbose".