Tag Archives: java

[2021 kcdc] Algebraic in Java: Pattern Matching

Posted on by
Reply

This post is my live blog from KCDC. For more, see the 2021 KCDC live blog TOC

Speaker: Chandra Guntur

Twitter: @cguntur

————————-

Background

  • This is part two of a talk. Part 1 covered algebraic types (ex: enums). Don’t need to have seen it for this talk
  • Pattern matching came froM SNOBOL (string oriented and symbolic language) in 1960s
  • This presentation is in https://github.com/c-guntur/algebraic-in-java

Switch case pattern matching

  • case can be type of object. ex: case Integer i -> “int”
  • Must put “case null” in order to avoid a null pointer
  • Guarded expressions: case Integer i && i < 50
  • Can use same pattern variable name across case statements
  • Flow scoping

If statement pattern matching

Deconstructing is from JDK 18 preview – https://openjdk.java.net/jeps/405 (preview features can change)

  • if (o instanceof Point p)
  • if (o instanceof Point(int x, int y) – deconstruct value. Implicitly type safe because null won’t reach branch (null instanceof X is always false)
  • if (r instanceOf Rect(Point(var x, var y), var lr) – nested deconstruction
  • If have varargs, can match by coordinates/number of elements. Ex Point() matches no params, Point(var a) matches one, Point(var a, …) matches one or more
  • For array, if (o instanceof String[] { String s1, … } – one or more elements in array

Pattern matching isn’t new

  • Always had instanceof
  • Visitor pattern
  • Regular expressions

My take

I’m excited Java is going to be adding a lot of this. The format of presenting from inside IntelliJ is interesting. The presentation was short though. Only half an hour. I liked the answer to my question about scope – pretend there is an else block!

[kcdc 2021] Java 17’s Project Panama Newbies

Posted on by
Reply

This post is my live blog from KCDC. For more, see the 2021 KCDC live blog TOC

Speaker: Carl Dea (Azul)

Twitter: @carldea

————————-

Foojay.io has more

JEP 412 – Foreign Access API

  • https://openjdk.java.net/jeps/412 – ties together other JEPs
  • incubator module. Third incubabor
  • in making for at teast 6 years

Problems with old way

  • Communicating with required wrapper code and distributing a .ddl
  • Have to do a lo of work yourself to interfaces with C

URLs

  • jdk.java.net/panama
  • https://github.com/openjdk/panama-foreign
  • panama-dev@openjdk.java.net
  • https://foojay.io/today/project-panama-for-newbies-part-1/
  • https://foojay.io/today/project-panama-for-newbies-part-2/
  • https://foojay.io/today/project-panama-for-newbies-part-3/
  • https://github.com/carldea/panama4newbies

Using

  • java -version. Make sure says 17-panama. (Not part of main JDK)
  • jextract -h to get help
  • jextract will generate Java code for you by looking at C header file
  • Most important options
    • -I (capital Eye) – include file path
    • -d – destination for generate files
    • -l (lowercase ell) – specify a library
    • -t – target package
  • Must add incubator module and enable native access flag to run
  • Can call C methods from Java by importing them
  • Java wil hande the memory allocation/cleanup based on scope

Include

  • Copies file and puts in this file.
  • Not like import where it a reference

My take

This is a topic I knew nothing about. (Or forgot what I had known.) It was really cool to see!

[2021 kcdc] Enterprise Cloud Patterns for Java Devs

Posted on by
Reply

This post is my live blog from KCDC. For more, see the 2021 KCDC live blog TOC

Speaker: Pratik Patel (Azul)

Twitter @prpatel

————————-

Philosophy

  • Monoliths are not elastic. Cloud is
  • Doesn’t waste money
  • Must design for elasticity
  • We learn to avoid premature optimization/keep it simple stupid. In the cloud, we have to do some optimization
  • Need to design for horizontal scaling (adding more servers/virtual servers)
  • Need entire architecture to be elastic. Else have created a bottleneck
  • Think about cosT, adapabiity/agil/security, time to market

Cloud native review

  • Containerized
  • Dynamically orchestrated (actively schedule containers to optimize resource utiilization)
  • Microservices oriented (try to avoid dependencies between microservices – not possible to avoid, but minimize)

Types of Patterns

  • Design and implementation – covered today
  • Performance and scalabity
  • Data management
  • Availability and reliabliliy

Ambassador Pattern

  • For transitioning legacy apps – could be monolith or SOAP or Java EE or Spring Boot or whatever to microservices
  • The Ambassador is a proxy. It adds monitoring, retry and a protocol adapter (hide SOAP/RMI from clients) and delegates to the legacy app.
  • This lets the callers all the Ambassador and get these cloud capabilities.
  • Implemented as a sidecar (does extra stuff)
  • Use Spring RestTemplate (now called WebClient) or Microprofile Rest client 2.0
  • For end user/callers

Anti-corruption pattern

  • Also for transitioning legacy apps
  • Callers is another service (microservice, cloud function, event driven api)
  • Does more than ambassador.
  • Facade/adapter pattern
  • Firewalls legacy apps
  • Useful for migrating large glegacy app
  • Protocol adapers
  • Legacy unchangeable APIs
  • Compartmentalize legacy app to protect requests coming in and rest of system in case something gos wrong
  • Spring Reg Template or Microprofile Rest client 2.0
  • Must define specific endpoints

Gateway aggregation pattern

  • For when app needs to call multiple services (ex: auth, media)
  • Calls multiple services and returns the results of multiple services to caller in one shot
  • Groups related services into one API call
  • Avoids death star anti-pattern when everything cals everything else
  • Client calls gateway not services directly
  • MUst think about how to handle failures in downstream services
  • Use SprIng AsyncRestTemplate (or web client) or GraphQL (Sprin, Microproile or SmallRye) – note that graphql introduces dependencies. Good to return a bunch of related data.

Back end for front end (BFF)

  • For flexibiity and performance
  • Adapter by client type (ex: mobile, web mobile, web desktop)
  • Returns data in way most practical and efficient for that client
  • Calls microservice and/or legacy app
  • Can be an implementation of a gateway aggregation pattern
  • Make sure not premature optimzation
  • Data can be shaped and size for specific needs
  • Improved performance
  • Could introduce code duplication
  • Are front and back end devs on same team.
  • Sprint AsyncRet Tmplate or Microprofile CompetableFuture or RestClientBuilder
  • Can be different URLs by service type – ex: mobile url (or header sniffing in API gateway)

Gateway Routing

  • Commonly used/misused
  • Calls proper service based on URL
  • Helps minimize change to clients
  • Reducing coupling directly to services
  • Tradeoffs: latency, bottleneck
  • Spring RestController or Microprofile JAXRS. Or cloud pattforms APAI gateway

URLs

https://docs.microsoft.com/en-us/azure/architecture/patterns/

https://aws.amazon.com/architecture/

My take

This was very fast moving, but I found it understandable. I learned a lot. I liked Pratik’s hand drawings of the patterns. It was also interesting that most people were using AWS at a primarily .NET conference