Category Archives: Conferences

[2024 dev2next] project amber

Posted on by
Reply

Speaker: Neha Sardana

For more see the table of contents

General

  • Aim: Code is clear like Amber
  • Showed old release cadence ncluding 5 year gap from 2006-2011

Many projects

  • Amber – small incrememenal language enhanceents
  • Loom – lightweight concurrency and virtual threads
  • Valhala – value types and generic collections
  • Panama – native code

Goals of Amber

  • Boost productivity – less boilerplate
  • Improve code readability
  • Support long term evolution
  • Maintain language consistency

Preview features

  • Experimental but final features
  • Have to enable preview features to use

Local variable type inference

  • var – JEP-286
  • var for lambda parameters JEP-323
  • variable names more important because don’t have the type

Data handling

  • Records – 359, 384, 395
    • Data classes
  • Immutable and final
  • IdIeal for data transfer objects
  • Sealed classes – JEP 360, 397, 409
  • Controlled inheritance
  • Improved code safety
  • Enhanced pattern matching
  • Text blocks – 355, 368, 378
  • Multi line string simplification
  • Improved readability
  • Automatic formatting
  • Remember when had to put SQL in a String
  • String templates 430, 459, 465 – withdrawn)
  • Not available in Java 23. Would have simplified string concat, improved safety and enhanced readability
  • Withdrawn due to issues
  • If some back, will have new design/syntax

Control flow

  • Switch expressions 325, 354, 361
  • Simplified syntax
  • Return values
  • Exhaustiveness checking
  • Pattern matching for instance of 305, 375, 394
  • Eliminates casting
  • Improves readability
  • Safer type handling
  • Pattern matching for switch 406, 420, 427, 433, 441
  • Some of the JEPs didn’t change; just wanted more user feedback
  • Primitives types in patterns, instanceof, and switch 445
  • preview in 23
  • can use int to match instead of having to use Integer
  • Record patterns – 405, 432, 440
  • Declare record fields in same line so can use in instance of without having to reference
  • Pattern matching for data decomposition
  • Can use instance of and && in a lamdba; doesn’t have to be in if statement
  • Works with instanceof and switch
  • Unnamed patterns and variable 443, 456
  • Use _ instead of name to show unused
  • Clearer that want to ignore data
  • Enhanced pattern matching flexibility
  • Can use _ in lambda variable, catch block, etc as well

New language features

  • Implicitly declared classes and instance main methods – 445, 463, 477
  • In preview
  • void main() – no class, no public/static/params
  • println() instead of System.out – in void main(), get that static import without having to have the import
  • Reduces boilerplate
  • Module import declarations – 476
  • In preview
  • import module java.base;
  • Simplifies module usage
  • Let’s use classes in module.
  • If conflict, need to explicitly import that class
  • Statements before super -> Flexible constructor bodies 447, 482
  • feature renamed between versions of Java
  • Flexibile initialization
  • Improved code flow
  • Enhanced control

Future

  • Derived record creation 468
  • in preview
  • allow extending records – dervices most values from original
  • Person x – original with { email = “e”; };
  • Simplify record inheritance
  • Reuseable code

My take

I had seen this talk in NY and came to support Neha. It’s still good :). I like that she had a lot of examples. Mentioning Scala a lot was fine, More opportunities to learn..

[2024 dev2next] virtual threads

Posted on by
Reply

Speaker: Piotr Przybyl @piotrprz and @piotrprz@mstdn.social

For more see the table of contents

Note: some things in this talk are in preview features. Might change/get better

Demo

  • Traditional demo of starting a thread and having it wait 10 seconds.
  • Ran 1K platform threads in just over 10 seconds. Ran 30K in 15 seconds. Ran 40K and it crashed due to “not enough space”.
  • Switched to virtual threads and no more resource constraints. Just over 10 seconds for 40K virtual threads. A million virtual threads took about 15 seconds
  • Awesome until see how fooled by demo
  • In the demo is sleeping, not using any resources
  • Redid demo with CPU work so no blocking.

Releases

  • released in Java 21 and previewed in 20-21
  • structured concurrency – preview in 23
  • Scoped values – preview in 22

