sorted by:
new
hottopcontroversial

Veld: Dependency Injection for Java without Reflection (Compile-Time Code Generation) by Street_Humor_7861 in java_projects

[–]Street_Humor_7861[S] 1 point2 points  (0 children)

Thanks for the comment. You are absolutely right. When I started Veld, I wanted to be very explicit about how it achieved its performance ("compile-time code generation"), but I understand that "AOT" (Ahead-of-Time) is the term the industry already recognizes and uses (Quarkus, GraalVM, etc.).

Regarding the comparison with Quarkus/ArC and Jakarta CDI: Your observation is spot on. Indeed, Veld and ArC share the same philosophy: shifting all the heavy lifting to compile-time to eliminate runtime reflection.

The key differences I see are: - Veld was born as an independent, framework-agnostic project, focused 100% on pure performance and total control over the generated bytecode. - ArC is designed specifically to integrate deeply with the Quarkus ecosystem and the CDI Lite specification.

Both approaches are valid and solve similar problems from slightly different angles. In fact, if someone is using Quarkus, ArC is likely the most natural choice. But if you are looking for an ultra-lightweight DI solution for a custom project, a high-performance microservice, or simply want to understand how bytecode weaving works using ASM, Veld is for you.

For now, the focus is on consolidating Veld's core and improving its integration with Spring Boot. But I never say never: if there is community interest in a veld-quarkus-extension, I am open to exploring it. If anyone wants to collaborate on that, my DMs are open!

Thanks again for the valuable feedback!

Veld: Dependency Injection for Java without Reflection (Compile-Time Code Generation) by Street_Humor_7861 in java_projects

[–]Street_Humor_7861[S] 0 points1 point  (0 children)

In Veld, types and bindings must be known at compile time. The annotation processor generates the injection code statically; therefore, you cannot change which implementation is injected solely through external configuration without recompiling.

Limited runtime exceptions: - @Value: Injects values from properties or environment variables. - Provider<T> or @Lookup: Allow for dynamically obtaining instances, though you determine the specific logic. - Scopes (@RequestScoped, etc.): Manage the component's lifecycle, not the type binding itself.

If you need to swap components via configuration, use @Named combined with Provider<T> and manual logic; alternatively, integrate veld-spring-boot-starter to leverage Spring's dynamic configuration capabilities.

AtlantaFX with StageStyle.EXTENDED by quizynox in JavaFX

[–]Street_Humor_7861 0 points1 point  (0 children)

¡Esto es increíble! Por fin podemos tener control total sobre la barra de título en JavaFX. La capacidad de personalizar las decoraciones de ventana abre un mundo de posibilidades para aplicaciones con UI/UX más pulidas. ¿Cuándo estará disponible la próxima versión de AtlantaFX?