DevNexus 2019 – Alternatives to Java Reflection and Unsafe Usage – Chandra Guntur

See the table of contents for my other blog posts from the conference

This presentation is a lot of live coding with this kata.

JSR 292

  • Multi Language VM proposed in 2016
  • Code named Da Vinci Machine project
  • Gained ability to change classes and methods at runtime

Issues with reflection

  • Performance overhead
  • Security restrictions
  • Exposes internals – breaks abstractions and encapsulation

Method handle

  • Goal is to make as fast as a statically linked Java call
  • Mainly same since Java 7
  • More verbose than reflection
  • Performance benefit because only checks accessibility the first time you use it
  • Main APIs:
    • MethodHandles.Lookup – searches for a method handle
    • MethodHandle – execution logic
    • MethodType – represents return type and input parameters of a method. Immutable

Katas

  • Call constructor using a method handle
    • MethodHandles.publicLookup() – gives a loop reference
    • MethodType.methodType(void.class) – constructors don’t have return types so void
    • lookup.findConstructor(DemoClass.class, methodType) – actually get the MethodHandle
    • handle.invokeExact() – invoke method (well, constructor) with no parameters. Need to cast result so correct type.
  • Pass in parameters
    • handle.invokeExact(“paramValue”) – note that the parameters are bound at runtime. If call with wrong params, get runtime exception
  • Call a public method
    • MethodType.methodType(String.class, String.class) – a method that takes a string and returns a string
    • lookup.findVirtual(DemoClass.class, “methodName”, methodType) – call public method with findVirtual
    • handle.invoke(demoClass, “param”)
  • Call a private method (protected and package private work the same way)
    • DemoClass.class.getDeclaredMethod(“name”, String.class)
    • privateMethod.setAccessible(true) – just like with reflection
    • lookup.unreflect(method) – creates lightweight version
    • handle.invoke(demoClass, “param”)

VarHandle

  • Unsafe still deprecated (but not removed) in Java 12
  • VarHandle replaces Unsafe in many cases
  • Standard replacement for some features for atomic concurrency and Unsafe
  • Can use to access field/array index elements
  • Memory fences for fine grained control of memory ordering
  • A strong readability fence
  • Improves safety – requires content types to match/be castable. Also requires array indexes to exist
  • Improves integrity – Follows field access rules including honoring final
  • Performance equivalent to Unsafe
  • API more usable than Unsafe because intended to be an API
  • Uses coordinates since fields are referenced by name.

My take

I like reflection so this was a good opportunity to learn about it’s “successor”. I enjoyed seeing the live coding. In addition to Method Handles code, it was nice to see the callouts to some IntelliJ features. Chandra did a kata on VarHandles. I didn’t take notes on that since I was reviewing my presentation which is next.

DevNexus 2019 – java things that make you go huh – Bob Paulin and Freddy Guime

See the table of contents for my other blog posts from the conference

Scene 5 – singleton makes spring factory return same object each time

Scene 6 – multi release – showed exploring a jar and the alternate files. Which shows a jar can have different behavior. Nice demo of a new way to shoot yourself in the foot!

My take

I misssed 2/3 of the session. I like that each scene stood alone so I could enjoy those parts. And enjoy I did. Their costumes and characters were awesome!

DevNexus 2019 – Why and How of Evolutionary Design – Rebecca Parsons

See the table of contents for my other blog posts from the conference

  • How plan long tern architecture when under constant change
  • if on unicycle, focus on not falling. We are on the unicycle
  • evolutionary architecture is guided change
  • have to agree on what consistutes good. Not all systems need same level of security reliability, etc

Fitness function

  • how we define good.
  • Needs to be clear so no disagreement on whether the system meets. So cant just say “maintainability”
  • examples: manual vs automated, temporal, triggered vs continuous, static vs dynamic
  • think of us a test
  • chaos monkey is like a test. You know configured correctly

Principles

  • Make decisions at last responsible moment. Know the nost then
  • evolvability needs to be a first class citizen
  • how communicate across non functional requirements
  • minimize logic to minimize change. Dont do unnecessary work
  • testability
  • Conway’s law. The communication structure of your system will mimic that of organization. Communication silos in an org result in broken ntegration

Techniques

  • Continuous Delivery
  • Database refactoring – can’t migrate a system if you are being held hostage by the data
  • orchestration – the orchestra follows the conductor.
  • Consumer driven contracts. – dont have to think about until test breaks

Kinds of monoloiths

  • Ball of mud
  • layered monolyth. Can’t change without coordinating across all layers. reduce costs by standarizing everything. Slows things down. IT is an enabler and not just a cost center
  • modular monolyth
  • micro kernel architecture is only adaptable in ways you predicated. Also have to write the adapters so have more code/bugs

My take

Good talk. It was interesting and applies to almost everyone. I particularly liked the principles. I would have liked to see the slides after it got stuck. The talk was clear. But it is a long day and would have been easier to follow by visually seeing the points on principles and techniques. Im glad she acknowledged the slides not working at leaat