Spring Tips: Useful Annotation Processors

Hi, Spring fans! In this installment, we look at some very useful annotation processors that'll help you in your day-to-day working with Java and Spring. #java #java21 #graalvm #code #coding

[@AlexandrStepanov-zl4ed]

Can't wait for dear Josh add timecodes.

[@gr3w]

My favorite use of MapStruct is to map JSON classes to DTO and/or @Entity beans and vice-versa. It's nice to be able to specify defaults in the @Mapping for JSON -> DTO, and much easier to source JSON data from multiple entities for Entity -> JSON.

[@jootuubanen7727]

Finally we got adds here. Spring tips with some exhilarating extra info ;)

[@jootuubanen7727]

Some extra cash to Josh ;)

[@RickDkkrd]

With mapstruct you don't need to define any beans to make the mappers singletons, just set the component model annotation param to "spring". Also, it has extensions to integrate in with lombok to use its builders for example, and with Spring boot to auto register mappers as convertors in the conversion service.

[@simongeard4824]

I can give you an interesting (if largely historic at this point) example of where DTO mapping is useful - the Google Web Toolkit (GWT) was a platform which transpiled Java to Javascript, but it had significant restrictions on the Java features it supported (e.g. it was very slow to support Java 5 features like generics and annotations). So having tools to map between JPA entities (or in those cases, maybe plain Hibernate) and the transpilable DTOs was vital...

[@MrQchien]

Great video 👍
Hi Josh Long, I have a question, how I can start the spring application for long running task with any API endpoint. For example, I wanna create a change stream mongo to listen an event continously

[@romanchumak1586]

Thans for the video. Can you please create a video about CompletableFuture and how to use it on Spring and RestClient or RestTemplate

[@boardlife_cali]

Hum first

[@sofianezerrouki]

Java-SPI
Record-Builder
Lombok
manifold
mapstruct

[@remek712]

I have a situation at work where my Product Owner asks me about my progress every day during the Daily. This is starting to make me feel pressured to deliver tasks faster. Additionally, he emphasizes the importance of quick development. On the other hand, it's hard for me to stand up to him and tell him that I don't need to be hurried and rushed. I feel like he is using Sprints and Dailies as a tool to exert pressure

[@ekadet]

. You could approach your Product Owner with a constructive perspective, saying something like: "I understand the importance of delivering quickly, but I want to ensure quality and accuracy in my work. Could we discuss setting realistic goals and expectations together?" This way, you open a dialogue without confrontation, focusing on collaboration and quality.

[@furkatlapasov5346]

​@@ekadetwould love to look at textbook that kind of art of negotiation is taken from

[@hackwithharsha]

00:23:30 Does anyone know how different MapStruct is from ModelMapper.. Looks like, ModelMapper does the same thing

[@CyanToryu]

Modelmapper uses reflection at runtime, MapStruct generates the implementation of the interface in the target folder.

[@muhammed_ozbilici]

@CyanToryu also mentioned, reflection. and that's why mapStruct is faster than modelMapper also type-safety because it's compile time checking.

[@iimuhin]

Manifold is new to me

[@DF-ss5ep]

That Manifold is looking too much like groovy. The dimensions thing is pretty cool, though.

[@SM-vg7zl]

Unlike with groovy (or kotlin etc.) with manifold you stay in Java. Another critical difference re groovy is manifold preserves type-safety at compile-time. Additionally, groovy/kotlin/etc. have nothing at all like the SQL support manifold provides or other static metaprogramming capabilities there.

[@DF-ss5ep]

@@SM-vg7zl That's good. Groovy's lack of static type checking was what I disliked the most.

[@ansismaleckis1296]

That Manifold looks dangerous af. Cool for a hobby project but I would not use it at my job.

[@SM-vg7zl]

Manifold is a _compiler_ plugin, so most of its features exist exclusively during compilation, no runtime hocos-pocus. Also, as the FAQ points out: To date, Manifold has adapted to eight major Java versions since its debut, always well in advance of Oracle’s official release schedule. This is since Java 8, so it is pretty well battle tested. _shrug_

[@simongeard4824]

@@SM-vg7zl It's not just the maturity/stability of the project - it's the fact that you're ending up with code which _claims_ to be Java, but will be utterly unfamiliar to non-expert developers. Bringing new stuff up to speed on our codebase is difficult enough already with a language they're well versed in, much less one with weird behaviours they can't find documented anywhere.

[@SM-vg7zl]

@simongeard4824 you’re missing the point. The idea is that the “unfamiliar” code is replacing tons of boilerplate nonsense resulting in a much improved developer experience and more readable code.

[@simongeard4824]

@@SM-vg7zl No, I understand the benefits. I just don't think they're worth the downside of having 'java' code filled with things that cannot be found in any Java reference material. Like I say, bringing new developers up to speed is hard enough without that

[@johnsandwich6726]

why do we need a recordbuilder if we have the lombok ?)