Did you know? DZone has great portals for Python, Cloud, NoSQL, and HTML5!

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of http://welshare.com . Worked on Ericsson projects, Bulgarian e-government projects and fish4 (http://fish4.co.uk). Currently working for Trinity Mirror Digital Recruitment. Member of the jury of the International Olympiad in Linguistics and the Program committee of the North American Computational Linguistics Olympiad. Bozhidar is a DZone MVB and is not an employee of DZone and has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

Why I Like The Verbosity of Java

01.11.2012
Email
Views: 5780
  • submit to reddit

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.

 

From http://techblog.bozho.net/?p=742

Tags:
Published at DZone with permission of Bozhidar Bozhanov, author and DZone MVB.

(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

Thanks a lot for your post. You are absolutly right : java force you to learn how things are done. In a certain manner, it's like Debian. When I want to be concise, I use Groovy.

Ramasubramanian... replied on Wed, 2012/01/11 - 5:10am

I agree, Java gives us the internals (atleast not low level stuff) but to some level for learning. We should use Java to learn and other JVM languages like Scala/Kotlin/Clojure to use in work since we cannot waste time by writing code to handle generic problems.

Pavel Tavoda replied on Wed, 2012/01/11 - 6:20am

More, more and denser. I'm tired of reading and speaking to people which complain whole day about Java. Scala is better, PHP is better, nearly everything is now better than Java - for them.
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

I agree, and in fact, this is a good reason why Java must be the OOP language to teach in School. It exposes the machinery, it makes you understand concepts at a deeper level. And for the times you want something less verbose, less boilerplate, there are frameworks and libraries ready to use!

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

You have a point here. I still think that the Java I'm using today professionally (5 & 6) is still too verbose. Luckily they're working on it. Java7 does address it and Java 8 will address further a lot of the useless verbosity issues. Furthermore, I think that people shouldn't focus on number of lines, just like a developer productivity shouldn't be measured in number of lines. Readability is, IMHO, much more important: how much time will it take an average developer to understand your code. That what it's all about, isn't it?

Victor Cisneiros replied on Thu, 2012/01/12 - 8:04am

By that logic you should be using Assembly instead of Java because it forces you to learn how computers work :)

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

I agree -- Groovy is the best bridge language when it comes to reducing verbosity in Java code. Just remember -- more hand-written code, more time and more bugs (likely).

Adrian Engler replied on Thu, 2012/01/12 - 11:00am

Of course, as far as verbosity IO is concerned, Java 7 is a big improvement, and Java 8 will improve the situation in other areas.

Bob Jones replied on Thu, 2012/01/12 - 11:01am in response to: bitstorm

Andrea, you have perfectly succeeded in contradicting yourself.

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".


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.