The top 3 are, as you may have expected, Chez Scheme, Gambit-C, and Racket.
A fast R⁶RS Scheme compiler. Was proprietary for a long time, but is Free Software nowadays. (GitHub: cisco/chezscheme.)
I don’t find this particularly surprising.
An annotation processor that implements Jakarta JSON-B via code generation.
Subqueries, lateral joins, and arrays. HQL is growing into a rather powerful query language.
A Java source code transformation engine, usable for refactoring, API migration, and such.
Matthew Yglesias on the housing crisis.
I wasn’t aware that zoning rules are as strict as they are. It sounds a bit insane. I wonder what it’s like in Germany—probably no better if I were to guess.
But I suppose that in addition to a NIMBY vs. YIMBY question it is also an instance of the principle of trying to protect people by taking choices away from them. I wonder how often that works.
A test suite generator for Java. Attempts to automatically generate JUnit test suites that target a given coverage criterion by searching the space of unit tests, encoding in them the current behavior of the code.
An implementation of Jakarta JSON Binding (JSON-B).
An implementation of Jakarta JSON Processing (JSON-P).
Keymaps for keyboards with programmable firmware.
The only one for NEO (my preferred layout) appears to be for the Kyria, but I’m sure it can serve as good inspiration for other keyboards.
A series of audio episodes by ZSA comparing different kinds of mechanical key switches.
A promotional video by KeebMaker that outlines the ways an ergonomic keyboard is better than a conventional one. 5 minutes.
Reads JFR recordings from remote or local Java virtual machines. A programmatic interface to what you can do with jcmd
.
If I understand correctly this is not based on and unrelated to JFR Event Streaming.
Summary: Only log errors that require intervention, nothing else.
In general that’s reasonable advice and the article makes some good points, which are:
- logging is not free; it has a non-negligible performance impact
- there are better tools for most of the problems that people tend to use logs to solve
I would add:
- logs are a user interface; it is important to keep them minimal so that they stay usable
But some of the details don’t really make sense.
The article suggests using plain println
in order to avoid overhead, but in fact access to stdout
/stderr
is typically what’s most expensive about logging, which actual logging frameworks mitigate by offloading it to a worker thread.
The author recommends not to log progress but to use metrics instead. Surely having metrics is a good idea, but in batch processing, logging progress can make sense because it gives more immediate feedback after the rollout of a new version than metrics collection, which tends to be laggy.
There is also the implied assumption that you have a whole host of infrastructure at your fingertips that you can make use of to replace your logging, such as trace collection, metrics collection, and so on. That may be true in a Cloud environment, but in other environments such things may be more expensive to maintain.
Overall I agree with the notion that you should err on the side of logging less rather than more. But if you do have something to log, then (1) do it freely and (2) use a proper logging framework.
My build recipe for a runtime container image based on UBI Micro1 and the latest feature release of OpenJDK.
Small, secure, and tracks OpenJDK upstream. If you like to be on the latest OpenJDK (rather than some vendor’s LTS), this is for you.
I use it for this website and am very happy with it.
Footnotes:
A general-purpose physics simulation library with a focus on both speed and accuracy. Suitable for biomechanical, robotic, and other research-related simulations as well as graphics animation (such as in video games).
Has a C API, which makes it easy to bind to from any language.
A Java library for event sourcing. Based on the Cloud Events specification and designed to be a library of utilities rather than a framework.