drtse4

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.

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.

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.

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).

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).

Haven't checked Fuchsia in a while, very glad to see that they have extended the documentation.

Did they improve the initial steps to get up and running too?

(I remember it took hours to clone all the subprojects and most of the times something failed along the way, even worse than downloading the Android sources)

Can confirm that the internal pull up/down are there and most libraries can enable them (alternatively this can be done manually via terminal after each restart).