Ripples from the pond

Java 8 is the biggest change to the syntax of the JVM since generics in Java 5

Yoav Landmand, CTO of  Jfrog - the creators of open source repository manager Artifactory and software distribution platform Bintray - shares his expert analysis of Java 8, and how he thinks the next generation of software from Oracle will impact the Javasphere as a whole.

JAX: To what extent do you feel that Oracle have succeeded with this release?

Landman: I think that this release is quite a success. Mainly because of the very important features that I guess would otherwise drive people to use languages other than Java. People were getting tired with Java and saying Oracle are not innovating enough, so with Java 8 they've really pushed it and tried to give developers some hope - which they delivered at the end of the day. All the functional stuff that they added into the language is a big and welcome change.

Do you think that there's anywhere Oracle could have done better? For example, a lot of developers were upset that Project Jigsaw didn't make it in this time around.

For us that was a little bit disappointing too - mainly because we are all about delivering and managing modular software. We really had high hopes for a lot of fields. They may have missed the train with Project Jigsaw. When you introduce such a big change, as long as you're in an ecosystem, you need to have the whole ecosystem comply - so I hope it's not too late for it.

I know they made a lot of changes in the VM itself just to make it ready so it can be a lot more modular, but other systems outside the JVM are trying to solve the same problems, and for now people are managing. But I really hope there will be some low level support in the JVM itself to remove all the isolation between modules - that would be great - but it's a bit disappointing that it didn't happen this time.

“Modularity remains a problem in Java” : do you think this will ultimately harm the popularity of the platform, or do you think other new features will override these issues?

I think that the modularity issue is something that people have gotten around. People have learnt to walk around it in so many ways that they will keep doing it. But the new constructs - the lambdas...default interface methods...things like that, are things that Java people really envied in other programming languages, and made them turn to the side and see whether they should move or not. I think they will manage to gain people in Java by having those features.

The community were a big part in this release - but do you think there's anything in this release that developers will struggle to adapt to?

For people coming from other languages with functional constructs like Groovy, for example, it's kind of an easy move. I say kind of, because when you program in Java you still have old habits, and the syntax is a lot different. In fact, I think Java 8 is the biggest change in syntax to the JVM since generics in Java 5 so I'm sure some people will find it challenging. It will also take some time to get used to the new languages and new APIs that are in the core of the JDK right now.

What does Java 8 mean for JFrog?

We have two kinds of products, cloud products and portable products. For the cloud products - especially Bintray  - we already started experimenting with Java 8 features in some of the components. It's an easy migration for us because we have full control over the roadmap. And if we think our code could look nicer or some cool features or new libraries are going to be helpful we can try it out.

For Artifactory, we are really in the hands of our customers, because they don't go and upgrade so often, even if they are a startup. Last time we went from Java 6 to Java 7, I think it took people around two years to do the move on the server side. The early adopters probably moved after six months, but altogether it took around two years for Java 7 to become more popular than 6.

Do think that Java 8 poses a serious threat to the other JVM languages that it's taken features from?

I'm not sure. Other languages, such as Scala for example - they have the biggest advantage. A lot of programmers are really keen on keeping the languages moving forward without breaking compatibility. With Java it's not the case.

It's kind of an expectation in many languages today that when you upgrade libraries, and when you move to new frameworks you refactor a lot. Even if you don't upgrade your dependencies, you refactor your code a lot and it's kind of OK on many occasions to refactor when you upgrade, even when you upgrade the language, so it allows the language to move forward a lot faster.

 

Lucy Carey

What do you think?

Comments

Latest opinions