29 October 2026

MapStruct: An Overview

 (viejo confiable).

Introduction

MapStruct is a code generator that greatly simplifies the implementation of mappings between Java bean types, following a convention-over-configuration approach.

It uses annotations to generate mapping code at compile time, ensuring high performance and reducing boilerplate code.

There are several Java DTO mapping libraries, such as MapStruct, Dozer, and ModelMapper. MapStruct stands out by generating mapping implementations during compilation rather than relying on runtime reflection.

The core solution involves creating an interface annotated with @Mapper. During compilation, the MapStruct annotation processor generates the mapping implementation. With Maven, this can be done by running mvn clean install.

This approach reduces repetitive code and makes object mapping easier to maintain.

Basic Usage of MapStruct

To use MapStruct, you need to define a mapper interface and annotate it with @Mapper.

Here is a simple example:

@Mapper
public interface SimpleSourceDestinationMapper {

    SimpleSourceDestinationMapper INSTANCE =
        Mappers.getMapper(SimpleSourceDestinationMapper.class);

    SimpleDestination sourceToDestination(SimpleSource source);

    SimpleSource destinationToSource(SimpleDestination destination);
}

The interface defines two mapping methods: one converts a SimpleSource object into a SimpleDestination object, while the other performs the reverse mapping.

The Mappers.getMapper() method provides an instance of the generated implementation. MapStruct generates the implementation automatically during compilation.

Nested Object Mapping

MapStruct can also map objects containing nested objects. The @Mapping annotation allows you to specify the source and target properties explicitly.

Consider an employee entity containing an identifier, a name, and a division. The corresponding DTO may use different property names and contain a nested division DTO.

@Mapper
public interface EmployeeMapper {

    @Mapping(target = "employeeId", source = "entity.id")
    @Mapping(target = "employeeName", source = "entity.name")
    EmployeeDTO employeeToEmployeeDTO(Employee entity);

    @Mapping(target = "id", source = "dto.employeeId")
    @Mapping(target = "name", source = "dto.employeeName")
    Employee employeeDTOToEmployee(EmployeeDTO dto);

    DivisionDTO divisionToDivisionDTO(Division entity);

    Division divisionDTOToDivision(DivisionDTO dto);
}

In this example, the source and target property names are different. The @Mapping annotations explicitly define how these properties correspond to each other.

The mapper also declares methods for converting Division objects into DivisionDTO objects and vice versa.

MapStruct can reuse mapping methods to handle nested objects, allowing complex object structures to be mapped through a combination of simple mappings.

List POJO Mapping

Mapping collections sometimes requires additional logic, particularly when the destination contains a list of objects that must be constructed from a source object.

In the following example, a mapper uses an expression to call a custom default method that creates a list of inner objects.

@Mapper
public interface ListPojoMapper {

    @Mapping(
        target = "innerPojoList",
        expression = "java(mapInnerPojoList(firstPojo))"
    )
    SecondPojo mapFirstPojoToSecondPojo(FirstPojo firstPojo);

    default List<InnerPojo> mapInnerPojoList(FirstPojo firstPojo) {

        System.out.println(
            "mapInnerPojoList..... default interface method!"
        );

        List<InnerPojo> innerPojos =
            java.util.Arrays.asList(new InnerPojo());

        for (InnerPojo innerPojo : innerPojos) {
            innerPojo.setInnerString(
                firstPojo.getStringAttribute()
            );
        }

        List<InnerPojo> result =
            new ArrayList<InnerPojo>(innerPojos);

        return result;
    }
}

The mapInnerPojoList() method demonstrates how a custom mapping method can be implemented directly in a mapper interface using the default keyword.

The method creates an InnerPojo object, assigns a string attribute from the source object, and returns a list containing the resulting object.

The expression attribute in @Mapping allows MapStruct to invoke this custom method when generating the mapping implementation.

This technique is useful when a mapping cannot be expressed as a straightforward property-to-property assignment.

Composite Inner POJOs

MapStruct can handle complex mappings, including composite POJOs containing inner POJOs.

Consider an EmployeeDTO class with the following properties:

@Getter
@Setter
@ToString
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class EmployeeDTO {

    private int employeeId;
    private String employeeName;
    private DivisionDTO division;
}

