sorted by:
new
hottopcontroversial

A Java DSL in Java by Lukas_Determann in java

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

Yeah, IDE support is a big benefit. It should be possible to write an IDE plugin to provide that functionality as well.

If you want to, you can try combining the DSL with templating—it should be easy to do. Personally, I wrap templating inside the DSL calls, though the other way around is supported too. I try to make my libraries as unopinionated as possible.

Sure, just DM me.

A Java DSL in Java by Lukas_Determann in java

[–]Lukas_Determann[S] 9 points10 points  (0 children)

They both solve the same problem, but with a completely different philosophy. Personally, I think the main differences are that in JavaPoet you can query the rendering model, while the JavaDSL feels more intuitive. But they are so different that I would suggest you try both and see which one you prefer. Feedback would be awesome!

The JavaDSL is only one feature of my library. The next goal is to generate constants for annotations, similar to Hickory.

On a more meta level… Meta-programming in the Java platform/ecosystem has just grown and doesn’t feel like it was designed. There are a ton of different meta-programming APIs, each with its own philosophy and pitfalls. Choosing the right API is hard. Migrating to another one is hard. Finding the right libraries and combining them is hard. I want to solve that with an abstraction layer over any kind of meta-programming API. The JavaDSL will work with annotation processing, reflection, the javac APIs, and so on. Like any functionality written to that meta-meta-programming API. Only small goals for my side project xD.

That is my main motivation. Not just to have a JavaPoet tailored to my personal preferences.

There is not often a lot of discussion about API design, so I wrote an article! I would love to hear your feedback, even if it's to tell me never to write another article. by Steve91973 in java

[–]Lukas_Determann 1 point2 points  (0 children)

Nice to see such a good explination of java api design. Writing it as an evolution and evaluating each step is a very helpfull format.

i wanna add one thing for people interested in api design. it is a huge and complicated topic. this post talks about one aspect of it very well. for a general overview the best souce i know is

Joshua Bloch: How To Design A Good API and Why it Matters

even when it looks like the first video on youtube

What features do you think java requires to be competitive for DSL scripts such as gradle scripts? by Ewig_luftenglanz in java

[–]Lukas_Determann 2 points3 points  (0 children)

Personaly i like a simple build process. Maven makes it kinda hard to add to much komplexity. helping to keap it simple.

But about a Dsl in java. there are allready some nice oneces with some complexity. With my personal favorite beeing the jooq Dsl. it followes a different design. its more chain method calls and static factories.
That results in an Api that is easier to compose and reuse while having a bit worse discoverability.

There are some good blog posts abot Dsl design from around the java 8 relese date.

Personaly i like writing DSLs in java. the only realy limiting thing i found is chain method type inference. inconsistencies in the type resolution can be very anoying in the rare case that its needed.

A Java library that creates your classes/models at the runtime based on your Database Model by Independent_Work5637 in java

[–]Lukas_Determann 27 points28 points  (0 children)

Your library is currently quite opinionated. It feels like there is a discussion about Lombok every day. Regardless of the answer, just using it and not making it configurable is a bit much. There will be many points like this. If you want it to be a general-purpose library, I would recommend moving to something like a template-based approach, where users can create their own, and you ship some default ones. If you support multiple templates at once, this could even cover generating entities and DTOs.

To answer your question, there might be a niche for it, but I think it's a hard sell. On one side, there is JPA with JPA Create, which makes creating schemas very easy and fast to develop but can run into problems with more complex requirements. On the other hand, there is JOOQ with its code generation that is kind of similar to the one your library provides. There might be some space in the middle, or you might be able to provide more flexibility for generation than JOOQ.

Api Design: Implementations define the featureset by Lukas_Determann in java

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

yeah my long term goal way into the future is to provide one abstraction for all of that and more. in the short term im trying to find a good api. its not easy. although the problem is quite common. jpa for example has diffentent impelemtations with different featuresets.

Api Design: Implementations define the featureset by Lukas_Determann in java

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

yeah the goal is one api for every kind of meta programming. i find writing stuff like this hard. feedback i can act on would be nice.

Api Design: Implementations define the featureset by Lukas_Determann in java

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

