Trisha Gee on the Java Eco-System
Recorded at:

| Interview with Trisha Gee by Ralph Winzinger on Jul 17, 2015 | NOTICE: The next QCon is in New York Jun 26-30, 2017. Join us!

Bio Trisha Gee has developed Java applications for a range of industries, including finance, manufacturing, technology, open source and non-profit, for companies of all sizes. She has expertise in Java high performance systems, and is passionate about enabling developer productivity.

Sponsored Content

Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.


1. Hi. My name is Ralph Winzinger. I am a software architect and editor for InfoQ. I am here at QCon New York 2015 and I am with Trisha Gee. Trisha, would you please introduce yourself to our watchers and readers?

Sure. I am Trisha Gee. I am a technical advocate at JetBrains. What that means is that I get to go and talk to people about how to use our tools. So, since that includes IntelliJ Idea that means I get to do Java programming at people all the time, which is very cool.


2. Yes, it sounds cool. You had a talk today about Java 8 and it was called “Java 8 in anger”. So, what is so angry about Java 8?

I chose that title because it makes sense to me as an English person and then I basically travel around the world with it and everyone is like “I do not understand. Why are you so angry about Java 8?” No, “Java 8 in anger” means “in practice”, like “in real life”. So then everyone said “Why did you not just call it “Java 8 in real life” then?” Because it is no fun that way. It does not mean typing really angrily “Oh, all these Lambdas!” It just means “in real life”, in the context of actual application, what Java 8 really looks like when you are working with it.”

Ralph: I was already afraid you do not like Java 8.

No, it is awesome. I like it a lot.


3. If you ask people about what is new in Java 8, then most of the time you hear “Oh, it is the Lambdas and it is the Streams”. That sounds like that just a little bit has improved, but what does this improvement mean for a Java ecosystem?

Firstly, there is more than just Lambdas and Streams in Java 8, obviously. There is DateTime and Garbage Collection stuff and Security and Mission Control and loads of really cool stuff. But, Lambdas and Streams are the most common ones because, as developers, they are the ones that are going to have the most impact on us.

So, it changes the way we think about code or it should change the way we think about code. For example, previously, we had Clojures because we had anonymous inner classes, but no one uses them because it is like 10 lines of code for really a couple of lines of code. And now we have Lambdas – we can stop thinking about how to pass behavior around, which means that instead of having to encapsulate everything inside an object and thinking “Exactly, how does this object look?”, we can start thinking about little bits of behavior that you might call “functions” and do something a bit more functional-style with it.

So that changes some of the paradigms, it allows us to use some design patterns in ways which we have not been using them before. And Streams is also interesting because it lets us look at data, maybe even big data type of stuff and do some analysis of the big collections, we can do filtering, sorting, mapping, and all these things, in kind of a nice, expressive DSL type of way, instead of having to do a for-loop and then going “OK. Do not put one of these in here, but then put this in this sub-collection and then sort that stuff”. It just makes it a bit more expressive, in smaller lines of code and you can also take advantage of the JVM optimizing some of that code for you.

Ralph: Besides the both of them, what is your favorite feature in Java 8?

I think the new Date and Time.

Ralph: Really?

Yes, because the old Date and Time was so horrible. I am so sorry Oracle people. But, yes, it was pretty nasty to work with and you are working with a Date object and you think it does one thing and there are deprecated methods on it and especially when you are doing testing on things, you want it to create dates and figure out how to move time around. It was very difficult in the old world. Now, we have a new Date and Time that has a very expressive way to build up all the types of dates and durations and things we want and it is just much simpler to use and much more intuitive. But, it took a lot of hard work, I think, to get it that way because I know there were loads of HackDays on the API, lots of feedback went back to the designers of it trying to get it right for the developers. And I think that is really interesting because this is an example of how developers can actually help influence the direction of the language directly, by doing HackDays and feeding back and things like that.

Ralph: It took about 20 years to get a good Date Time.

Right. Exactly.


4. Also, the concept of Lambdas and Streams are really as old as computer science is. Why did it take so long to show up in Java?

I do not really know, but I think that partly, you always end up in silly syntax wars, right? What should it look like? Well, what does it matter as long as we have something that does the job? Like I said: we used to be able to use anonymous inner classes for the same sort of function anyway. So, we did have some of those features to begin with, it is just that they were not super useful to work with. I think it takes some of the other JVM languages using these things “in anger”, in the real world and seeing how developers interact with them to produce that kind of maturity that then Java, the language, can embrace. Because obviously, with Java, it is used by a lot of people, all over the world, backwards compatibility is very important to it. So, they do not want to get something wrong because they will not be able to change it, like Date Time for example. So, it is really good to see people who design Java the language looking at the other JVM languages, figuring out what works, what does not work and taking some of those best things and then having a lot of discussions about what the syntax should look like, how should we implement this, what are the performance implications and how can we make sure that we do not break anything too badly going backwards.