The nested DivisionDTO class contains its own properties:

@Getter
@Setter
@ToString
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class DivisionDTO {

    private int id;
    private String name;
}

The mapper can define the conversion methods for both the employee and division objects:

@Mapper
public interface EmployeeMapper {

    @Mapping(target = "employeeId", source = "entity.id")
    @Mapping(target = "employeeName", source = "entity.name")
    EmployeeDTO employeeToEmployeeDTO(Employee entity);

    @Mapping(target = "id", source = "dto.employeeId")
    @Mapping(target = "name", source = "dto.employeeName")
    Employee employeeDTOToEmployee(EmployeeDTO dto);

    DivisionDTO divisionToDivisionDTO(Division entity);

    Division divisionDTOToDivision(DivisionDTO dto);
}

This example illustrates how MapStruct can map properties with different names and work with nested object structures.

By defining the appropriate mapping methods, developers can separate the mapping logic from the business logic and avoid manually copying properties between objects.

Generated Code

One of the main advantages of MapStruct is that it generates ordinary Java code during compilation.

For example, the generated implementation of SimpleSourceDestinationMapper can look like this:

import javax.annotation.processing.Generated;

@Generated(
    value = "org.mapstruct.ap.MappingProcessor",
    date = "2025-02-18T15:58:04-0300",
    comments = "version: 1.6.3, compiler: javac"
)
public class SimpleSourceDestinationMapperImpl
        implements SimpleSourceDestinationMapper {

    @Override
    public SimpleDestination sourceToDestination(
            SimpleSource source) {

        if (source == null) {
            return null;
        }

        SimpleDestination.SimpleDestinationBuilder
            simpleDestination = SimpleDestination.builder();

        simpleDestination.name(source.getName());
        simpleDestination.description(source.getDescription());

        return simpleDestination.build();
    }

    @Override
    public SimpleSource destinationToSource(
            SimpleDestination destination) {

        if (destination == null) {
            return null;
        }

        SimpleSource.SimpleSourceBuilder simpleSource =
            SimpleSource.builder();

        simpleSource.name(destination.getName());
        simpleSource.description(destination.getDescription());

        return simpleSource.build();
    }
}

The generated implementation checks for null values, creates the destination object using its builder, copies the properties, and returns the resulting instance.

Notice that the generated code contains direct method calls such as getName() and getDescription(). This is one of the reasons MapStruct can provide high-performance mappings without relying on runtime reflection for these operations.

The generated classes are produced by the annotation processor during compilation. Developers normally work with the mapper interface rather than manually maintaining the generated implementation.

Drawbacks and Limitations

MapStruct works well when mapping large numbers of objects with similar structures and many attributes. It can significantly reduce repetitive code when converting between entities, DTOs, and other Java bean types.

However, mapping becomes more complex when the source and destination objects have significantly different structures.

Nested classes and composite objects may require additional mapping methods or explicit configuration to determine how properties should be transferred between outer and inner objects.

Mapping can involve Java beans, primitive values, nested classes, and collections. Collections may require particular attention when the destination structure differs from the source structure or when each element needs custom transformation logic.

For these situations, custom methods and explicit @Mapping annotations can help make the intended conversion clear.

Conclusion

MapStruct is a useful tool for Java applications that need to convert objects between different representations. By generating mapping implementations at compile time, it reduces boilerplate code while maintaining readable and efficient Java implementations.

Its annotation-based approach supports straightforward property mapping, nested objects, collections, and custom conversion logic. For complex object structures, developers may need to define explicit mappings and custom methods.

Overall, MapStruct is a practical option for simplifying DTO mapping and keeping conversion logic separate from the rest of the application.

References

23 October 2026

22 October 2026

Cuantización / Quantization

La cuantización en inteligencia artificial es un proceso que reduce el número de bits utilizados para representar los pesos y activaciones de un modelo, pasando de formatos de alta precisión (como FP32 o FP16) a formatos de menor precisión (como INT8, INT4 o inferiores).

 

21 October 2026

Feature creep

Feature creep is the excessive ongoing expansion or addition of new features in a product,[1] especially in computer software, video games (where it should not be confused with power creep) and consumer and business electronics. These extra features go beyond the basic function of the product and can result in software bloat and over-complication, rather than simple design.

