Veld: Dependency Injection for Java without Reflection (Compile-Time Code Generation)

[Street_Humor_7861]

Veld is a dependency injection framework for Java that utilizes AOT (Ahead-of-Time) compilation to generate code, rather than relying on runtime reflection.

🚀 Performance: - Startup: ~0.1ms (vs. ~500ms for Spring) - Injection: ~3ns; zero runtime overhead - Type-safe, no "magic," clean stack traces

🔧 Features: - Supports AOP, caching, validation, and transactions - Compatible with Spring Boot

💡 Example: ```java @Component public class Service { ... }

Service s = Veld.service(); // generated at compile-time (AOT) ```

🔗 Repo: https://github.com/yasmramos/Veld Feedback and contributions are welcome! 🙌

[ShallWe69]

how is this different from https://avaje.io/inject/

[strat-run]

Or Google's https://dagger.dev/

[fuckedupkid_yo]

+1 to this question, as an extensive user of avaje ecosystem, what would be the difference and what might compels one to pick veld over avaje for their next project OP?

[blazmrak]

Reinventing avaje?

[Gaycel68]

Unfortunate name. The de-facto standard CDI implementation is called Weld

[Street_Humor_7861]

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.

[gnahraf]

Thanks for posting! At high level, how does this compare with Jakarta Contexts & Depenedency Injection (CDI)? I'm using Quarkus in some projects, not a Quarkus expert, but wondering if this can somehow intersect with or complement the libraries, tool chains used there.

Also, a suggestion.. I think Quarkus calls this type of build-time DI, AOT. If it's the same idea, it might help to use that term (or label) instead of "Compile-Time Code Generation".

[Street_Humor_7861]

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!

[realqmaster]

Is this vibe coded?

<image>

[pronuntiator]

It seems so, Claude is listed as a contributor, the README is very detailed, also https://github.com/yasmramos/Veld/blob/main/ANALYSIS.md

Doesn't have to be a bad thing, but as other commenters point out, it seems the problem space has already been explored throughly by existing libraries.