Ralph: It's not a competition with the other languages and also the JVM languages, but it is the experience that is absorbed to introduce new features.

Right. Exactly. People often ask “How is Java going to compete with something like Scala or Clojure or Groovy?” The answer is really that it is not there to compete with that because those languages have got their own niches. I think Scala is trying to grab all the niches, but they have their own places and they have developers who use them for particular things and Java has its own place as well. It is always going to be a big enterprise language, which is always going to be suitable for people who want something which is backwards compatible forever. So you can’t take everything from these other languages and put them into Java. You are also not going to compete with those other languages because if you want something which is dynamic, if you want something which is kind of scrypty, use Groovy. Do not try to implement that stuff on Java. There is no point.

Ralph: So, interacting would be the way to go.

Right. Exactly. And it is really nice to see the JVM languages that interop so that you can quite easily write. I have a lot of Groovy tests that just talk directly to the Java stuff. So, Groovy is very appropriate for testing in the sorts of circumstances that I am looking at and it talks directly to Java. It is still working on the same JVM, so I can use the right tool for the right language.


5. Sounds good. Is there a feature you are still missing in Java right now?

I am not really a polyglot person, so I have been a Java person for ages. So, I did not know I was missing Lambdas and Streams until I got Lambdas and Streams. I will say that, having done quite a bit of stuff on Groovy for the last couple of years, previously, when people said that Java was very boilerplate heavy I was like “Well, whatever, just get over it. It is Java. You get used to it.” But after having used Groovy for a bit, I really like the succinct map syntax and creating lists and things like that. So, some of the boilerplate around dealing with maps and dealing with lists, it would be nice not to have those in Java. I don’t know if that is ever going to happen, but that is kind of my limited experience in using other kinds of languages. Just some of that and removing the unnecessary noise would be quite nice.


6. You mentioned backwards compatibility as one of the focus points of Java evolution. Is it also the reason why Java is slow in evolution and would it maybe be healthy or helpful to really do a cut and introduce a really new version of Java?

I used to think that it would be really cool to have like a genuine Java 2, not 1.2, but 2. And then you can delete the deprecated code and you can move stuff on and not be weighed down by all the stuff that is already there. I no longer really think like that. Maybe I spent too long speaking to Oracle guys, I do not know. I have been listening to these talks and I am like “Yeah, good point” But the other day, I wheeled out some of my old code that I wrote in 1999 and it would have been Java 1.1 and I was using Swing. At the time Swing was coming into 1.2 and you had to use as a library in 1.1. And I got that running in Java 8 and I did not have to change anything apart from some of the imports because Swing was now part of Java. That is very compelling especially if you are a large organization like a big bank or a big manufacturing firm – you do not really want to be thinking “Oh, my goodness. When the next version of Java, we have to rewrite all of our apps.

We have to rewrite payroll, we have to rewrite inventory” These are core systems that these organizations work on and you do not want to rewrite everything just because a new version of the language came out. So, Java is very firmly in that market. It does mean that they can’t really easily go “Well, we could take Lambdas and let’s do it in this way and break all of our backwards compatibility” It does limit them – they cannot move as fast as they would like to. But that is another reason why having all the other JVM languages is quite nice because if you want to do something which is more dynamic, use Groovy. If you want to do something which is purely functional, use Clojure. It is not really a competition. They are complementary technologies and as I said, you can kind of use these other languages to see what is working, what developers really take to, what is helping their productivity and move that into Java in a non-backwards compatibility breaking way. So, it is compelling to say “Well, let’s just draw a line underneath it, get rid of all the rubbish, allow it to level up a bit”, but I just do not think that is the sweet spot for Java. The stability is one of the main reasons people chose it. And on top of that, we have Jigsaw coming in Java 9. You will be able to pick and chose the modules you want. So if you do not want the old Date Time, for example, or some of the nasty old stuff that you just don’t use any more – you do not import those modules any more. So, it is not as important saying “We need a new version of Java so we can shrink our footprint”. Now you have modularization for that.

Ralph: I actually remember I had a discussion at a customer and they went like “Oh, how much pain will it be to move to the next major version of Java!” and I was like “Eh, none.”

Right. Exactly. Just use the new version of Java.

Ralph: And they did not believe it.

There will be some pain with Java 9 – potentially – because Java 9 with the modularization breaks things into different pieces and will remove a lot of the internal APIs that no one should have been using anyway, but probably are. So, if you are using internal APIs, then you need to run JDeps to figure out if your code is going to break. So, with Java 9 there is one of the few places where you might get some breaking changes, but only if you were doing things you should not have been doing to begin with.

