"javax and Jakarta EE's future, singleton performance, exactly once delivery, DB authentication and refresh tokens, Kafka Java EE integration, distributed failures with microprofile, openjdk, oauth and refresh tokens, JSF and memory, green field architectures, javafx, embedded space, and interactive code review":
C64 and sports games, Weiden is not in Bavarian Forest,
soccer as motivation for programming, writing first programs in basic with 17, writing contacts management, PCs are boring machines, but good for business,
Java is the best programming language, Pentium 1 was introduced at CEBIT in 1993, the dream about an own booth at CEBIT came true, webdesign software based on applets (XPage) was very successful at SYSTEMS in Munich,
Markus was the business man and had no time for programming - like Steve Jobs, self-financing with selling products, competing with Microsoft and Adobe, writing a 4GL Java-based development environment like Visual Basic called XDev, Java Developers don't like the Drag and Drop programming experience,
building an IDE from scratch, discussions with Sun Microsystems about StarOffice integration, migrating from Swing to SWT and Eclipse, using Vaadin as UI technology,
connecting beautiful UI to DB was too hard, databases have more types than Java what makes code generation hard, in 4GL the database comes first, RapidEclipse is free but commercial support is available,
XDev provides tool and project support, RapidClipse understands rich database types and generates JPA POJOs, Hibernate importer, how to write queries in Java, implementing JPA-SQL is based on xtext by itemis and generates JPA-QL from SQL,
storing data is still too complicated, serialization looked promising but was too unsecure and only entire objects can be serialized, Kryo, Fast Serializer, JetStream (renamed to Microstream) serializer, the database engine stores objects in any file storage,
there is no impedance mismatch, the native Java storage engine, queries are performed with Java 8+ streams, JCA connector passes transactions and security context to the application server,
JCA prototypical implementation, kubernetes persistent volumes,
Bavarian Forrest is like Canada, the largest walking robot, Roding race car,
being a TV host on Giga, constant 30k downloads and the XDev TV, DVDs were more successful than TV,
JCon and the coding keynote, Java EE as secret weapon at JCon, stealing (adapting) the "no slides" ideas, the world first free, physical,
Java magazine JAVAPRO with 8500 readers, community prefers Java-only conference,
Eclipse Foundation won't get the rights to use Oracle's Java trademarks with the following implications:
The javax package namespace may be used within Jakarta EE specifications but may be used “as is” only. No modification to the javax package namespace is permitted within Jakarta EE component specifications. Jakarta EE specifications that continue to use the javax package namespace must remain TCK compatible with the corresponding Java EE specifications.
Jakarta EE component specifications using the javax package namespace may be omitted entirely from future Jakarta EE Platform specifications.
Specification names must be changed from a “Java EE” naming convention to a “Jakarta EE” naming convention. This includes acronyms such as EJB, JPA or JAX-RS.
Consistency, clarity and simplicity are crucial for the success of Jakarta EE. A clear cut e.g. renaming all packages from javax to e.g. jakarta
would introduce a consistent look and feel and branding. A single package strategy is better, than a mix of javax and jakarta namespaces.
Forcing projects to migrate (=search "javax" and replace with "jakarta") or introducing breaking changes every 20 years (J2EE 1.2 was introduced in December 12, 1999)
is acceptable. Such a migration could even introduce an opportunity to remove superfluous patterns, layers, indirections and libraries.
the result of pressing the break button on a BBC computer, and ZX Spectrum, Space Invaders with Basic,
extending minecraft with Java, accidental tester career, best interviewees got programmer jobs, hackers and testers, developers like the happy path, unit test coverage is useless without good asserts,
is 80% code coverage a valuable target?, code coverage was used as a motivation for writing tests, reflection utilities to increase code coverage, getters / setters never brake,
Code as a Crime Scene book, methods longer than a screen are problematic, the ratio between trivial and good asserts,
a good javadoc and unit tests follow similar principles, system tests are the most important one, unit testing is good for checking error scenarios, the more tests you have,
the easier it is to locate errors, the Law of Triviality requires standard names for test categories, integration testing and system testing,
reusing system tests as clients and stress tests,
UK retailer goes down, take the max load and double it,
jbmc is bytecode verification tool, diffblue cover generates unit tests, generating unit tests quickly for legacy backends, playground,
What is the AI in “AI for Code”? blogpost, diffblue blog, @diffbluehq
An itkonekt session for building a MicroProfile / Java EE application from scratch.
Metrics, OpenAPI, FaultTolerance, Configuration, multi-server deployments, ThinWARs, and even reactive (easter) eggs included:
An airhacks.fm conversation with Andrew Schofield, Chief Architect, Event Streams at IBM about:
1982, Dragon 32 and Basic Programming with 12, starting with JDK 1.0,
writing a JMS provider for WebSphere v6,
no ceremony JMS, Apache Kafka considered simple,
why writing a Kafka application is harder than a JMS application,
there is a big architectural difference between Kafka and JMS, or message queuing and event stores, Kafka remembers historical data,
JMS is about fowarding messages, with Kafka it is harder to write conversational systems, clustering singletons is hard, running Kafka on a single node is easy,
"deliver once and only once" is the killer feature of persistent JMS queues, JMS topics are nicer - you can send messages to unknown receivers,
the killer use cases for JMS and Kafka, JMS is good for system coordination and transaction integrity, Kafka is well suited for (IoT) event buffering and re-processability,
2PC, XA and the advantages of middleware,
in distributed transactions everyone has to remember everything, we only need distributed and rock-solid persistence,
kubernetes pods are stateless, challenges of using Kafka, setting up for production can take months for an average Java programmer with JMS background,
restarting Kafka brokers can be challenging, in Kafka you are communicating with the cluster, MQ is a collection of individual queue managers,
in MQ there is a directory of resources which knows where the queues are hosted.