Software Craftsmanship

Pull Request Review Resolution with Claude Code

Wed, 25 Mar 2026 00:00:00 +0000

Are you tired of Copilot comments on your PR? Then let AI deal with it. In the following article, find a useful command for Claude Code.

Prerequisites

Claude Code
gh cli
- brew install gh
- gh auth login

Create Claude Code command

Create file ~/.claude/commands/resolve-pr-comments.md with content:

Fetch all open/unresolved review comments on a PR and help me resolve them.

## Step 1: Determine the PR
If a PR number is provided as $ARGUMENTS, use that.
Otherwise, run this command first and capture the output:

``bash
gh pr view --json number -q .number
``

Store the result as the PR number. If the command fails or returns empty, tell me there's no open PR on this branch and stop.

## Step 2: Get Repo Info
Run this command and store the owner and repo name:

``bash
gh repo view --json owner,name -q '.owner.login + "/" + .name'
``

This gives you OWNER/REPO. Use these values in all subsequent commands.

## Step 3: Fetch Unresolved Comments
Use the PR number and OWNER/REPO from previous steps. Replace OWNER, REPO, and PR_NUMBER with the actual values — do NOT use $() substitution.

First, get unresolved review threads via GraphQL:

``
gh api graphql -f query='query { repository(owner:"OWNER", name:"REPO") { pullRequest(number:PR_NUMBER) { reviewThreads(first:100) { nodes { isResolved, comments(first:10) { nodes { id, body, author { login }, path, line } } } } } } }'
``

Only include threads where `isResolved` is `false`. Skip any already-resolved threads entirely.

**Important**: Filter out noise before analysis. Ignore any comments from bots like SonarQube/SonarCloud (user login containing "sonar") that indicate passing quality gates, no issues found, or "Passed" status. Only keep Sonar comments that flag actual issues, bugs, or code smells. Also ignore other CI bot comments that are purely status updates (e.g. coverage reports that just show numbers with no actionable feedback).

## Step 4: Critical Analysis
For each comment, provide a structured analysis:

- **Comment**: The reviewer's feedback
- **File & Line**: Where it applies
- **Assessment**: Do you agree this is a valid concern? Be honest — if the comment is nitpicky, subjective, or wrong, say so with reasoning.
- **Recommendation**: One of:
  - **AGREE & FIX** — Valid point, here's the proposed change
  - **DISCUSS** — Has merit but needs discussion, here's a suggested reply
  - **PUSH BACK** — Disagree, here's why and a suggested reply
- **Proposed Change** (if fixing): Show the exact code diff

## Step 5: Present the Plan
Present ALL comments with your analysis in a single summary table, then wait for my approval before making any changes.

## Step 6: Execute (only after approval)
Once I confirm which comments to resolve:
1. Make the code changes for approved fixes
2. For DISCUSS/PUSH BACK items, draft reply comments
3. Stage and show me the final diff before committing

Permissions

This is optional, without it you’ll need to approve multiple commands.

Add to ~/.claude/settings.json the following:

{
  "permissions": {
    "allow": [
      "Bash(gh pr:*)",
      "Bash(gh api:*)",
      "Bash(gh repo:*)"
    ]
  }
}

Note, maybe it’s worth fine tunning the permissions, instead of using the wildcard.

Usage

claude /resolve-pr-comments

Decouple Maven Releases from Version Logic

Fri, 02 Jan 2026 00:00:00 +0000

In standard Maven projects, versions are hardcoded in the POM, requiring a manual update after every release. This workflow is prone to several issues that often complicate CI/CD pipelines. I will explain why this approach is problematic and show a better way to handle releases by decoupling the version and Git operations from Maven.

Let’s first revise what Maven offers out of the box, namely the maven-release-plugin workflow:

Change version from 0.1.0-SNAPSHOT to 0.1.0.
Commit the change and create a Git release tag.
Build and push the tagged version to the repository.
Bump the version to 0.1.1-SNAPSHOT and commit again.

