Earendil is the company, Lefos the first product, an agent that has email as primary interface.

If you really want to write really performant java code, the word "spring" should not even be mentioned. Same thing for Jackson, write you own lazy json library if the data is bigger than a few 100k.

The code will not look pretty but it will be very fast.

Speaking of Jackson and performance... I have been working on Jagger for a while now, which aims to replace all that reflection during databind with annotation processing.

I am trying to aim for something like Mapstruct for the developer experience, since everybody loves Mapstruct. With Jagger, you bring a parser (JSON/XML/whatever), define some databind methods, and it generates the implementation for you.

So far I've only had my own use cases, so I would love to have some wider feedback.

https://github.com/Tillerino/jagger

A huge mistake, I've seen a lot of code where clearly the author thought that just adding "synchronized" would have solved any concurrency issue. And no one even talks about how synchronized is implemented, basically a monitor on the object.

The point of view is usually also wrong, they focus on the method call flow while they should think about protecting access to shared data.

Yeah. The more I learn about concurrency (which I think is a fair amount at this point), the more I respect Erlang. It was so ahead of its time with this stuff.

As I said, I feel like when I reach for a lock, about 95% of the time it’s because I don’t really understand the problem well enough.

Yes, but that's not the path that modern frameworks suggest nowadays.

0. Fix your algorithms, code optimization comes later

1. Avoid abstraction as much as possible, convoluted flow control and reduce useless objects creation

2. Learn how to manage concurrency correctly, focus on the data being accessed by multiple thread and focus on sequential access

3. Don't use bloated frameworks (all of them)

4. Consider rewriting common libraries following the principles above and with only the functionalities you actually need.

Easy 10x improvement, try it.

> Java SE subscribers will receive JDK 8 updates until at least December 2030

Not for clients with a commercial license, and there are many.

Sadly it's not maintained anymore and even the intellijidea-derived decompilers are better nowadays (used to be horrible until a few years ago).

In addition to the limitation to classfiles built for Java8, it sadly has a hard time decompiling new language features even if compiled for a Java8 target. And then there is the well known bug that decompiling full jars in bulk does not get you the same output you see in the UI but orders of magnitude worse... jd was great until it lasted, helped me solve a lot of issues with verdors over the years.

The most annoying thing in intellij (fernflower is it) is that it does not maintain correct line numbers, so when debugging, there is a divergence. Still you need to download sources but not always they are available

I've only seen that with transient dependencies that are instantiated via Reflections

In my opinion, you shouldn't expose it to a browser, it's not what is good at, build something custom that converts to json. Like using REST to talk between backend services, makes no sense using a human readable protocol/api especially if there are performance requirements (not a call every now and then with a small amount of data returned).

To be fair, it was intended to be for browsers. But it was designed alongside the HTTP/2 spec, before browsers added HTTP/2 support, and they didn't anticipate that browsers wouldn't end up following the spec. So now it only works where you can rely on a spec-compliant HTTP/2 implementation.

The article seems to be an advert for this, with its plug of that hosted gRPC<->JSON service.

As someone that used it for years with the same problems he describes... spot on analysis, the library does too much for you (e.g. reconnection handling) and handling even basic recovery is a bit a nuisance for newbies. And yes, when you get random failures good luck figuring out that maybe is just a router in the middle of the path dropping packets because their http2 filtering is full of bugs.

I like a lot of things about it and used it extensively instead of the inferior REST alternative, but I recommend to be aware of the limitations/nuisances. Not all issues will be simply solved looking at stackoverflow.

AKA Bit banging PWM, never seen it working with this kind of displays, nice project, it can be done even with higher frequency signals too (requires an oscilloscope and a few tries to get a smooth signal).