--wikipedia

 

14 October 2026

Orthogonal Array Testing

Un Orthogonal Array (OA) es una matriz experimental utilizada para estudiar como diferentes factores afectan un resultado, reduciendo la cantidad de experimentos necesarios.

El metodo Taguchi utiliza estas matrices para diseñar experimentos de manera eficiente, especialmente en ingenieria, optimizacion de procesos y control de calidad.

En Desarrollo de Software es una buena tecnica para ser usado en QA (Quality Assurance), 

---------------------------------------

Taguchi Orthogonal Array L4

Three factors with two levels require 8 experiments in a full factorial design, but only 4 with L4.

Experiment A: Threads B: Batch C: Pool
1101005
210100020
310010020
410010005

Key idea: Each pair of columns contains all four combinations of levels exactly once.

----------------------------------


Group Testing / Combinatorial Group Testing.

  • Orthogonal Array Testing (OAT) — usa matrices ortogonales para reducir sistematicamente las combinaciones.
  • Pairwise Testing — garantiza que cada par de valores de parametros aparezca al menos una vez.
  • Combinatorial Testing — nombre general para estas tecnicas.
  • Covering Array Testing — busca un conjunto reducido de casos que cubra todas las combinaciones de t parametros.
  • Equivalence Partitioning — divide entradas en clases y prueba representantes, aunque es otra tecnica.
  • Boundary Value Analysis — prueba valores en los limites.
  • Combinatorial Interaction Testing (CIT) — enfocado en detectar fallos producidos por interacciones entre parametros.
  • Design of Experiments (DOE) — viene de estadistica/experimentacion y tambien busca obtener mucha informacion con menos experimentos.


*AI-assisted content

09 October 2026

Jax London 26

 


Wed 07.10.2026

  1. Welcome and Opening Keynote of JAX London 2026
    Sebastian Meyen

  2. Worth a Million Arguments
    Venkat Subramaniam (prototype!)

  3. Low Latency Machine - Can Generative AI Write High-Performance Code?
    Mark Price

  4. Four Green Ticks – Yet Still Hacked: Threat Modelling for AI Agents
    Christian Schneider

  5. Security in the Age of AI – Ask the Expert
    Charles Weir

  6. Small Signals, Big Incidents: Catching Production Problems in the Performance Lab with JFR & AI
    Ram Lakshmanan

  7. Building Agentic AI with Small Language Models — Locally and Efficiently
    John Davies| Incept5

  8. Build Your Own Private AI Cluster for the Office
    John Davies| Incept5



Thr 08.10.2026

  1. AI and the Future of Enterprise Software
    Rod Johnson| Embabel

  2. Create Your Own Role-Playing Game with Agentic AI Using Spring AI
    Arnaud Jean| AWS

  3. Architecture Observability in Agentic Engineering
    Victor Rentea| Independent Trainer

  4. AI Literacy for Developers: Thinking Clearly While AI Writes the Code
    Russell Miles| TechTalk

  5. Trade-Offs Are Everything: Non-functional Requirements For the AI Era
    Eoin Woods| Artechra

  6. A2UI & MCP-UI: Agent-Driven Interfaces
    Diego Ligtenberg| Rabobank

  7. Patterns and Anti-patterns of Agentic Engineering
    Victor Rentea| Independent Trainer



Fr 09.10.2026

  1. Agentic Engineering Workshop: Building Secure, Autonomous AI Agents and Multi-Agent Systems in Production
    Victor Rentea| Independent Trainer


https://www.youtube.com/@JAXLondonCon

 

01 October 2026

Gauss Billete

Billete antiguo de marcos alemanes del principe de las matematicas Carl Friedrich Gauss.






 

29 September 2026

Alan Turing Billete

Un homenaje del Banco de Inglaterra al poner a Alan Mathison Turing en el billete de 50 libras esterlinas.

 

25 September 2026

Outbox Pattern

TL;DR

Primero insertar dato en base datos y desde ahi (message relay) publicarlo en cola.