Issues with Maintaining Hardcoded Versions in POM

Noise in Git History

Tags are required as they mark a point in Git history where we can reliably track releases. Version change commits, on the other hand, are not used in any context and add noise.

Merge Conflicts

Regardless of the branching strategy, we will eventually need to merge branches, like bringing a hotfix into the main branch. Because both branches have different hardcoded versions, an immediate merge conflict is triggered.

There are some options to work around this like cherry-picking and merge strategies among others, but that adds significant complexity to the CI/CD automation.

Security Issues

As per best practices, the main branches should be protected, preventing direct pushes, deletions, commits without a pull request etc. In mature projects, CI/CD automation typically handles releases, creating a problem: we must either manually approve every version-change PR or whitelist a bot/user to bypass branch protection rules. Both are poor options: the first defeats the purpose of automation, while the second has security risks like self-escalation via workflow edits. Here is an intersting discussion around the later one.

The Solution: Decouple Versioning and Git Operations from Maven

Seeing the initial workflow, it is clear that Maven has two distinct roles: release orchestration and artifact deployment. To solve this, we need to separate the responsibilities between two actors:

CI/CD: Acting as the orchestrator of the release process.
Maven: Building and publishing the artifact.

While the following example focuses on a multi-module project, these steps are equally valid for standard projects. You can view the full implementation in this PR, but let’s break down each step:

1. Remove hardcoded version

Update the POMs to use ${revision} instead of hardcoded versions. This should be done for the parent as well as children POMs.

Instead of:

<groupId>md.adrian</groupId>
<artifactId>crop-parent</artifactId>
<version>0.1.3</version>

we use:

<groupId>md.adrian</groupId>
<artifactId>crop-parent</artifactId>
<version>${revision}</version>

2. Define a Default Version in the Parent POM

Defining a default version is necessary for local builds and IDEs to avoid errors. It can be overridden via the command line argument -Drevision=0.1.5-SNAPSHOT.

<properties>
    <revision>0.1.4-SNAPSHOT</revision>
</properties>

3. Add the Flatten Maven Plugin

This should be done for two reasons: to resolve ${revision} and to remove everything that is not needed for the consumers of the artifact. The plugin actually creates other POMs. It is important to note that there are a couple of flatten modes:

resolveCiFriendliesOnly: Useful for CI/CD pipelines, like running tests. It will only resolve ${revision} in our case, but the rest will remain as is.
ossrh: Useful for flattening when publishing to Maven Central. It removes everything that the consumer of the artifact does not actually use (parent references, build plugins, profiles, etc.) and creates a clean, minimal POM.

The published POM will look like this:

<groupId>md.adrian</groupId>
<artifactId>crop</artifactId>
<version>1.0.0</version>  <dependencies>
    <dependency>
        <groupId>jakarta.persistence</groupId>
        <artifactId>jakarta.persistence-api</artifactId>
        <version>3.1.0</version>
    </dependency>
</dependencies>

4. Update .gitignore

Add .flattened-pom.xml to our .gitignore, so that we don’t accidentally commit automatically generated flattened POMs.

5. Update the CI/CD Pipeline

Amend the Maven deploy command to pass the revision version.

mvn deploy -Drevision=$

In this example, the version is pulled directly from the GitHub Release action, which says both what version is used and when the release occurs. Once these responsibilities are separated, it is easy to extend the logic, for instance, by implementing automatic version calculation similar to jgitver. But be carefull: in CI/CD pipeline, not in Maven.

CrOp 0.1.3: Adding Result Counts and a Look at API Trade-offs

Mon, 22 Dec 2025 00:00:00 +0000

I’m happy to share that I’ve added a new feature to CrOp and also moved it to a new namespace.

In my previous articles, I explained what problem it solves in a typical REST service. At the time, I was still missing a way to count the total result. This is a must-have in a paginated query. @Query from Spring Data JPA, for example, has a separate attribute for that - countQuery.

