InfoQ was fortunate to recently speak with Cay Horstmann regarding the current state of Java affairs in conjunction with the release of his latest books: Core Java, Volume 1 & Volume 2, Ninth Edition.
Java has undergone numerous changes since its original release in 1995, from growth in the language specification to a change in ownership when Oracle acquired Java as part of its purchase of Sun Microsystems. Our conversation begins with a discussion of how Oracle has managed their management of Java.
InfoQ: What do you think about Oracle's management of Java thus far? I am thinking of both language features but also the business side, such as the decision to bundle a 3rd party Internet browser toolbar with the JRE installer.
Horstmann: I wasn’t happy about the bundling of that toolbar. Oracle has been really inconsistent here. On the one hand, they've been putting a ton of resources behind improving Java. On the other hand, they do unfortunate things like this. They've also mismanaged the security aspects for a long time, and are only now catching up. I think their stewardship has been a mixed blessing.
And when Oracle makes a questionable decision, there is no discussion with the community. When you talk to people in the inside, they say, "Oh, my hands are tied. I can't say anything." With Sun it was never like that. They were always much more open and when something didn’t go well, they would cheerfully admit that they needed to do a better job. But I guess that's the culture at Oracle.
InfoQ: So they kind of deny a problem until they have a solution available?
Horstmann: I guess that's a very good way of putting it. It's annoying. Also, another thing that I think many people held against Oracle, is their lawsuit against Google.
InfoQ: Yes, that's a good point. I guess you could say that Android was acting like an ambassador for the Java platform as a whole. With Google choosing Java, it increases demand for Java programmers, increases overall Java market penetration.
Horstmann: Yes, absolutely. And it's not that they had inherited any useful market from Sun. For a couple of years Sun kept talking about Java ME (Java Platform, Micro Edition) phone as somehow viable when everyone saw that ME was doomed to extinction. And they never had a smartphone strategy.
InfoQ: You are not only an author, but also a college professor who teaches computer science. Is the demand for teaching Java student-driven from a desire to learn how to do Android development or is it based on a directive from you or the university?
Horstmann: Well, in the university there's a significant cost involved to introducing a new language in any course. It takes longer than a semester for students to be comfortable and really productive in a language. When we design a curriculum, we have to pick our battles. Java does have an enormous range of applicability. You can start with it in basic assignments and then use it in your database course, in your networking course, and the mobile course, with Android, of course. We're pretty Java-heavy for that reason. Also, at the university we feel it's not our job to teach the students ten languages, but to teach them the concepts with several representative languages. We teach them Java, C and a functional language.
InfoQ: What language(s) do you use for your mobile course?
Horstmann: I want the students to have some experience with iOS because more than half of them have an iPhone in their pocket. And they of course are curious what it takes to put an app on their phone and into the app store. So about 50% Android, about 30% iOS and 20% HTML5 (JQuery Mobile, PhoneGap).
InfoQ: So you split it up and what was the feedback from the students?
Horstmann: First of all, they really did appreciate getting the multiple perspectives. They thought that was very useful. But in the end, they vastly prefer to work with Android.
InfoQ: Where do you think that leaves the future of Java—primarily an Android-based one?
Horstmann: On the server there's still a lot of Java -- mostly in big shops. I look at the startups around here and a lot of them don’t use Java. I'm not even sure if they have a particular reason. I talk to people and I say, "What's so great about (your technology choice) that you couldn’t just be doing with Java?" And they say, "Oh, I don’t know. I don’t know the Java stuff." There's a whole generation of young kids at these companies who don’t know server-side Java. For someone like me who likes Java that's a bit worrisome. And Oracle has not really done a great job convincing people that the latest Java is actually very pleasant to work with. It's not the rocket science stuff that it used to be. These days, Java EE is easy, and the tool support is tremendous.
InfoQ: Java’s “It” factor is not there in a sense for startups?
Horstmann: I think Oracle tends to go into the big organizations where someone is going to buy expensive services. But a lot of innovations, particularly in Silicon Valley, happen with the little outfits. And so when I talk to those people, they use Rails, they use Node.js. They by and large do not use server-side Java. And like I said, it's not always for a good technical reason. Sometimes they don’t even know what they're missing.
InfoQ: Looking at the most recent version, Java 7, and the forthcoming Java 8, do you think Oracle is doing anything to address the “hip factor”, or with areas like the server-side benefits is it more of a marketing problem?
Horstmann: I really do think that server-side Java has a marketing problem. There is a large market for server-side development in a language that's well managed, that's comfortable to deal with, that has great tools. But few people open their mouths and say, "You guys should give Java a try. You might be more productive starting with Java than hitting a wall with (seemingly popular technology X) after a couple of years."
InfoQ: That is a good point. The issue for small shops seems to be whether or not they switch from Node or Rails to a "more serious" environment as their application hits explosive growth.
Horstmann: Yes. And I think the fear of Java EE Is unfortunate. Even for small projects, I just start out with Java, and it's always been fairly fast and painless. Now I don’t do something that has the scale to ten billion users. I usually have something that has a few thousand or tens of thousands of users. But I've seen a lot of people who no matter how small or how large, automatically use Rails, for example. And then you have to find people who know Ruby. It's a whole new set of technologies. It's actually easy to find people who know Java.
InfoQ: Now, when you say that, is that coming from current developers or from those fresh out of college?
Horstmann: Fresh out of college. Java is so ubiquitous in education, whereas it is much more difficult to find someone who knows Ruby from a college course. Either they were self-taught or they learned it on the job.
InfoQ: How well do you see Java changing with the times?
Horstmann: Any language that wants to stay alive needs to be able to pick up features that everyone finds essential nowadays. Now, in a world of concurrency, you want to have more functional style libraries. This wasn’t doable without the Java 8 features, which are pretty nice. When I compare it with what I have in Scala, sure, Scala is nicer but Scala has other issues. It's more complex.
InfoQ: Well that raises the idea that Scala users really enjoy the JVM as a platform but don’t want to use Java.
Horstmann: If you know what you're doing, you are more productive with Scala. You can express your ideas in half the lines of code or less. And approaches that you would never attempt in Java because they're cumbersome, are easy in Scala. On the flipside, while I love Scala, I also fear it occasionally. If you make one wrong move, you’ll be scratching your head for a while.
Java is, for the most part, simple and consistent. I can't remember the last time I asked myself what the statements in my Java program do behind my back. And that's a valuable feature.
InfoQ: Especially when in a corporate environment or on a team it probably means things are larger than just a couple of individuals. It makes it more difficult for someone to keep it all in their head. That predictability is necessary …
Horstmann: Indeed. In contrast you can't comprehend all of C++11 in your head. That's a huge language.
InfoQ: What about languages like Ruby, I mean you're able to just start writing right away and then --
Horstmann: Ruby by itself does not give you much direction. Rails is really what keeps you regimented. I could give you Ruby puzzlers where you would scratch your head for days, and the experts would say, "Oh, two years ago it was working this way. Right now it's working that way."
InfoQ: Do you think some of those frameworks for Java that mimic Ruby on Rails are effective as far as taking the best of what Ruby on Rails offers and providing it for use with Java?
Horstmann: Keep in mind that Rails solve lots of problems that nowadays aren't always necessary to solve. If you have a user interface on the client via a mobile device or a tablet or HTML5, with JavaScript doing the rendering on the client, you are not interested in Rails' HTML templates. So it's not clear that, going forward, Rails is going to have the growth that it had.
InfoQ: Well, looking at your book again, how do you tackle writing about Java given the size of the language? Now you've broken it into two volumes, but how do you go about covering the language given how big it is today? How do you decide what to cover?
Horstmann: Originally the book got so big because the mandate was to cover everything. When the book was first designed many years ago, everyone wanted to know Swing. And RMI. And I think this is the last edition that tries that. So the next edition, the Java 8 edition, I'm just going to have to focus on what people actually want to do. I can't imagine that Swing is going to be there in the next edition. Or RMI. When is the last time you used that?
InfoQ: When looking at this book, it is pretty clear that while this is not a starter edition, it does cover the whole language. Do you see that new developers or people using Java appreciate that or do they just stick to volume one?
Horstmann: More than half of the people don’t have the physical book anymore. When I look at where the sales are coming from, a huge amount of it is actually through Safari Books Online. Programmers go there and read a few pages at a time.
InfoQ: The size doesn’t matter to them - I mean it may matter to you as far as keeping the book organized but readers don’t care about the size because they can pull up what they want.
Horstmann: That's right. Also, if the next edition doesn’t have Swing, Safari still has the previous edition. So it's not the end of the world. It's actually been stunning to me how quickly sales have migrated to electronic copies. It has been going on for a while in the computer science market.
One of the things that I don’t try to do anymore is long examples that can't be understood in isolation. Some books do this in every chapter. They build out their examples more and more, and that makes it really hard to dive in somewhere in the middle.
I try to make the books accessible so that someone can come right in to a chapter or section of interest, and then be able to follow it without having read the six chapters before that.
InfoQ: You mentioned that you're looking ahead already to Java 8. What major features do you think are needed or should be talked about?
Horstmann: Oh, definitely, lambdas are big. The changes in the collection library are big. It's going to make it much easier to do common things. And the concurrency changes are really important. You want to be able to take advantage of multiple cores without making it difficult for programmers. With Java 8 and Scala, that works beautifully. The programmer says, "Oh, I want all of this stuff done in parallel." You just have a parallel view, you operate on it by doing a Linq-like query, and you get parallelism for free. So I think that's going to be very important.
InfoQ: Do you think there is a need to... (while researching I saw that there might be commonality)... have primitives eliminated?
Horstmann: It would be so nice. Years ago I asked Neal Gafter who was at the time working at this problem. I asked why this hasn’t happened when the primitive types added a whole level of complexity with generics? He said was there was a reason why you couldn’t just equate an int and an Integer. Someone out there had made integer objects like new Integer(42) and used them as locks! And so, if you can no longer distinguish two different new Integer(42), that individual’s code would have broken.
An absolute guarantee to remain backwards compatible seems unreasonable. You really want that int and Integer are interchangeable, and that distinction is something that the VM should be able to optimize for you.
Also, to change between an array of ints and an array of integers, the VM would have to work pretty hard.
In hindsight, integers and floating-point numbers should have been objects from the very outset, but 20 years ago, primitive types sounded like a good idea.
InfoQ: When you are bringing up Java for the first time to students, do you use Integer just because it's there?
Horstmann: No, I use int because there are so many libraries where they see int. I don’t really spend a lot of time on the distinction. With collections, they have to worry about wrapper classes. In practice, it's not that big a deal. How many times do you actually collect a bunch of integers with an ArrayList?
In the end, if you think about what made Java what it is, Java has two things going for it. One is that it's a blue-collar language that you don’t have to have a PhD to understand. And the other one is that it always had a humongous library. For anything that you would ever want to do, there seems to be a Java library.
There are not many languages with such an extensive library. Python, for example, is a nice language but in comparison to Java, the Python libraries are rather limited.
The other thing about Python is that it makes you appreciate the backwards compatibility of Java. I applaud Python 3 for its regularity and elegance, but I am amazed how long Python 2 is hanging on, and having both is not pretty.
InfoQ: Having a large legacy code base can pose problems...
Horstmann: With Scala, they're ruthless. It sometimes seems as if every six months everything you did is broken and you have to redo it.
InfoQ: Really. There was a lot of that?
Horstmann: Oh, yes. So at some point they're going to have to stop it. But right now Scala is not binary-compatible, so you have to recompile everything. And there are enough feature changes in the language that there's a good chance that you're going to have to fix something as well.
InfoQ: That's good for language growth but not with adoptions.
Horstmann: Right. And that's why that at some point they're going to have to say, "Okay, we've had fun enough and now we're going to have to stabilize it."
InfoQ: Well, looking at Java as a whole, what is the biggest obstacle you would like to see overcome if you were in charge of the language? (Either removed or changed for the better.)
Horstmann: Probably primitives types. It's super annoying just because it adds a lot of complexity. What else do I truly hate that I want to get rid of? I have never really asked myself that. You know, it's not so much the Java language. But I hate the slow startup time. I hate that it precludes Java from being used for scripting. And that is something that I feel has never really been addressed. I hope Oracle will address that with modularity, maybe in Java 9 or maybe my grandchildren will live to see it. It is an issue that limits the width of applicability of the language.
And the other thing that has nothing to do with the language per se but rather the environment is the security issue --- we are losing users because Oracle can't update the client JVM as they should. No one has complained about Flash insecurities because Adobe has figured out how to get you a new version every three weeks. But with Java on my Windows machine, every time that I turn it on I get a little icon that Java needs to be updated; then when I click on it, I get some error message that it couldn’t do it. And after all these years, they still couldn’t fix that.
InfoQ: I never thought of comparing the two that way and that is a good point. Adobe seems to have the better approach compared to Java's runtime.
Horstmann:Yes. You just click a button and Flash is updated. But with Java, it is broken. It just doesn’t work. I look at my students and there's some graveyard of old Java versions on every student's machine.
InfoQ: For active developers I guess it's easier to look at what's installed and get it corrected, but certainly if I was trying to diagnose it remotely it would cause confusion.
Horstmann: Exactly, yes. And then you might diagnose and then what remedy do you give a regular user? "This would be a really good time to reformat your hard disk?"
InfoQ: Anything else you would like to change?
Horstmann: Well if you ask me what language feature is so bad that it should be gone, there's a couple of features that I never use like labeled breaks that I wish weren’t there. I'd remove them just to reduce accidental complexity, but I don’t use them so they are not really in the way. But otherwise, it does speak for the design of Java that there isn't anything I'd want to remove. As for adding features, the other thing that I wish Java had that I would kill for is properties. I hate writing those getters and setters.
It's not like solving world hunger, but it would be nice not to have the boilerplate. One thing that I love about Scala is that you can write a trivial class in just a couple of lines of code.
InfoQ: That would address the boiler plate type code that Java is accused of.
Horstmann: Yes, but let's put it in perspective. When people say that Java is the new Cobol, let's remember where Cobol was when Java was born. Cobol really was at the verge of death. I still remember when more than half of the world's programmers were working on Cobol, and a few years later no one was working on Cobol any longer. That transition was very, very fast. And with Java, I think there are still so many things that Java can do that really don’t have an equal; in particular, having a world-class virtual machine that's portable. For these reasons, I think that Java is going to be around for a bit longer.
The other thing is that when Cobol died, there was something much better to replace it. Right now, I mean, what is so much better that everyone would flock to it? I mean there's nothing else that makes you say “hallelujah”.
InfoQ: Yes, that's a good observation. I mean look at some other languages. For example, C++ now seems to be revitalizing itself yet this is drawing the most attention from within the C++ world.
Horstmann: Do you want to code in it?
InfoQ: If you're a C++ person, you might be feeling better, but I don't know if that is enough to keep attracting new developers. If you look at C#, a lot of those users feel that it is better than Java, yet many are developers who feel that Microsoft may be ignoring C# in favor of newer technologies.
Horstmann: C# is Java, for all intents and purposes. It has a few features that Java doesn’t have but Java could have those in a jiffy if it was important.
InfoQ: But there doesn’t seem to be enough for Java developers to switch en masse. If you're a C# guy, you're happy. But, right, most camps have already divided up. New developers are not coming from those. I guess after that you just have all the - I don’t want to say fringe in derogatory sense but the...
Horstmann: Niche...
InfoQ: Yes. Different size, different competing tribes of languages.
Horstmann: Yes, at this point, there is no one language to rule them all. It might come. When you find it, let me know and I'll write the next book.
InfoQ: There are new languages, and some are popular at least at a low level, but nothing really catches on in widespread popularity. There are critics and defenders of every language right now, but there's no real mania or just push for anything.
Horstmann: And it's tough. I mean it's not just the language anymore. Nowadays, people expect a good size library. They expect a virtual machine. The time of languages that run directly on the bare metal are over. There are optimizations that you can do with a VM that a language like Objective-C could never hope for. JavaScript runs pretty well because they've jazzed up the virtual machine.
InfoQ: It's almost there's two different major pools. There's one pool of the statically typed and the kind of plan more language. And then there's the "I want to write something really fast, as fast as possible". And there's overlap but there's not a commonality anymore.
Horstmann: That's a good point too. And I do think that statically typed languages have a lot to offer. Look at what Google has been doing with Dart. They try to bridge static and dynamic typing. That's certainly an interesting way to go. But are those going to be contenders for the next language for everyone? I think Java is going to be going strong for a while.
InfoQ: It seems like every time Java has a quiet period or lull a new technology pulls it through. It started as you know with applets and that seemed like a big breakthrough. Next was probably the original web apps backend and now Android. It seems that Java has always had a champion that arrives and pulls the language forward.
Horstmann: And the other reason why actually Java may be around for a long time is that it is open source and its patents are going to expire fairly soon. Whatever you can say about the patent that is one of its beauties- that eventually those 20 years are up.
InfoQ: That might be the next champion right there. I appreciate your time today, thanks again and best of luck.
Horstmann: All right. Well, thank you very much.
About the Interviewee
Cay S. Horstmann is author of 'Core Java Volumes 1 & 2', 'Scala for the Impatient' (Addison-Wesley, 2012), and coauthor of 'Core JavaServer Faces', 3rd Ed. (Prentice Hall, 2010) He is professor of computer science at San Jose State University, a Java Champion, and a frequent speaker at developer conferences.