The Transactional Outbox Pattern is a crucial architectural design pattern used in microservices to ensure reliable message publishing to Apache Kafka. It solves the dual-write problem, which occurs when a service tries to update its local database and send an event to Kafka at the same time.

Because databases and Kafka cannot share a single distributed transaction, a network failure or application crash right after the database commit means the Kafka event is lost forever. The outbox pattern completely eliminates this risk by leveraging the atomicity of local database transactions.

 



https://developer.confluent.io/courses/microservices/the-transactional-outbox-pattern/

https://www.decodable.co/blog/revisiting-the-outbox-pattern

https://microservices.io/patterns/data/transactional-outbox.html


23 September 2026

Ley de Brooks

La Ley de Brooks afirma que añadir más personal a un proyecto de software retrasado hace que se retrase todavía más. 

Este principio fue acuñado por Fred Brooks en su libro clásico de 1975, The Mythical Man-Month (El hombre-mes mítico), basándose en su experiencia al dirigir el desarrollo del sistema operativo OS/360 en IBM. Como resumen de su idea, Brooks popularizó la frase: "Nueve mujeres no pueden tener un bebé en un mes".

Este es uno de las leyes mas basicas que ocurre en desarrollo de software donde la gente no involucrada en la fabrica tienden a confundirse.

Ahora surge el fenomeno de la IA... habria que ver con este nuevo approach.



12 September 2026

Historia de las APIs

Siempre existen conversaciones de APIs, desde el boom de los microservicios se le dice coloquialmente APIs donde se refiere por default a API Rest o Web API, sin duda, los mas senior solo piensan en la API de C, C++, Java, etc.

Dicho esto es simpatico cuando aparece por primera vez ese termino.

Todo apunta que fue en:

Finally, hardware independence at the central computer means that a consistent application program interface could be maintained if that computer were replaced...


Ademas, los siguientes libros y presentacion hablan mas de la historia de las APIs:

TL;DR

Sigue usando API para cosas modernas estilo API Rest, y ponle el adjetivo si quieres hablar mas claro de otro tipo de APIs, como:

EDSAC subroutine library, FORTRAN libraries, IBM System/360 interfaces, Application Program Interface (1968), Unix system calls, C Standard Library, POSIX API, MS-DOS API, Macintosh Toolbox, Windows API, Xlib, RPC, OpenGL, CORBA, Java API, SOAP Web Services, .NET API, REST APIs, GraphQL, gRPC.
 






10 September 2026

Algorithm Recreational Programming

Newsletter de inicio de los 90s que es como la continuacion del articulo de Scientific American que desde matematicas recreativas paso a programacion recreativa.






06 September 2026

Amdahl’s Law

Amdahl’s Law can be expressed mathematically as follows:

$$ \mathrm{Speedup}_{\max} = \frac{1}{(1-p) + \frac{p}{s}} $$
  • SpeedupMAX = maximum performance gain
  • s = performance gain factor of p after implementing the enhancements.
  • p = the part whose performance needs to be improved.

Let’s take an example. If the part that can be improved is 30% of the overall system and its performance can be doubled, then:

$$ \displaystyle \mathrm{Speedup}_{\max} = \frac{1}{(1-0.30)+\frac{0.30}{2}} = 1.18 $$

Oregon State University — Amdahl’s Law

If you buy a system with n cores, you should get n times Speedup (and 100% Speedup Efficiency), right? Wrong! There is always some fraction of the total operation that is inherently sequential and cannot be parallelized no matter what you do. This includes reading data, setting up calculations, control logic, storing results, etc.

Tutorialspoint — What is Amdahl’s Law?

Wikipedia — Amdahl’s Law

La Ley de Amdahl dice que el rendimiento total está limitado por la parte del sistema que no podemos acelerar.

29 August 2026

¿ Aymara o Aimara ?

Aimara es aymara en aymara :)


¿Cómo se dice aimara en aimara?

- Aymara.

- Perfecto… ¿y cómo se dice aymara en español?

- Aimara.

- 💀  x_x



En castellano, ambas formas son correctas: aimara y aymara.

aimara → forma adaptada al español, recomendada por la RAE.

aymara → forma muy extendida, especialmente en contextos culturales, académicos y en el propio idioma.


26 August 2026

C - Project status and milestones