Seems trivial now, as any problem in retrospect, but at the time I was getting SqmRoot not yet resolved to TableGroup error. And that was because I was using the wrong root to apply predicates for count. Storing predicates as a function that accepts another root allowed me to reapply them for count.

Below is an example of count. Note that it is the same query as for select, but a different execution method at the end:

@GetMapping("/pets/count")
Long count(PetCriteriaOperator searchCriteria) {
    return cropService.create(Pet.class, searchCriteria)
            .match(Pet_.id, PetCriteriaOperator::getId)
            .match(Pet_.name, PetCriteriaOperator::getNickname)
            .match(Pet_.birthdate, PetCriteriaOperator::getBirthdate)
            .match(Pet_.price, PetCriteriaOperator::getPrice)
            .join(Pet_.features)
                .match(PetFeature_.feature, PetCriteriaOperator::getFeatures)
            .endJoin()
            .match(Pet_.active, PetCriteriaOperator::getActive)
            .join(Pet_.petType)
                .match(PetType_.code, PetCriteriaOperator::getType)
                .join(PetType_.petCategory)
                    .match(PetCategory_.code, PetCriteriaOperator::getCategory)
                .endJoin()
            .endJoin()
            .getCount();
}

About the namespace, I did it for simple economic reasons - did not want to renew the old domain com.apulbere, so I published instead under md.adrian. The library can now be found at the coordinates:

<dependency>
    <groupId>md.adrian</groupId>
    <artifactId>crop</artifactId>
    <version>0.1.3</version>
</dependency>

This project was more than just trying to solve a problem. It made me think very carefully about the design choices of an API, just a few of them:

Was it a correct choice to use the Metamodel API?

Example Pet_.name in .match(Pet_.name, PetCriteriaOperator::getNickname). Perhaps using strings and forcing the JPA provider to perform the Metamodel lookup at runtime could offer more flexibility, but less type safety. At the same time, in the examples I provided, I used a statically generated metamodel, but not everyone is a fan such tools. It’s always about compromises.

How should I test it?

While I am currently using a demo project for integration testing, the long-term goal is to move tests closer to the source code. That means bringing a specific JPA provider and testing through it.

Does the API have enough flexibility for further enhancements and extensibility?

Let’s say I need to add customizable validation for input parameters without breaking the existing contract. Here, I should carefully consider what the core idea and domain of the library are, and whatever needs to be added is a part of it.

And perhaps the most challenging one: Does the API offer too much?

Currently, once you define a filter, you automatically get every operator for that data type. For example, a string filter exposes like alongside the basics eq, neq, and in. This can be a problem if your database isn’t optimized for full-text search. I mention this because using a tool in the wrong context doesn’t make the tool itself flawed - it just means it’s being pushed beyond its intended limits.

The primary goal was to power a front-end data grid, and the library handles that job perfectly. Of course, every design comes with trade-offs, and I’ve tried to be as transparent as possible about those here.

Premature ORM-ification

Wed, 23 Jul 2025 00:00:00 +0000

ORMs promise to simplify persistence, but in practice, they introduce recurring problems.

In many cases, there’s no clear or well-documented justification for why an ORM was introduced in the first place. Most probably it’s adopted by default, based on assumptions such as the belief that you can switch the database vendor without changing any code or that an ORM somehow “bridges” object-oriented programming and relational databases.

While intended to ease data access, ORMs often end up dictating the entire application design. Instead of designing models around business logic, we adapt them to fit ORM limitations, flattening structures, adding unnecessary relationships, or compromising encapsulation just to bypass ORM constraints. The result is a codebase where the data model drives the design and the actual logic comes second.

Since ORMs typically map entire database tables to entities, these entities tend to get passed throughout the application. The issue? You rarely need all the fields, let alone the related entities that are pulled in by default. Projections or custom queries can help, but despite code reviews, overfetching still frequently slips through.