Virtual threads

  • Great for I/O and waiting
  • No way to switch on and off globally in JDK
  • Don’t make threads faster; Make app scale better
  • Gave NYC example: drive to restaurant and park. Hardware resource (Car) not used. Vs taxi/Uber where don’t care where is when eating
  • If all cars were taxis, could move people faster. But one person doesn’t move faster by just using a taxi.
  • Said not his metaphor but likes it [I like it too]
  • Will not squeeze more juice from your CPU

Don’t Reuse

  • Reuse – cheap to start, create new
  • Pool – requires reusing

Don’t Pin

  • Like car “keep engine running”. Wastes resources, still have to pay.
  • I/O and synchronize pin in Java 21 when takes more than 20ms
  • Find with -Djdk.tracePinnedThreads=full and JFR events
  • toxiproxy – good for chaos engineering. Can set to half a second plus some jitter for variance (or anything you want)

Logging Double slit experiment – “how many lights are there”

  • Observing makes the answer different
  • Changed from 5 seconds of work to five one seconds and added logging.
  • Logging changing behavior because default handler is synchronous.
  • Less finished because opportunities for other threads to get in
  • It’s like everyone calling an Uber when a concert gets out.
  • Every time you do I/O, the thread blocks. ex: get out of taxi
  • Platform threads are different; they don’t block just because you do an I/O operation.

Other problems

  • Can’t ignore backpressure control
  • Ignore interrupts
  • merge with synchronized/native

Structured Concurrency (preview)

  • better “idioms” for multi threaded coded
  • helps eliminate thread leaks and cancellation delays
  • not replacing interruption with cancellation
  • showed waiting on two future. they don’t know the other gave up.
  • each future needs a reference to all other features so they know to give up when implemented manually
  • StructuredTaskScope.ShutdownOnFailure() { // two futures } // allows to know
  • scope.throwIfFailed() knows

Scoped Values (preview)

  • One way immutable ThreadLocals.
  • ThreadLocale is like a cache.
  • Bounded lifetime; visible in code
  • Results in simplified reasoning and improved performance
  • ScopedValue.where(x,y). run(() -> dostuff())
  • Can use Runnable or Callable
  • Can nest where() as long as you don’t mutate it

My take

This was interesting. I didn’t know pinned threads were a thing. Also good humor; well known debug pattern of “debug 1” 🙂

[2024 dev2next] kafka

Posted on by
Reply

Speaker: Daniel Hinojosa (mastodon.social/@dhinojosa)

For more see the table of contents

Related tech

  • Piniot – OLAP
  • Input to kafka – kafka streams, akka streams, flink, spark streams
  • Connectors – ex: to database

Kafka

  • publish/subscribe queue
  • producer can also be a consumer

How looks inside

  • messages sharded
  • immutable data store
  • message gets an offset number in the partition.
  • data is temporary – specify retention size or time
  • don’t reuse offset numbers even after message delete
  • can only read/write to leader, not the replicas/followers

Message

  • Similar to a row/record
  • Just an array of bytes; format doesn’t matter
  • Message key is also an array of bytes. Only time something is guaranteed to be in order. Partitioner hashes key and maps to partition.

Batch

  • Group of messages
  • Every batch knows where each partition is going
  • Uses murmur2 for hashing
  • Can set batch size

Acknowledgements (Ack)

  • 0 – no ack; assume all is well; lowest latency
  • 1 – only goes to leader
  • all – all replicates must ack. Higher latency; safest. ex: bank transactions

Consumer

  • goal: scale to a large amount of different consumers without affecting performance
  • Consumers are not threadsafe
  • Consumer rebalance – mitigate when consumers go down
  • Settings: Isolation level

Producer

  • Settings: idempotent, transactions

Compaction

  • Retain message of same key where only latest message will be retained.
  • Cleaner thread does compaction
  • Can treat as events or tables
  • Tables treat Kafka as key/value database
  • LIkely don’t care about past with respect to table. Care about current/end state not everything that happened along the way.
  • Dirty – extra records

Stream processing

  • Everything is consumer/producer. Everything else is just a higher level
  • Stream groups
  • Java type stream methods – peek. foreach, groupByKey

My take

I used to know some of this, but had forgotten it so excellent review. And the new stuff was good too! I wish the screen had different resolution rather than relying completely on zooming in. Would have allowed to see some stuff while running, live code changing, and the web page (which weren’t magnified). The extended demo was great though! The gitpod “sales pitch” was a nice side effect.