As everyone knows, this is the list of the state of the art in C:

https://open-std.org/jtc1/sc22/wg14/www/projects.html

ISO/IEC 9899 - Revision of the C standard

The primary output of WG14 is ISO/IEC 9899, the C Standard. The following is a list of revisions to ISO/IEC 9899 that the committee has produced:

RevisionPublicationSimilar draft
C2yNot availableN3685 [2025-09-28]
C23ISO/IEC 9899:2024N3220 [2024-02-22] (early C2y draft)
C17ISO/IEC 9899:2018N2310 [2018-11-11] (early C23 draft)
C11ISO/IEC 9899:2011N1570 [2011-04-04]
C99ISO/IEC 9899:1999N1256 [2007-09-07]
C95ISO/IEC 9899:1990/Amd 1:1995Not available
C90ISO/IEC 9899:1990Not available
C89ANSI X3.159-1989NIST publication

-----------------------------------------------------------------------------------------------------------

.It looks like a RPG D&D quest:

— N3340: Slay Some Earthly Demons II
— N3341: Slay Some Earthly Demons III
...
— N3558: Chasing Ghosts I: Constant Expressions and Objects of Known Constant Size

-----------------------------------------------------------------------------------------------------------


 

16 August 2026

Fischer vs Spassky

Game of Fischer Spassky

Robert James Fischer – Boris Spassky
Match por el Campeonato Mundial, partida 6
Reikiavik, 23-07-1972
Resultado: 1–0

Es la famosa partida en la que Fischer sorprendió con 1.c4, entrando posteriormente en el Gambito de Dama, y que Spassky llegó a aplaudir al finalizar. 

Partida 6 del match, ChessBase. 

Este tablero lo puedes ver en: https://devwebcl.blogspot.com/2024/04/beginning-c-7th-edition.html

12 August 2026

Consuetudinaria

Del lat. consuetudinarius.
  1. adj. Que es de costumbre.
  2. adj. Habitual o reincidente.

 

08 August 2026

Nefelibata

Nefelibata es un adjetivo que describe a una persona soñadora que camina o vive en las nubes, alejada de la realidad cotidiana.

 

29 July 2026

PBFT, IBFT and QBFT Consensus Algorithms

The diagrams illustrate PBFT-family consensus algorithms (PBFT, IBFT, and QBFT), which are Byzantine Fault Tolerant protocols used in permissioned blockchains such as Hyperledger Besu.


1. PBFT (Practical Byzantine Fault Tolerance)

Purpose

  • Allows distributed nodes to agree on a block even if some validators are malicious or faulty.
  • Tolerates up to f Byzantine nodes among 3f + 1 validators.

Consensus Phases

1. Request

  • A client sends a transaction to the leader (primary).

2. Pre-Prepare

  • The leader proposes a new block.
  • All validators receive the proposal.

3. Prepare

  • Validators verify the proposed block.
  • If valid, they broadcast a Prepare message.
  • When a validator receives at least 2f + 1 Prepare messages, the block is considered prepared.

4. Commit

  • Validators broadcast Commit messages.
  • After receiving 2f + 1 Commit messages, the block is finalized.

5. Reply

  • Validators execute the transactions.
  • The client receives confirmation.

Characteristics

  • Three communication rounds.
  • Immediate finality (no forks).
  • High message complexity (O(n²)).
  • Excellent for permissioned networks.

2. IBFT (Istanbul Byzantine Fault Tolerance)

IBFT is an adaptation of PBFT designed specifically for Ethereum-compatible blockchains.

Consensus Flow

Leader Selection

  • One validator becomes the proposer for the current round.

Proposal

  • The proposer creates a candidate block.

Validation

Validators verify:

  • Block format
  • Signatures
  • Transactions
  • Gas limits
  • Previous block hash

Prepare

  • Validators multicast a Prepare message.

Commit

  • After receiving 2f + 1 Prepare messages, validators send Commit.

Finalization

  • Once 2f + 1 Commit messages are collected, the block is appended to the chain.

Additional Features

  • Round-change protocol.
  • Automatic leader replacement after timeouts.
  • Better suited for blockchain environments than classical PBFT.
  • Used in early versions of Hyperledger Besu and Quorum.

