JavaOne – How to Make a Project Java 9 Compatible

Posted on by
Reply

“How to Make a Project Java 9 Compatible”

Speaker: Nikhil Nanivadekar

For more blog posts from JavaOne, see the table of contents

Examples use Eclipse Collections

Examples from:
https://github.com/nikhilnanivadekar/Java9Compatibility
https://github.com/nikhilnanivadekar/Java9Modules

Reflection

  • Used ArrayListAdapter which uses reflection
  • Got illegal-access warning (when default was warn; now it is permit
  • If run with illegal-access=deny, it fails
  • Lesson: have lots of regression tests so know about such errors
  • Lesson: Allow a lot of time to migrate. Don’t start Friday evening. Long sequence of “just one more compilation error to fix”

Infering types

  • Compler error because can’t assume generictype to return
  • Comes up when class doesn’t have a generic type and try to store it in one that does.
  • Compiler not supposed to infer type
  • Fix is to cast or store in a local variable
  • Similarly need to declare types on class instatiation if not diamond operator usage

NullPointerException

  • collect() now calls Objects.requireNotNull(combiner).
  • In Java 8, a null combiner worked in serial mode because not used.

“I love compiler errors vs runtime exceptions”

Migrating a Java 8 Maven project to Java 9

  • Migrated a maze solving project. Was written recently so not legacy code
  • Switch source/target of maven-compiler-plugin to “9”.
  • Changed JDK in IntelliJ.
  • Maven itself works fine with Java 9. Compiling works. JavaDoc and Enforcer plugins work fine with milestone version; not yet for released versions. Seewiki on support for Java 9 in Maven plugins
  • Looking at modularizing library in future
  • Runs without adding module info file or doing anything else
  • Once add module file, more enforcement happens. ex: error on unnamed packages
  • Eclipse and IntelliJ have quick tip to add requires
  • Important: start with base module
  • If not using a build tool, need to ensure no cyclic dependencies. (build tool takes care of this for you)
  • Add exports clause for module. The compiler error just says the class isn’t found. It doesn’t say it is because the export is missing.
  • Move code in split package to another package updating all callers
  • Delete empty package; can’t have empty package
  • Hide internal packages by not exporting sub-packages

My take: Nice to see issues by example. And nice to see that it wasn’t “all about Jigsaw.” It was a good mix of problem types!

JavaOne – Optional – the mother of all bikesheds

Posted on by
Reply

“Optional – the mother of all bikesheds”

Speaker: Stuart Marks
#OptionalBikeshed

The deck is available online

For more blog posts from JavaOne, see the table of contents

Showed early version of “optional” (stream returning null)

Review of basics

  • Two states – present (contains non null reference) or absent
  • Don’t say “null optional”. Say “absent” or “empty”
  • Optionals are immutable
  • equals() and hashCode() work as one would expect – useful for JUnit because can call assertEquals()

New in Java 9

  • stream() – stream with 0 or 1 elements
  • ifPresentOrElse(Consumer)
  • or(Supplier)

Good code and Best practices

  • Never set an Optional variable to null. It should be Optional.empty() as default.
  • If method returns Optional, never return a null either.
  • Intended for return types where might or might not have a value to return.
  • Don’t call get() as could be empty optional
  • Use isPresent() and get() as last resort
  • Using .map().orElse() chained after stream pipeline gives fluent API calls
  • Calling filter() returns original value only if non-empty optional that matches. else returns empty. Using filter() and orElseThrow() is good for validation
  • [and more see the deck]

My take: Amazed there is so much to say about Optional! Excellent set of best practices. And excellent point on not calling an optional “null.” I needed to leave early as my session is immediately after this one. And I really wanted to know “what’s with the bikeshed” which is covered last.  It’s a nice collection of quotes. So I found the deck and best practices online. There’s also a youtube video linked so you can watch at home.

JavaOne – 10 tips to become an awesome tech lead

Posted on by
2

“10 tips to become an awesome tech lead”

Speaker: Bart Blommaerts

For more blog posts from JavaOne, see the table of contents

Not one free seat in the room and long wait list line. [I wait listed and left the keynote 5 minutes early to ensure I got in]

Role of Tech Lead

  • Provide tech leadership
  • Protect team from interruptions
  • What new libraries/frameworks should we use? What are risks?
  • Coaching
  • Communication – bridge gap between devs an business

Do we need one

  • In ideal world, don’t need tech lead
  • Hard to do everything by consensus
  • Unlike the lego movie, everything is not always awesome
  • Business still needs point of contact
  • New people still need training

The ten tips

  1. Advocate for change – don’t want people to be afraid of prod, need to evolve. Try to make stupid processes better. OODE – observe/orient/decide/act
  2. Work through failure and success – prepare for failure, don’t finger point (“we”), take responsibility, learn from failure, problem if you are fixing the same bug twice – that is process failure. Celebrate success – sprint celebrations, feature complete, congratulate team/individuals
  3. Stay technical – write code, review code, tech vision (and get buy in; ideally with everyone contributing to it), evolution of code. Don’t forget about security/networking
  4. Time management – be available – spending time on tech design, talking to the business, project management (ex: help write user stories) and code
  5. Be a mentor for your team – facilitate discussion. Help team becomes stronger developers. Delegate. Optimize for the group/team
  6. Surround yourself with other tech leads – on a personal level, see what others do to get ideas and learn. On an organizational level, look at common org/architecture along with interoperability/dependencies
  7. Interviewing potental new team members – know your goals. For short term,, looking at tooling. For longer term, look at eagerness to learn. Don’t use stack overflow to find questions; pick things relevant to your project
  8. Embrace cultural differences – diversity, culture, family. Your users are different too.
  9. Estimating is hard – “Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.”. Planning poker. Uncertainty is normal. Add 20% for test/debug/polish/documentation/wtf moments.
  10. Interfacing with the outside world – want to be the go-to person, but not the single point of failure
  11. Faciliate an agile and awesome team

Other notes/tips

  • Not difficult for tech lead to make things worse
  • Need to experience same pain as everbody else on team – you are part of the team
  • Be realistic. Not possible to answer every question. Also, need to connect teammates to each other. Ok to request time to look into a question as long as you get back to them. Also ok to suggest pairing.
  • Not making a decision is worse than making the wrong decision becuase not doing any work
  • Interview style – comfort people (they are nervous; start with a siimple question like “what is the difference between an interface and abstract class in Java”), offer options, build on responses like “what is the difference between interfaces/abstract classes in Java 8”, show interest, bonus question
  • Offshoring – work gets done while sleeping, communication harder. Prepare work for remote teammates since they can’t talk directly to business. Harder to make everyone feel like part of team. ex do a night shift “most developers work better at night” [I am so non standard here!] Keep history ex: Slack

He commented about people working nights the last couple sprints to ensure success on the project. [That sounds completely against the sprint of sprints being sustainable]

My take: Nice to have a good tech soft skills talk. I noticed that Bart referred to “technical lead” as “he” whenever he used a pronoun. I wonder if it’s like that in his native language. Google translate says both tech lead and developer use “le” (are masculine) in French. This was more obvious at the beginning; he switched to “you” after a bit. And he said he/she later on.