We strive for loose coupling between components for good reason. But under the hood, many ORMs create tightly coupled entity graphs through bidirectional or deeply nested relationships. The model becomes tangled, what seems like a minor change in one part can trigger unpredictable behavior elsewhere. One use case might require a lazy one-to-one mapping, while another needs it eager, both relying on the same entity. The result: conflict and performance degradation.

When debugging performance issues, you’re forced to work at two layers: the ORM abstraction (JPQL, HQL, etc.) and the raw SQL it generates. This doubles the effort and mental overhead.

ORMs claim to offer vendor-agnosticism, but that illusion breaks down the moment you need a database-specific feature or optimization. Suddenly, you’re writing native queries or injecting dialect-specific logic, completely undermining the abstraction. Worse, when these two layers collide, you end up manually triggering flushes, refreshes, or other operations to keep them in sync.

Some argue that these issues arise from developers not fully understanding the tool, and sure, there’s truth in that. But ORMs were supposed to simplify development, not require mastery of every quirk just to execute a query properly.

Java Database Search Made Easy

Sun, 14 Jul 2024 00:00:00 +0000

Search functionality is so ubiquitous in any web app that at some point you start asking yourself if it can be done any easier. Introducing CrOp, a lightweight, zero dependency, and type-safe wrapper around Java Persistence Criteria API, which simplifies building queries, particularly useful within REST SQL (RSQL) context.

Let’s dive into it’s core principles.

Zero Dependency

We all know the pain of upgrading dependencies. What I find the most troublesome is going through compatibility matrices (if you are lucky enough to find them). For example, you can’t use Spring 3 with Hibernate 5. And if you built something with Hibernate 5, you’ll have to rewrite it before upgrading Spring.

That’s why CrOp relies on the JPA specification and is agnostic to the underlying implementation, whether it’s Hibernate, EclipseLink, Apache OpenJPA, or any other.

Type Safe

CrOp guarantees compile type-safety without relying on reflection. It has specialized wrapper classes for most common data types and allows mapping only JPA’s Metamodel. Meaning for example that you cannot use a String to query a Long entity field. Your code won’t simply compile if your try to do such thing.

Optimized

Database optimization can refer to a lot of things, but what CrOp can do (for now) is to promise that it won’t add unnecessary joins. For example, you have two entities Pet and PetType with a one-to-one relationship between them, and sometimes you wish to include pet type in search. Guess what, only when the lookup parameter is present the join with PetType will happen.

@GetMapping("/pets")
List<PetRecord> findAll(PetCriteriaOperator searchCriteria, CriteriaOperatorOrder order, CriteriaOperatorPage page) {
    return cropService.create(Pet.class, searchCriteria, order, page)
        .match(Pet_.name, PetCriteriaOperator::getNickname)
        .join(Pet_.petType)
            .match(PetType_.code, PetCriteriaOperator::getType)
        .endJoin()
        .getResultList()
        .stream()
        .map(petMapper::map)
        .toList();
}

Example

A GET request like http://localhost:64503/pets?birthdate.gte=2010-01-11&nickname.like=Ba, is transformed by CrOp (via an ORM) into the following SQL:

select
    p1_0.id,
    p1_0.birthdate,
    p1_0.name,
    p1_0.pet_type_id 
from
    pet p1_0 
where
    p1_0.name like ? escape '' 
    and p1_0.birthdate>=?

There are a couple of easy steps to achieve the above:

Add the dependency

<dependency>
    <groupId>md.adrian</groupId>
    <artifactId>crop</artifactId>
    <version>0.1.3</version>
</dependency>

Define a DTO that contains all fields necessary for filtering. For example, if you want to do filtering on String type then you choose StringCriteriaOperator from md.adrian.crop.operator package.

@Getter
@Setter
public class PetSearchCriteria {
    private StringCriteriaOperator nickname;
    private LocalDateCriteriaOperator birthdate;
}