3. QBFT (Quorum Byzantine Fault Tolerance)

QBFT is the successor to IBFT and is currently the recommended consensus algorithm for Hyperledger Besu.

It keeps the PBFT consensus model while simplifying validator management and improving robustness.

Consensus Phases

1. Proposal

  • The proposer creates a block.

2. Prepare

  • Validators verify the proposal.
  • Valid validators broadcast a Prepare message.

3. Commit

  • After receiving 2f + 1 Prepare messages, validators broadcast Commit.

4. Finalization

  • After 2f + 1 Commit messages, the block becomes final.

Improvements over IBFT

  • More robust round-change mechanism.
  • Better handling of validator changes.
  • Simpler protocol specification.
  • Improved interoperability with Enterprise Ethereum implementations.
  • Lower operational complexity.

Comparison

Feature PBFT IBFT QBFT
Byzantine Fault Tolerant ✅ ✅ ✅
Leader-based ✅ ✅ ✅
Consensus Phases Pre-Prepare → Prepare → Commit Proposal → Prepare → Commit Proposal → Prepare → Commit
Immediate Finality ✅ ✅ ✅
Forks No No No
Round Change Basic Improved More Robust
Ethereum Compatible No Yes Yes
Hyperledger Besu No Legacy Recommended

Fault Tolerance

For all three protocols:

  • Number of validators = 3f + 1
  • Maximum Byzantine failures = f
  • Quorum = 2f + 1

Examples

Validators Byzantine Faults Tolerated Quorum
4 1 3
7 2 5
10 3 7
13 4 9

Why QBFT is Preferred Today

For modern permissioned Ethereum networks (such as Hyperledger Besu), QBFT is generally preferred because it:

  • Provides deterministic finality.
  • Tolerates Byzantine failures.
  • Includes a more reliable round-change mechanism.
  • Simplifies validator management.
  • Offers improved stability over IBFT while maintaining the same consensus guarantees.

This is why QBFT has become the default recommendation for new Hyperledger Besu deployments.




* AI English text generated
 * AI-assisted content

14 July 2026

Mastering Ethereum: 2nd Edition

Mastering Ethereum, 2nd ed.

New edition of this classic book that has license:

https://github.com/ethereumbook/ethereumbook

This is the second edition of the book "Mastering Ethereum". You can access the book in the following ways:




License

This work is licensed under Creative Commons. For the first 12 months after publication, it is available under the CC BY-NC-ND 4.0 license (Attribution-NonCommercial-NoDerivatives). After that period, it becomes available under the CC BY-SA 4.0 license (Attribution-ShareAlike).

 



10 July 2026

Pro Git, 2nd ed.

This classic Git SCM book is open and released under a Creative Commons license.

It is essential reading for anyone who wants to gain a solid understanding of Git.

Anyone can also submit a pull request to fix issues or improve the content. I found only one issue several years ago and was able to submit a fix.


https://git-scm.com/book/en/v2

 

10 June 2026

Redis Lua Script

En Redis existe ZSET y script Lua para ejecucion de metodos/transacciones atomica.

1. un ZSET es más parecido a:

    Map<String, Long> + TreeMap<Long, Set<String>>

2. El script se ejecuta con Redis:

docker run -d \
  --name redis-poc \
  -p 6379:6379 \
  redis:7

3. El output esperado:

=== INITIAL BALANCES ===
ACCOUNT_A = 1000
ACCOUNT_B = 500

=== LUA RESULT ===
SUCCESS
1000
900
500
600

=== FINAL BALANCES ===
ACCOUNT_A = 900
ACCOUNT_B = 600

=== MODIFIED ACCOUNTS ===
ACCOUNT_A
ACCOUNT_B

 

 4. Codigo fuente:

09 June 2026

29 May 2026

English n00b

The principal parts of the human body are the head, the trunk, and the limbs.

 

26 May 2026

Scriptorium

A scriptorium (/skrɪpˈtɔːriəm/ ⓘ)[1] was a writing room in medieval European monasteries for the copying and illuminating of manuscripts by scribes.

El término scriptorium,[a] literalmente «un lugar para escribir», 


 





Blog Archive

Disclaimer

Qux