Otavio Santana

Thank you, and I am glad that you enjoyed it.

Thank you for your opinion.

Indeed, simplicity is hard to trust, mainly because we have a complexity bias. We start to realize it with time and experience.

It is expected to feel more confident with a thousand layers and interfaces because you might need them in the future instead of doing what you need and then refactore the code.

If I can use a picture, I would use this:

Use when it makes sense; don't try to put several layers because it is cool, and focus on simplicity.

> But how a new implementation of a service might be provided, given that the service doesn't have an interface and, hence , it isn't even a service ?

The simple answer: is refactoring. With the code provided, a good test, and documentation, you can extract the interface. Modern IDE can help you to do it as well.

> I would be curious to understand how do you think to use the template one, without interfaces ?

The interfaces are a requirement. But please, don't use all the patterns all the time. My point is: to use it when it is needed.

> how do you deal with functional interfaces?

It makes to use, thus, use it.

Yes, you can use interfaces and explore patterns without overengineering

What is easier:
See the future or refactor the code and put interfaces when needed?

I am not against interfaces, but I don't believe that all applications need SPI, thousands of interfaces, and several layers; just because Netflix or other companies do, it does not make sense either.

My point is the balance, and yes, I spent more time putting into tests and documentation instead of creating an interface because you might need it in the future.

Thank you, I will fix it, ASAP.

That is the code designer dream!

I am glad that you enjoyed it.
For now, I used this formula to migrate 45 microservices.
So far, so good.

You are right!
Thank you for bringing this up!

Indeed, the balance is crucial.

Thank you, Ronaldo; I am glad that you enjoyed it.

Thank you for your valuable feedback; I genuinely appreciate it. Your mention of several annotations in the Lombok framework brings up some critical points.

As I mentioned, working with any framework involves trade-offs, and Lombok is no exception. Every design and architectural decision comes with its set of advantages and disadvantages.

One significant concern I have pertains to using the Data annotation in Lombok. This annotation, while convenient, has the potential to break the principles of encapsulation that are fundamental to Object-Oriented Programming (OOP). In traditional OOP, we emphasize the concept of hiding data and exposing behavior, encapsulating data within classes to maintain data integrity and control access. The Data annotation, however, tends to encourage an anemic model, where data and behavior are separated. It can lead to data inconsistency issues because it blurs the boundaries between data and behavior.

It's important to note that frameworks like Lombok can sometimes misguide developers by providing convenient shortcuts that may not align with best practices. I recommend using IDE templates or other tools that promote a more explicit and maintainable code structure in cases like these.

Again, thank you for the feedback.

Hey, thank you for your feedback.

I hope to get better in the following video.

The emphasis on modern API design has undeniably shifted towards declarative APIs. This approach is rooted in the idea that APIs should prioritize safety and actively prevent developer errors. As software engineers, we must grasp the trade-offs inherent in the frameworks we use. Problems stemming from inadequate encapsulation can potentially lead to security vulnerabilities, and it's worth remembering that in the realm of security, we adhere to the CIA triad, where 'C' stands for consistency.

I strongly encourage you to delve deeper into object-oriented programming (OOP) principles and explore classic literature like "Clean Code." These timeless resources champion the primary objective of concealing intricate details while exposing desired behaviors.

It's essential to recognize that if an API guides a developer toward a mistake, we should seriously question whether it makes sense to include such a feature. Sometimes, these seemingly helpful additions can inadvertently act as auto-destruct buttons, leading to unexpected consequences. Thus, carefully evaluating an API's design and its potential impact on developer actions is paramount to ensure its effectiveness and safety.

Again, super thank you for the feedback.

Optional in Java it still WIP, since Java 11, it has made several progress.

Optional is a good tool, but there is no silver bullet.

In the end, we are talking about trade-offs.

Hey Jasper.

Thank you, I included this book on my list. This one will be my next.

That is my pleasure, always.

Those are great points; thank you for sharing.

Good point, thank you.
I'll request an update.

Hey, Robert. Thank you for your comments.

I don't follow your "security". Could you explain better?

But if you look at the CIA triad and the ISO/IEC 27001, you'll see integrity and consistency.

Does encapsulation help with consistency?

Does encapsulation help avoid leaks in the application?

If you look at clean code by uncle bob, you'll see the expression "OOP hide data to expose behavior" and guarantee that you don't have an inconsistency in your application, such as a null item in a list is a sample of it.

The point is, you're right. A good encapsulation helps with knowledge, abstraction, and expressiveness. Furthermore, it helps with consistency and data integrity on some occasions. Those are not exclusive but inclusive.

I'm glad that you enjoyed it.

It has been updated, please check it now.

Thank you.

Hey Nicolas.
Thank you for sharing.

It is a good one.

You're welcome.

Thank you, I'm glad to hear it.

Thank you.

Thank you.

Yeap, this is one solution to move away from the reflection, with the same API, so with annotations.

We've changed the issue to compilation time from the runtime.

You're welcome.

Thank you :)

Yes, I know, and I have this feeling. Migration to Java 11 from Java 8 is a colossal pain, mainly because of the modules.

The good news is several Java EE/Jakarta EE vendors have support in Java 11. Furthermore, the next version in July will release with Java 8/11 as a minimum requirement.

What I did to migrate as keep in the maven as Java 8 while I compiled with Java 11. And I did step by step to relocate; I did not move in a huge step.

Now, JSF still alive.

There is a group around that you can join if you wish:

https://jakarta.ee/specifications/faces/

Furthermore, there are several libraries such as primefaces that has released the latest version this month:

https://mvnrepository.com/artifact/org.primefaces/primefaces

Please check with the dependencies that I sent to you.

I checked from the documentation:

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jms/support/converter/MappingJackson2MessageConverter.html#setTargetType-org.springframework.jms.support.converter.MessageType-

Hey, I'm glad that you liked it.

Yes, I have it in a repository:

https://github.com/platformsh/java-quick-start/tree/master/spring/spring-jms

Please, let me know if there is any further question. I'll have all the pleasure of answering it.

Thank you, fixed.

Nice write-up! Btw. @Hibernate Validator supports the validation of monetary amounts and Currency out of the box; just add the Money JSR API:
https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#section-builtin-constraints

Ref: https://twitter.com/gunnarmorling/status/1125709428945301504

Yes, that is an issue when we have a class with several fields.

I know that there are several frameworks whose can help us with this builder. Such as IntelliJ IDE with several plugins and templates. And these frameworks:

http://immutables.github.io/

https://projectlombok.org/

Hey, thank you. I glad that you liked it.

Yes, I could do a fluent API on the builder to make even more natural the constructor.

The point is the scope, and I would like to create both the builder pattern and a rich model to get data integrity.

There is an excellent article whose covers more this detail:

https://www.code-held.com/2019/04/29/robust-builder-pattern/

I avoided a final field because on the ORM frameworks such as Hibernate it uses reflections on the field; therefore, when you use this kind of tools usually don't use final fields, unfortunately.

Hey Robert, thank you for the comments.

Yes, you're right.

That still missing some points to make the model rich, that why I talked in conclusion about the next steps, otherwise, this post would be so huge.

Did you try the same test with the setter method? What was the result?

Hey, that is a Java EE project, so what we can do is run this command:

• mvn clean package tomee:exec -DskipTests

The source code: https://github.com/soujava/polyglot-persistence

Thank you, Denis.

Thank you, I'm delighted that you enjoyed it.