Create an instance of the service that will parse the query. It requires EntityManager in the constructor.

@Bean
CriteriaOperatorService cropService(EntityManager entityManager) {
  return new CriteriaOperatorService(entityManager);
}

Finally, invoke the service’s create method with the root entity and filter object. The result is a builder that lets you match the entity’s meta-model with each field from the DTO. When done, execute the query.

@GetMapping("/pets")
List<PetRecord> search(PetSearchCriteria petSearchCriteria) {
  return cropService.create(Pet.class, petSearchCriteria)
          .match(Pet_.name, PetSearchCriteria::getNickname)
          .match(Pet_.birthdate, PetSearchCriteria::getBirthdate)
          .getResultList()
          .stream()
          .map(petMapper::map)
          .toList();
}

For full example and to see all the capabilities of the library checkout pet-shop demo repository.

A Feature Toggle Story

Tue, 22 Aug 2023 00:00:00 +0000

Feature toggle is a technique that helps to change the system’s behavior without altering the code. It’s interesting how stories around it vary from the catastrophic failure of the Knight Capital Group^[1] to the stellar success of the first GPS satellite^[2]. In the following article, we’ll see a more typical example that all engineers have to deal with.

Delivering a new feature according to Murphy’s Law

Imagine an existing flow in a system that generates a PDF report, and then uploads it to the cloud:

@AllArgsConstructor
@Service
class ReportService {
    PDFGenerator generator;
    StorageService storageService;

    void generateReport(Payload payload) {
        OutputStream reportStream = generator.generate(payload);
        storageService.upload(reportStream);
    }
}

Now the client wants to add a layer of authentication and sign the PDF before uploading. So let’s define an interface just for that:

interface SignerService {
    OutputStream sign(OutputStream payloadToSign);
}

And integrate it into the main flow:

@AllArgsConstructor
@Service
class ReportService {
    PDFGenerator generator;
    SignerService signerService;
    StorageService storageService;

    void generateReport(Payload payload) {
        OutputStream reportStream = generator.generate(payload);
        OutputStream signedReportStream = signerService.sign(reportStream);
        storageService.upload(signedReportStream);
    }
}

Everything seems perfectly fine until uncertainties start to creep in. Let’s say we already merged into the main branch the change and even did a demo to the client using a self-signed certificate on the local environment. But shortly before deploying the new version of the system on upper environments, the DevOps informs us that they have problems installing a valid certificate.

What do we do now? The main flow will certainly be broken. Not only the client won’t be able to receive his signed PDF, but he won’t receive a PDF at all. So, nothing left but to frantically revert the change, fix some conflicts on the way, run the regression, and finally prepare a new version.

Now let’s imagine another scenario where right from the beginning we took into consideration Murphy’s law. In this scenario, even after we implemented the feature, the main flow should work as before and only when we wish so, to pass through the signing step.

@Service
class NoOpSignerService implements SignerService {

    @Override
    public OutputService sign(OutputService payloadToSign) {
        log.info("bypassing signing step");
        return payloadToSign;
    }
}

Above, is a noop implementation for the code to work as before. And below is another implementation that does the signing.

@Service
@Primary
@ConditionalOnProperty(name = "activateSigning", havingValue = "true")
class BCSignerService implements SignerService {

    @Override
    public OutputService sign(OutputService payloadToSign) {
        //... sign and return the payload
    }
}

Notice that this implementation is the primary one but Spring picks it up and injects it into the main flow only when activateSigning is true.

Static vs dynamic feature toggles

Perhaps one of the objections to the above solution would be the fact that we have to change an environment variable (activateSigning) and do a restart. True, but this doesn’t necessarily mean that your service will be offline since you can have multiple instances and gradually replace them.

This approach is a static one, meaning that your application will work only with one state of the feature toggle, flipping it will not change the running system. There are certain use cases and reasons to choose the static feature toggle:

It’s one time only - you won’t need to go back and forth between states of the flag unless you have to “rollback” and revise it.
The code is clean, testable, and modular. Notice that the feature lives in a separate class, apart from the rest of the code. The old unchanged tests still work, we just have to add a couple of test cases for the activated feature.

The dynamic feature toggles are more fit for scenarios where they are dependent on user requests or the stakeholders want to control them via some management tool.

All things said, I think the feature toggle should be always considered during the design phase even if the client didn’t specifically request it and even if we don’t have a feature toggle discipline. We can always start small, with configuration properties as shown in this article.

^[1]How to lose half a billion dollars with bad feature flags

^[2]The Relativity Switch

^[3]Murphy’s law

Unit Testing Anti-Patterns

Fri, 11 Aug 2023 00:00:00 +0000

Writing unit tests might be challenging, especially when dealing with an ongoing project with already established hard-to-break anti-patterns.

I will go through some of the most common pitfalls I’ve encountered quite often.

Verifying the stubs

Let’s suppose we write the following piece of code:

@AllArgsConstructor
public class UserCreationService {
    private final UserFactory factory;
    private final UserRepository repository;
    private final NotificationService notificationService;

    public void create(UserCreateRequest request) {
        var user = factory.createEntity(request);
        user = repository.save(user);
        notificationService.notify(USER_CREATED, user.getId());
    }
}

And then create a test for the happy path:

@Test
void userCreatedSuccessfully() {
    var request = new UserCreateRequest();
    var userEntity = new UserEntity(randomUUID());
    when(factory.createEntity(request)).thenReturn(userEntity);
    when(repository.save(userEntity)).then(returnsFirstArg());

    userCreationService.create(request);

    verify(repository).save(userEntity);
    verify(notificationService).notify(USER_CREATED, userEntity.getId());
}

The first verify is redundant. Some engineers keep verifying every single stub resulting in noise and duplicated code. Every time you modify the stub you also have to do the same for verify step. More than that, if the stub is broken, then verify will not be executed, and if the stub passes then verify will always pass. The issue is worse if the test has an @AfterEach with verifyNoMoreInteractions and strictness = Strictness.WARN. It forces you to write verify even if you don’t want to.

Verifying the stubs should be rather an exception than a regular thing.

Test data constants

When setting up the test module for a project, often the second thing to do after adding the testing framework is to create a common test data class. In no time this class is filled up with lots of constants shared across dozen of tests.

Let’s start enumerating the problems:

Constants are misused. A constant like public static final String ID = "550e8400..." is set as user id, market id, and so on. There is no relation whatever between all these entities, it’s misused most probably because fits the data type and was automatically imported by IDE. What if the market id should be UUID while the user id is the username?
Mutable objects are declared as constants. This is the best recipe for “Why do the tests fail on Jenkins?”.

The alternatives to test data constants are factories and abstract factories. If you need a user id then declare a method in UserFactory that creates that id. This way it’s easy to change the value, make it a constant or randomly generated.

Tests know too much

Using reflection to set fields, invoke a method, a constructor, change access modifier, etc. - all this done for testing purposes is always a sure sign of poorly written tests. The worst part is if you go and alter the source code for the sake of a test. Doing any of the above tricks is a sign that the code requires refactoring.

In conclusion, testing should show how good the code you wrote is. And one thing that many forget is that tests should adhere to the same programming principle as the base code.

REST Search API with QueryDSL

Sat, 07 Jan 2023 00:00:00 +0000

One of the most common features in a typical web application is the search functionality. The tricky thing is that we have to provide it via REST API and make it quite dynamic in terms of supported operators and filtrable fields. In the following paragraphs, we’ll go through what QueryDSL offers and how a lightweight extension could help.

