QCON NEW YORK 2017

Conference: Jun 26-28, 2017
Workshops: Jun 29-30, 2017

Presentation: Applying Java 8 Idioms to Existing Code

Track: 
Innovations in Java and the Java Ecosystem

Location:

  • Salon C

Duration

Duration: 
11:50am - 12:40pm

Day of week:

  • Tuesday

Level:

  • Intermediate

Persona:

  • Developer
  • Developer, JVM

More talks on:

Key Takeaways

  • Understand how to improve performance with your Java code using Java 8 language features.
  • Learn hands on techniques to discover and implement common Java 8 refactorings.
  • Understand when you should and should not apply key refactorings in Java 8.

Abstract

While we’re drawing ever closer to Java 9, and even hearing about features in Java 10, many of us are still working with an older version. Even if your project has technically adopted Java 8, and even if you’re using it when coding new features, it’s likely that the majority of your code base is still not making the most of what’s available in Java 8 - features like Lambda Expressions, the Streams API, and new Date/Time. And this is a shame, since Java 8 provides not only nicer syntax for developers, but (usually) better application performance.

In this presentation, Trisha will:

  • Highlight the performance benefits of using Java 8 - after all, you’ll probably have to persuade "The Management" that tampering with existing code is worthwhile
  • Demonstrate how to identify areas of code that can be updated to use Java 8 features, and how to pick which changes will give you the most benefit
  • Demonstrate how to automatically refactor your code to make use of features like lambdas and streams
  • Cover some of the pros and cons of using the new features - including suggestions of when refactoring may NOT be the best idea.

Interview

Question: 
What can we we expect to see and learn about Java in your talk?
Answer: 
In terms of the coding techniques I am going to show, the technical side of the talk is aimed at people who know what they are doing so that they can apply these in a real production code base. But beginners should be able to follow along with it.
The goal is to allow attendees to figure out which tools to use to bring their code base more up to date, more Java 8’ish. We will be looking at features specifically in IntelliJ, but a lot of these features are in the other IDEs as well. These allow someone to find areas of their code that can be refactored, and then apply various refactorings to new idioms, like Lambdas, method references, streams, new Date and Time, and Optional.
Question: 
Is there a discovery mechanism inside IntelliJ that are pointing these areas out?
Answer: 
IntelliJ has inspections and a developer can turn on various inspections. One set of inspections is called Language Level Migrations. For example, it can even help migration from Java 5 to Java 6 to Java 7, so it will say things like you have got anonymous inner class here. This would be a good place for Lambda. If you are declaring all your generics here whereas in actual fact, you can use the diamond operator from Java 7.
Question: 
What am I going to walk away from your talk with?
Answer: 
In my ideal world everyone would watch so that they can kind of get a feel for all new things in Java 8 they might not have been aware of.
But if just one person in the team sees this talk, then they can be spreading the idea of "how can we refactor this" or "maybe instead of using this, we will be moving in this direction." I want this to be pragmatic: I want anyone to be able to look at the code they already have, and start to train their brain to see patterns on how to do new things instead.
Question: 
Just upgrading from Java 7 to 8 often yields significant performance boost. Is it always faster? Can you give me examples of some of the performance benefits you’ll discuss that can come from language updates?
Answer: 
Generally speaking, Java 8 will give better performance without the developer doing anything. For example, HashMap is faster for various operations. But it is not always faster, especially with streams.
For example: if someone is going to replace a very simple for-loop with streams, they are going to end up with less performance because there are all sorts of objects happening there. Simple for-loops are easy to optimize at CPU level, whereas streams become much more complicated. That is fine for big data or bigger data, but for a for-loop which iterates 10 times over numbers, then a stream is unlikely to give you better performance.
Question: 
How much are you going to dive into performance details and show real code?
Answer: 
I have got a whole stream on performance, so I am going to highlight some of the freebies that you will get like with the better performance (on HashMap for example), highlight some lesser-known things about new methods on collections which might give better performance or new collections which can give better performance, then look specifically at streams, considering when something might be better in this case, or worse in this case, and hopefully, show some performance tests for some simple micro benchmarks.
Question: 
As you well know, QCon targets advanced architects and senior development leads, what do you feel will be the actionable that type of persona will walk away from your talk with?
Answer: 
While all developers should be able to use these skills, one of the interesting points (or probably frustrating points for a lot of developers) is that only the architects or tech leads will have the power to go back to the organization and say "we should do this". This is important.
That’s where the performance comes in, because they can use that as a selling point to the systems people, who tend to prefer stability, and to the business people, who don’t really want you to wander off and do refactoring, which gives them no value. I think the performance might be the stick with which to hit the rest of the organization to say "This is why we need to go back and refactor our code."
"Performance" can also be interpreted to mean developer performance. The Java 9 idioms we’ll discuss can lead to easier-to-understand code, and, therefore, better comprehension. This just makes things easier to reason about and change.
Question: 
You've mentioned refactoring many times. What can you tell us more about the refactorings you plan to hit on it your talk?
Answer: 
There is real value in knowing when not to refactor. Especially when you are looking at a tool like IntelliJ, which will automate finding these spaces and automate doing the refactoring. It could be easy to say "apply all" and think "What’s the worse that could happen?" It is useful to know which of these might be dangerous refactorings, and which are probably not really going to cause any problems. One I am struggling with, or have been looking over, the last week is optional. I really like the idea of the optional type and I feel like it has a lot of value, but I haven’t worked on anything using in it anger yet. I haven’t really got a feel for it, and I am trying to apply to one of my open source projects but it is painful.
It’s painful to figure out optional because it’s quite verbose to use, because nulls aren’t formally checked in Java generally: it is quite difficult to know where is null a valid value, where is not a valid value.
Once you start putting optionals in somewhere, it starts spidering throughout your whole code base. Once you start applying it, it could explode all of your code base and it’s dangerous.

Speaker: Trisha Gee

Java Champion, Morphia Committer, and Developer Advocate @JetBrains

Trisha 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. Trisha blogs regularly on subjects that she thinks developers and other humans should care about, she’s a leader of the Sevilla Java User Group, a key member of the London Java Community and a Java Champion - she believes we shouldn't all have to make the same mistakes again and again.

Find Trisha Gee at

Speaker page

https://twitter.com/trisha_gee
https://es.linkedin.com/in/trishagee

Similar Talks

Learnings from a Culture First Startup
CTO @Buffer
Sunil Sadasivan
Becoming an Outlier
Software Architect @VinSolutions, Author @pluralsight
Cory House
ESPN Next Generation APIs Powering Web, Mobile, TV
Senior Director of Distribution Platforms @ESPN
Manny Pelarinos
The Human Side of Microservices
Tech Lead @Yelp
John Billings
Lessons Learned on Uber's Journey into Microservices
Software Engineer @Uber
Emily Reinhold
What They Don’t Tell You About Microservices…
CTO @Yodle
Daniel Rolnick
Algorithms for Animation
Partner & Tech Lead @CarbonFive
Courtney Hemphill
Machine Learning Fast and Slow
Lead Data Scientist @betaworks
Suman Deb Roy
Vowpal Wabbit a Machine Learning System
Leading Machine Learning Researcher, Vowpal Wabbit Contributor
John Langford

Tracks

Monday, 13 June

Tuesday, 14 June

Wednesday, 15 June

See the Full Schedule

Conference for Professional Software Developers

Follow QCon

Contact

Menu

QCons around the World

Qcon