ea-async
Vert.x
ea-async | Vert.x | |
---|---|---|
4 | 46 | |
1,362 | 14,080 | |
0.2% | 0.4% | |
0.0 | 9.5 | |
about 2 years ago | 5 days ago | |
Java | Java | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
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.
ea-async
-
Fluent: Static Extension Methods for Java
I feel like this misses the reason I like extension methods: discoverability.
With an extension method, I can do `object.` and my IDE will tell me what can be called on object. With a static helper method, it isn't as easy to know what is available. I need to know which helpers actually exist.
Since this doesn't have IDE support, it doesn't help discoverability. I'm not going to get nice autocomplete that shows me what is available. In fact, my IDE is going to highlight it as a bug. If I have a spelling mistake, I won't be able to easily pick it up - I'll assume it's just the normal complaint for all of these fluent extension methods.
That makes this simply syntactic sugar rather than something that actually helps me discover things more easily. It then hurts readability and navigation since I can't easily click through to get the definition of the method.
On a more general note about Java, things like this are one of the reasons I don't love the Java ecosystem. People try to change the behavior of Java in really hacky ways that don't work well. I understand that it's an attempt to overcome shortcomings in the language, but when one looks other languages it becomes clear that Java could have just evolved the language to be better. Java has lots of good things and I'm not looking to argue that. However, when I look at things like this, it makes me think that Java needs to really address the core language.
Instead, we get lots of tools like this which might be nice, but make it really hard to understand what's going on. Electronic Arts created an async/await library that'll do crazy stuff to let you do async/await style programming (https://github.com/electronicarts/ea-async). Yes, Java is doing good things with structured concurrency and Project Loom, but the point is how people keep trying to work around the language. There are so many POJO generators it isn't funny: AutoValue, Immutables, JodaBeans, Lombok, and more I'm probably forgetting. Java records don't fulfill everything (and they're at least a decade late). Java doesn't support expression trees for lambdas so libraries sometimes do crazy hacky things to make that exist.
Java is a great piece of technology, but it feels like people are often trying to overcome issues with the language through really hacky means in a way that I don't see in other languages. Java is getting better about modernizing the language, but it still feels like people are running against the language more than in other ecosystems.
-
What are some forbidden, broken, possibly even black magic stuff that you can do in Java and to that extent, JVM in general?
https://github.com/electronicarts/ea-async via preprocessing the bytecode in the jar or at start time
-
Concrete reasons why one would choose java over node.js?
Like I mentioned in the other comment - EA Async can help there, it brings async-await semantics to CompletableFutures and resilience4j has CompletableFuture decorators that you can apply to get retries, circuit-breakers and all the good stuff they offer.
- Async await in Java
Vert.x
-
Spark – A web micro framework for Java and Kotlin
https://vertx.io/
It's actively maintained with full time developers, performant, supports Kotlin out of the box, and has more features?
-
Reactive database access on the JVM
Hibernate Reactive integrates with Vert.x, but an extension allows to bridge to Project Reactor if wanted
-
Looking for a coroutine-based message broker implementation for inter-app communication.
Have you looked at Vert.x?
-
What's the state of server-side frameworks with Kotlin support today for small teams?
Explicitly so:
-
Anything close beam/otp for other languages?
I really like Eclipse Vert.x... As both an Erlang dev and Java dev, it's a great synergy and soon to have support for Virtual Threads similar to BEAM.
-
Go doesn’t do any magical stuff and I love that
There are many lean, popular, non-magical libraries in Java land. (https://quarkus.io/, https://vertx.io/, etc). Spring is a monster 😱. Its like comparing Kubernetes (written in Go) with some lean framework in another lang.
- PFA vs SRL
-
Favorite hidden gem library?
Eclipse Vert.x - Add amazing Async to any Java stack
-
Codeberg a GitHub Alternative from Europe
Vert.X example: https://github.com/eclipse-vertx/vert.x/blob/master/src/main/java/examples/EventBusExamples.java#L106 (couldn't even find docs)
-
Quarkus fundamentals
In fact, it builds on top of proven standards such as Eclipse MicroProfile or frameworks such as Vert.x or JAX‑RS.
What are some alternatives?
Reactive Streams - Reactive Streams Specification for the JVM
Akka - Build highly concurrent, distributed, and resilient message-driven applications on the JVM
FrameworkBenchmarks - Source for the TechEmpower Framework Benchmarks project
javalin - A simple and modern Java and Kotlin web framework [Moved to: https://github.com/javalin/javalin]
Quasar - Fibers, Channels and Actors for the JVM
Quarkus - Quarkus: Supersonic Subatomic Java.
navigo - A simple vanilla JavaScript router.
Micronaut - Micronaut Application Framework
CreepyCodeCollection - A Nonsense Collection of Disgusting Codes
RxJava - RxJava – Reactive Extensions for the JVM – a library for composing asynchronous and event-based programs using observable sequences for the Java VM.
kotlin - The Kotlin Programming Language.
helidon - Java libraries for writing microservices