Out of the box, QueryDSL comes with Web Support. It boils down to having a Predicate parameter in REST controller method. The bad news is that you cannot do much of the customization. Imagine the ubiquitous example of Pet Shop, where we have to search by nickname using contains or exact match. The natural thing that comes to mind is having in a query parameter the search field, operator and value:

/pets?nickname=like:Br

/pets?nickname=Britney

The above example is possible if you extend QuerydslBinderCustomizer parse the parameter value, extract the operator and invoke the appropriate expression. But it is not possible if you have other data type than String. QueryDSL first looks at the Q type field and converts the value, only after that we have it in the customizer. For example, the following /pets?birthdate=between:2000-01-01,2023-01-01 will fail because the value between:2000-01-01,2023-01-01 cannot be parsed as LocalDate and we have no (correct) way to fix that.

Presenting RSQL-QueryDSL library

The philosophy behind the library is to be just a bridge between REST and QueryDSL. Things like parsing fields and operators, conversion of values, and building predicates are already well handled by Spring and QueryDSL.

So let’s jump straight to the example and see how it works in the Pet Shop web application.

First of all we add the dependency in our POM:

<dependency>
   <groupId>io.github.apulbere</groupId>
   <artifactId>rsql-querydsl</artifactId>
   <version>1.0</version>
</dependency>

Next, we define a DTO containing all fields that we want to use in the search:

@Setter
@Getter
public class PetCriteria {
    LongCriteria id = LongCriteria.empty();
    LocalDateCriteria born = LocalDateCriteria.empty();
    StringCriteria petType = StringCriteria.empty();
    StringCriteria nickname = StringCriteria.empty();
}

And finally, we use the above DTO as a parameter in the controller method. Spring will automatically map request parameters to the DTO:

@GetMapping("/pets")
List<PetRecord> search(PetCriteria criteria, Pageable page) {
    var predicate = criteria.id.match(pet.id)
            .and(criteria.born.match(pet.birthdate))
            .and(criteria.nickname.match(pet.name))
            .and(criteria.petType.match(pet.type));
    return petRepository.findAll(predicate, page)
            .stream()
            .map(petMapper::map)
            .toList();
}

Now we can make a request using the parameter names matching the ones from DTO and operators natural to their types. For example, it makes sense to have LIKE with String but not with Long:

/pets?nickname.like=Br

The above request produces the following SQL:

select
    p1_0.id,
    p1_0.birthdate,
    p1_0.name,
    p1_0.type 
from
    pet p1_0 
where
    lower(p1_0.name) like ? offset ? rows fetch first ? rows only

Full code can be found over on GitHub.

Running Java shebang with Kubernetes

Wed, 10 Aug 2022 00:00:00 +0000

Java 11, among other features, introduced the possibility of running a single Java source file. We are going to see a practical example of this feature running with kubernetes.

apiVersion: v1
kind: ConfigMap
metadata:
  name: java-shebang-config-map
data:
  script.sh: |
    #!/usr/bin/java --source 17

    public class App {

        public static void main(String args[]) {
            System.out.println("Hello Java Script");
        }
    }
---
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  volumes:
  - name: java-shebang-config
    configMap:
      name: java-shebang-config-map
      defaultMode: 0777
  containers:
  - image: openjdk:17.0.2-oracle
    command: ["./scripts/script.sh"]
    name: app
    volumeMounts:
      - mountPath: /scripts
        name: java-shebang-config
  restartPolicy: Never

kubectl create -f hello-java.yml
kubectl logs app

How to collect more than a single collection or a single scalar

Sun, 09 May 2021 00:00:00 +0000

A well-known characteristic of Java Stream is that it can be consumed only once, thus if we want to do some operations that require two passes or more through elements we have to create a new stream or develop a custom collector. Thankfully, Java 12 comes with Collectors::teeing that solves exactly this situation.

Imagine that we need a concise way to get both the min and max values of a stream.

We know how to do that if deal with specialized primitive streams by terminating it with operations like summarizingInt:

@Test
void shouldFindMinAndMaxInt() {
    IntSummaryStatistics statistics = IntStream.of(32, 42, 1, 2)
        .summaryStatistics();

    assertEquals(42, statistics.getMax());
    assertEquals(1, statistics.getMin());
}

Similarly we have specialized collectors when dealing with objects:

@Test
void shouldFindMinAndMaxProduct() {
    record Product(String label, double price) {}
    
    var products = Stream.of(
            new Product("T-Shirt", 12.99),
            new Product("socks", 5.09),
            new Product("pants", 89.1)
    );

    DoubleSummaryStatistics statistics = products.collect(
        Collectors.summarizingDouble(Product::price)
    );
    
    assertEquals(89.01, statistics.getMax());
    assertEquals(5.09, statistics.getMin());
}

The drawback of these collectors is that we don’t know which object is the max or min we have just its value. Using Collectors::maxBy and Collectors::minBy will require to pass the stream twice.

Thankfully, the following collector alleviates this problem:

public static <T, R1, R2, R> Collector<T, ?, R> teeing(
    Collector<? super T, ?, R1> downstream1,
    Collector<? super T, ?, R2> downstream2,
    BiFunction<? super R1, ? super R2, R> merger) {
    //...
}

Collectors::teeing has three arguments first two are downstream collectors. Every stream element is processed by each of them. The third parameter is a BiFunction that merges two results into the single one, e.g. it can be a function that creates a pair.

Consider the following record representing a movie:

record Movie(String title, double rating) {}

Finding the best and worst movie in a single stream pass is as simple as:

@Test
void shouldFindWorstAndBestMovie() {
    var m1 = new Movie("Groundhog Day", 8);
    var m2 = new Movie("Stop! Or My Mom Will Shoot", 4.4);
    var m3 = new Movie("Forrest Gump", 8.8);

    record MovieStatistics(Movie worst, Movie best) {}

    var ratingComparator = Comparator.comparing(Movie::rating);

    var movieStatistics = Stream.of(m1, m2, m3)
            .collect(Collectors.teeing(
                    Collectors.minBy(ratingComparator),
                    Collectors.maxBy(ratingComparator),
                    (worst, best) -> new MovieStatistics(
                            worst.orElse(null),
                            best.orElse(null)
                    )
            ));

    assertEquals(m2, movieStatistics.worst());
    assertEquals(m3, movieStatistics.best());
}

The best part about teeing collector is that we can handle much more complex scenarios by combining multiple collectors downstream. Consider the following enhanced Movie record:

record Movie(
    String title,
    double rating,
    List<Genre> genres
) {}

enum Genre {
    DRAMA,
    //...
}

We can find titles of drama movies and their average rating:

@Test
void shouldFindDramasTitlesAndAvgRating() {
    List<Movie> movies = readMoviesFromCSVFile();

    record MovieStatistics(List<String> titles, double avgRating) {}

    var movieStatistics = movies.stream()
            .filter(m -> m.genres().contains(DRAMA))
            .collect(teeing(
                    mapping(Movie::title, toList()),
                    averagingDouble(Movie::rating),
                    MovieStatistics::new
            ));

    var expectedTitles = List.of(
            "Pulp Fiction",
            "You've Got Mail",
            "Forrest Gump"
    );
    assertEquals(expectedTitles.size(), movieStatistics.titles().size());
    assertTrue(expectedTitles.containsAll(movieStatistics.titles()));
    assertEquals(8.13, movieStatistics.avgRating(), /* delta */ 2);
}

In the main pipeline we filter movies by genre, then in teeing collector, for one downstream we extract movie titles and collect them in a list. For the second downstream, we produce a scalar - average rating. Finally, for the merger function, we pass a constructor reference that matches types returned by both downstream collectors.

Conclusion

We can solve most of the problems with one out-of-the-box collector, even when we need to collect more than a collection or a scalar.

Full code can be found over on GitHub.