Ralph: Then you deserve the pain.

Right. Exactly.

Ralph: How efficient is the JCP process for defining new specifications. I guess, JCache was introduced very, very early in the process and just got finished this year or last year – I do not know. And you also mentioned Jigsaw – it has been talked about for a long time now.

Jigsaw was supposed to be in 7, right? So, it has been there for a while.


7. Is it not efficient enough? Are there too many people trying to bring in their ideas?

I do not think so. I do not think efficiency should really be a key goal of the JCP. Efficiency will potentially mean streamlining the process so that you approve lots of standards. So the JCP is around approving standards, not necessarily about changing the language. Because you can change the language in the open JDK, you do not have to put it through the JCP. The JCP is more appropriate for things like Java EE and other standards like caching and so forth. So, with standards, you do not really want to efficiently smooth the process for people to just slip their standards for Java in.

So, I do not think efficiency is something we should be driving for in the JCP. However, openness and transparency is something that we really should be working towards because that slowness, that committee thing, those decisions, apart of the problems what people think that the JCP is like an ancient closed organization that does not want to make any changes and it is not. It is just that these things take time. With a bit of transparency, which has been slowly introduced over the last few years very successfully, people are starting to see how the process works, what it is appropriate for, what it is not appropriate for, they can get involved by being involved on expert committees and things like that.

I think transparency is more important than efficiency. And I think it is important to take your time when thinking about standards. So, for example, when I worked at MongoDB, I got asked a lot about “Should we have a standard for NoSQL?” And the answer is “Most definitely not. Right now, no!” Because what is a NoSQL? It is everything, it is just everything that is not Oracle SQL databases basically. So you cannot have a standard for everything that is not a relational database. You have to sort of figure out what is going to come up and stay in practice, what people are going to use, how it is going to evolve over time and you need to sort of section it up. So maybe document databases maybe, maybe graph databases and how you need to act with those things.

So, standards by definition I think should take time because you want to see competing technologies doing the same sort of thing: what works, what does not work, where the common things are and then at that point you can draw a standard and say “This is a standard” and then the JCP is there for approving standards. So, by definition, it is just going to take a long time to do that sort of thing, I think.


8. Back to Java 8 and the adoption of Java 8 in the market. I am working for mostly major brands and they are a little conservative. Actually, in my current project I am working with Java 6. So, what is your experience? How much distribution is already there for Java 8?

Before this morning, I would have said maybe a quarter to a third of audiences at conferences say “I don’t know what is like”. At conferences you already have people who are a little bit ahead of the curve anyway, their companies are willing to send them places where they learn, so they are more likely to be a bit more advanced anyhow. But at conferences you used to sort of see a third or a quarter of people on Java 6, like a smattering of people on Java 7 and then a good chunk, maybe another third on Java 8, because Java 7 was not really compelling enough for lots of people to make the leap. This morning, in my talk, I asked who was using Java 6 and I had about 200 people in the talk and I had three hands go up.

I was really surprised by that because in cities like London and New York where you have big organizations, like you say, who have architecture committees and approval processes, it takes a long time for them to make that approval to say “Yes, now you can use Java 7”, for example. What is happening now, I think, is that there were not enough compelling features to move to Java 7. It was nice, there were some nice syntax things, there were some changes around the garbage collector, it was really nice for IO stuff, but it is not stuff that you use every day as a developer.

With Lambdas and Streams, from a developer’s point of view, there is a real push to move towards this. It will make out jobs easier, it will make the code more maintainable, I can do things for the business that I could not do before or least could not have done as easily before. So, there is pressure there from the developers to say “I want to use these new features, but because it will be good for you”. And then there is kind of pressure from the other side as well in that Java 8, in most cases, will provide you with better performance.

So, even if you do not do any tuning of the garbage collector or anything like that, you do a straight swap from 6 to 8, you will get better performance. You get a better performance and also you get better security because theoretically, well, they are going to continue maintaining Java 8 from now on so it is always getting all the updates and all the patches. The security stuff always goes into the old ones but, the mindset is that the latest version will always be the most secure. So, a better performance and most security you can possibly get. So there is pressure even from the ops and the non-functional side to say “Well, perhaps we should use Java 8” So, I think a lot of people have been happier to make the switch from 6 straight to 8 whereas 7 is like “Well, we will wait and see if Oracle is actually really serious about improving our Java over time” So, I think adoption has definitely been much faster than I expected it to be. The last time I spoke to them and the Oracle guys, they were saying the same thing, that the uptake has been pretty quick and mostly because of the performance thing.

Ralph: I guess in Java 7, as far as I remember, there was the “invoke dynamic” which was a really important feature, but just if you use other JVM languages and so for Java users it is not so important.

