jvm-serializers
SLF4J
jvm-serializers | SLF4J | |
---|---|---|
7 | 23 | |
3,277 | 2,268 | |
- | 1.0% | |
4.4 | 7.8 | |
8 months ago | 11 days ago | |
Java | Java | |
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
jvm-serializers
-
Fury: 170x faster than JDK, fast serialization powered by JIT and Zero-copy
Compared with protobuf, fury is 3.2x faster. When comparing with avro, fury is 5.3x faster. Compared with flatbuffers, fury is 4.8x faster. See https://github.com/eishay/jvm-serializers/wiki for detailed benchmark data
-
The state of Java Object Serialization libraries in Q2 2023
First, there's benchmarks here if you haven't seen it: jvm-serializers. Not terribly scientific, but it's something. To make any decision, you really need to benchmark your own object graph and it's important to configure the serializer for your particular usage. Still, it is sort of useful for comparing frameworks. It would be interesting to see how Loial performs there. Ping me if you add it.
-
Up to 100x Faster FastAPI with simdjson and io_uring on Linux 5.19+
It depends. Some binary encodings such as flatbuffer are actually slower than some JSON libraries. There's a wide range of performance even in the JSON libraries themselves. Generally the faster JSON libraries are the ones that work on a predefined schema and so are able to generate code specifically for that JSON.
-
Go standard library: structured, leveled logging
> I'm surprised this is up for debate.
I looked into logging in protobuf when I was seeing if there was a better binary encoding for ring-buffer logging, along the same lines as nanolog:
https://tersesystems.com/blog/2020/11/26/queryable-logging-w...
What I found was that it's typically not the binary encoding vs string encoding that makes a difference. The biggest factors are "is there a predefined schema", "is there a precompiler that will generate code for this schema", and "what is the complexity of the output format". With that in mind, if you are dealing with chaotic semi-structured data, JSON is pretty good, and actually faster than some binary encodings:
https://github.com/eishay/jvm-serializers/wiki/Newer-Results...
-
Scala 3.0 serialization
You could use any of the JVM serialisers which should still work.
SLF4J
- Slf4j.org TLS Certificate Expired
-
dazl — a facade for configurable/pluggable Go logging
A few years ago, my team moved from Java to Go. Working on Go projects, we encountered a wide variety of logging frameworks with different APIs, configuration, and formatting. We soon found ourselves longing for a logging abstraction layer like Java’s slf4j, which had proven invaluable for use in reusable libraries or configuring and debugging production systems. So, not long after moving to Go, we began working toward replacing what we had lost in slf4j.
-
Fargate logging thru console awslogs or directly to Cloudwatch?
I'm not familiar with Serilog as I code mostly in Java, use slf4j (logs to stdout) and our apps send logs to Cloudwatch using the task definition's awslogs configuration. I prefer it this way because I can customize the log configurations in my task definitions. Also the default stream name has this format prefix-name/container-name/ecs-task-id so I can easily identify the logs of the task I want to look at. I haven't experienced any downsides with this approach and our apps publish a shit ton of logs. Cloudwatch approach looks like you can customize the stream name?
-
How does Loggers get multiple parameters in functions
slf4j is open source. You can look at the code.
-
Logging in your API
Java -> Logback, Log4j2, JDK (Java Util Logging), Slf4j, e.t.c.
-
Primeiros passos no desenvolvimento Java em 2023: um guia particular
slf4j para padronização dos logs;
- What are some of the biggest problems you personally face in Java?
-
must known frameworks/libs/tech, every senior java developer must know(?)
SLF4J
-
Go standard library: structured, leveled logging
> My God. Logging in protobuf?
Yes, or any other data format and/or transport protocol.
I'm surprised this is up for debate.
> Logging is the lowest of all debugging utilities - its the first thing you ever do writing software - “hello world”. And, while I admire structural logging, the truth is printing strings remains (truly) the lowest common denominator across software developers.
This sort of comment is terribly miopic. You can have a logging API, and then configure your logging to transport the events anywhere, any way. This is a terribly basic feature and requirement, and one that comes out of the box with some systems. Check how SLF4J[1] is pervasive in Java, and how any SLF4J implementation offers logging to stdout or a local file as a very specific and basic usecase.
It turns out that nowadays most developers write software that runs on many computers that aren't stashed over or under their desks, and thus they need efficient and convenient ways to check what's happening either in a node or in all deployments.
[1] https://www.slf4j.org/
- Logback en Springboot
What are some alternatives?
fury-benchmarks - Serialization Benchmarks for fury with other libraries
Apache Log4j 2 - Apache Log4j 2 is a versatile, feature-rich, efficient logging API and backend for Java.
Apache Avro - Apache Avro is a data serialization system.
Logbook - An extensible Java library for HTTP request and response logging
zio-json - Fast, secure JSON library with tight ZIO integration.
tinylog - tinylog is a lightweight logging framework for Java, Kotlin, Scala, and Android
opentelemetry-specificatio
kibana - Your window into the Elastic Stack
janino - Janino is a super-small, super-fast Java™ compiler.
graylog - Free and open log management
grpc-dotnet - gRPC for .NET
Logback - The reliable, generic, fast and flexible logging framework for Java.