Helidon: Never Block The Thread

An airhacks.fm conversation with Tomas Langer (@langer_tomas) about:

The first line of code was in Basic on Atari 800 XE in 1989, computer club for kids in Prague, the programming accident in Java, studying and working for 16h a day, early interests in application servers, joining BEA Systems in 2003 and starting with version 6, the weblogic.jar and the weblogic "thin client" jar, the only BEA consultant in eastern Europe, Oracle's acquisition was a big change, leaving Oracle and moving to AVG for building custom application servers, starting at HomeCredit to develop with WebLogic, service buses and Co., joining a JavaONE conference session with Josh Long about SpringBoot, what is the purpose of FatJARs, one application per server, WebLogic became bigger over time, hollow JARs are explainable, about the costs of running application servers in the cloud, the deconstruction of the application server, how clustering became obsolete, application servers and docker layers, separation of business logic and infrastructure, the superfluous deployment machinery, the idea of a single application, the complicated application server's classloading, helidon only relies on the system ClassLoader, cloud features without clouds, starting at Oracle again, Airport, Prime, J4C and Helidon, helidon was fully opensourced in February, 2019, the origin Helidon idea was to be a cloud platform, Helidon's security is similar to WebLogic 8-9 security model, helidon separates between the user and service accounts, helidon's outbound security is automated, helidon was designed with docker in mind, helidon supports hollow jars and so directly the Docker layering, FatJARs are not worth the trouble, bare metal is the killer use case for FatJARs, hardcore classloaders are problematic with GraalVM, Helidon supports MicroProfile 3.0 all parts of it, merging all infrastructural modules in a single JAR is dangerous - beans.xml and class clashes are possible, helidon comes with JWT support fo outbound communication, in helidon you can provide you own main method, helidon comes with two modes: MicroProfile and Java SE, helidon is just a set of libraries, one library happens to be the server -- but is optional, helidon started as a Java SE platform only - microprofile came later, helidon was inspired by expressjs, trying to replicate the express experience, helidon ported the Java 9 flow API to Java 8 (by renaming the package) to backport the user experience, helidon uses the event loop of netty - never block the thread, most of Jakarta EE and Java SE libraries are not reactive, Java SE and MicroProfile modes can be used at the same time, helidon Java SE application is directly compilable with GraalVM to native image, Helidon 2.0 will come with native compilation support of MicroProfile, commercial support for Helidon will be probably possible, Helidon team answers questions on slack channel, no-one is interested in providing support of outdated software, MicroProfile is volatile - backward compatibility can be a challenge,

Tomas Langer on twitter: @langer_tomas and on github: https://github.com/tomas-langer