There was some nice syntax stuff. There was Project Coin which gave you little angle brackets and few other bits and pieces. There is ?? resources and, like I said, new IO stuff which was nice. But it was not stuff you were going to use every day, that makes you faster and more productive. The other thing I found that was tricky where I was working – it was tricky for us to move from 6 to 7 because we tuned our garbage collector so specifically for 6 that we could not quite get the same performance from 7. I am sure we could have done, if we had invested enough time in time, but there was not enough of a compelling reason to do that.


9. Now in Java 8 there is also Nashorn. I don’t know how it is pronounced in English because it is a German word. So, why would I need a Java Script runtime now in Java?

That is a really good question. It is something I keep asking. Why do you want to do that? I hear people saying they want to run JavaScript on the server. Java Script is useful for things like REPLs and for things like – if I want a command line to allow me to kind of tweak stuff and do things, Java Script is a nice language to do that then. And if you are running Java for everything else, then maybe you might want to run Java on the server, but provide a JavaScript interface to it. It is not really something that I have had need of, but for me, getting the JVM everywhere was a good thing. So, if you want to run Node.js on the JVM, fine! Go for it!


10. I am a fan of those lightweight solutions just like Node.js or vert.x and I still can’t really find much support for that directly in Java. Will there be something like that or will it still be frameworks like vert.x that I have to use?

I do not know. I think that for now, it is just going to be a case of frameworks and I think, like with a lot of standards, you want to see a few different frameworks that do it so that you can see what people like about it, what they don’t like, what they use, what they do not use. I don’t know. Vert.x is really interesting, but I can’t see it being folded into the language any time soon.

Ralph: You mentioned that you are now working for JetBrains - the creator IntelliJ, also my favorite IDE, I must say. So, if you are doing a good job, then lots of developers have fun in their work. So how does this feel compared to just creating a product, for example, or some kind of …

… inventory system for a bank or something? Yes, I think that is a really interesting question. Working for a firm like JetBrains which produces a product for developers is definitely very interesting. But before I talk about that, I want to talk about working as “just” a developer somewhere else. I think that there are loads of pros and cons for everything, right? When I used to work at Ford Motor Company, which is a big organization, an old organization and all the work we used to do is largely internal facing. So, you would not be impacting like 9 million Java developers, you would be impacting that team over there and their ordering system.

But that was quite nice because you could go over to that team over there and say “Do you like the new changes?” and they would say “No, we hate them. Can you do this?” And you get this fast feedback and you know that you are doing something that makes someone’s job – you know, Bob’s job - much better. When you are working on something like IntelliJ and you are making lots of people’s lives better, but you do not necessarily know all those people and sometimes you can work on something – when I was working on the MongoDB Java driver, the same sort of thing – sometimes you work on something and you think that you are making their lives better and you are not, but you do not know, because you do not speak to them until you make it really bad for them.

But, the JetBrains is really cool because you come to conferences and everyone is using IntelliJ. Lots of people are using IntelliJ. Sometimes they use the other one. And people come up and say “Good work on IntelliJ.” and you say “Yes, it took me no time at all to do it”. It was not me, obviously, but it is really nice to work for a company where people say “I love your tools. They make my life better”. That is actually why I chose to work for IntelliJ, for JetBrains because I have been using IntelliJ for 6 – 7 years.

I feel like I know it inside out, but I do not. But I know it pretty well and I know that I know lots of things that other developers do not know, so now I can actually go and help real developers to write the inventory systems, the ordering systems and the sales baskets or whatever, help them write those better by telling them how to use their tools better and how to get the most of it. And that is really cool. I like that because I am not just impacting those guys, I am impacting all these other systems as well.


11. That is nice. Well, just one step back to Java again. We have the new version of Java. I guess it should be final by September and then it will be released a year after that. How much work is this for a tool vendor?

It is going to be quite a lot of work, I think. I mean, I actually said last week, internally to JetBrains that I really want to speak to the guys in IntelliJ who were working on the Java 9 stuff, but I haven’t had a chance to speak to them yet. So, anything I say is not like JetBrains’ official stand point. But, 9 in particular is very interesting for tools vendors because of modularization, because of the removing of some of the internal APIs. I am sure that tool vendors and library people as well are using stuff they should not be using under the covers. So, I think it is going to be quite a big challenge. There is also the REPL which is coming in Java 9 and exposing the REPL to developers while the IDE will be quite an important thing too. So, I think this is going to be a big thing, a big challenge for us and I assume we started working on it like two years ago. There has been an open JDK version of Java 9 for ages, so it is really important for anyone who is doing library development or tools development to download that, use that as soon as possible and see what the impact is on the tools.

Ralph: OK. Thanks a lot for your insights, for this fun talk.

My pleasure.

Ralph: Have fun at QCon.

Thank you very much.