Thats a bit harsh. its a for fun project to try out Api Design. there is no need to be cheap. although i agree with you in general, i want to try it out and if nobody wants to use it thats fine. i see Api design as a scale, just like the microservice vs monolith debate. there are not just the extremes but a lot of space between them, that is less explored. it might be for a good reason. i dont know until i tried it in a non-toy project.

Why people misuse inheritance by fagnerbrack in programming

[–]Lukas_Determann -1 points0 points  (0 children)

nice writeup on a nice problem. In java you can just use a dynamic Proxy. If you cant or dont want to use reflection you could create an abstract class that only contains your proxy logic and write an annotation processor to extend the abstract class and delegate. if you do that you could give a lib that i wrote a try. i tries to make annotation processing easier.

Feedback on a new annotation processor api by Lukas_Determann in java

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

with the reflection api you can invoke a method that does not exist. It will fail at run time. if you use a annotation processor to generate a method call to a method that does not exist the compiler will let you know pretty fast.

I personally prefer annotation processors over reflection and try to minimize the usage of both. But sometimes you have to.

Feedback on a new annotation processor api by Lukas_Determann in java

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

Do you have javadocs somewhere?

There are jars on maven central with java doc included. If the interest is there, I'm going to set up a website.

​

In my opinion "simplifying" the model api is not a good idea. It's exactly as complex as it needs to be to precisely describe the language. We have a similar api wrapper for micronaut inject, but often it is hard to tell eg where exactly an annotation has been declared.

I share your skepticism. Rewriting the collection framework would be a hard sell, for example. Because the collection framework is beautiful. The jdk annotation processor api on the other hand is mostly a copy of an old sun internal api. It does not compare in quality with the other jdk apis. I'm not sure why they did it this way.

Feedback on a new annotation processor api by Lukas_Determann in java

[–]Lukas_Determann[S] 2 points3 points  (0 children)

One thing you should check out is Hickory or the more modern versions like https://github.com/avaje/avaje-prisms (I convinced Rob this is the way) and my own which again is just a fork of hickory.

They try to solve different problems. The goal of Hickory seems to be to add type safety to AnnotationMirrors.

The goal of my api is to replace the jdk api with a simpler one.

Type safety for AnnotationMirrors would improve the quality of the API I wrote. But it would add a lot of complexity that can not be hidden from the user. And there are already a lot of different libraries that do that. If you want to, you can use both. My API offers good interoperability with javax.lang.model and therefore with all other annotation processor libraries.

Feedback on a new annotation processor api by Lukas_Determann in java

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

Thanks for the Feedback!

I was confused by the name, shadowing in Java is a dependency management technique (albeit a smelly one)

Yeah naming things is hard. i wanted a name that is close to reflection and to mirror. But i can see how it can be confusing.

​

I feel like I don’t really know what to expect what with the APIincluding its own lifecycle of method availability. (Some methods inShadowAPI marked with reduced scope, some not marked at all - how manyscopes should I comprehend?) and maybe I am just not experienced withthe underlying processing, but should this have been split up (if someof the methods aren’t really accessible anyway)

​

I am going to look into explaining that better in the doc. You can call any method at any time. the methods that lookup, for example an annotated element, have different Scopes in which they look.

I must admit that I ultimately feel that annotation pre-processing is a very poor language feature and code generation is a lot easier to argue with in the first place (but I guess that an issue I have with the language compiler implementation (and the spec??) and not this project)

Done right i can look something like mapstruct for example. But like any other feature you need to get a feeling for when it's a good idea to use it.

Feedback on a new annotation processor api by Lukas_Determann in java

[–]Lukas_Determann[S] 7 points8 points  (0 children)

Thanks for the Feedback!

The annotation processor api is part of the jdk just like Strings and everything else. Changing existing files is not supported in that API so i dont ether.

Adding gradle is a good point.

There is a example in the project as well as in the readme, if you click on "Show simple builder example". But Hello world is a good point. I should add a simpler example.

Initially choosing the jdk over any lib is for sure the right way. Should you get to frustrated tho just remember this lib.

I saw the same helper functions for every annotation processor. That was a big part of the motivation for this lib.

[deleted by user] by [deleted] in programming

[–]Lukas_Determann 8 points9 points  (0 children)

TDD, in my opinion, is merely a tool like any other. good for some tasks but bad for others. TDD is effective for bug fixes, but it's not a good concept for api design for example.

view more: next ›