In the first part of this series, we explored the challenges Java developers face when manually creating Kubernetes manifests, such as the risk of errors, complexity, and time consumption.

In this second part, we dive into Dekorate, a powerful Java library that simplifies the process of generating Kubernetes manifests automatically, seamlessly integrating into your development workflow.

Overview of Dekorate

Dekorate is an open-source library that enables Java developers to generate Kubernetes manifests directly from code annotations. By building configurations into your application, you bridge the gap between application code and deployment configurations, reducing manual work and ensuring consistency.

Key Features

Design of Dekorate

Dekorate is built on a modular design to streamline Kubernetes resource generation. The core design revolves around annotation processors, crucial in interpreting annotations and generating configurations.

1. Annotation Processors: Dekorate includes multiple annotation processors, each responsible for generating Kubernetes resources for specific annotations. The compiler invokes these processors at least twice during the build process when it detects matching annotations in the code.
2. Processing Flow:
    — During each invocation, the annotation processor collects information from the annotated classes.
    — The final invocation signals the end of the processing stage when the collected data is passed to configuration handlers.
3. Configuration Handlers: Once the processing is complete, handlers receive the assembled configuration objects from the annotation processors. These handlers modify or create models based on the provided configuration.
4. Model Serialization: The resulting models are serialized into JSON or YAML files and stored on disk. These files include Deployment manifests, Service configurations, and other Kubernetes resources, ready for deployment.

This modular design ensures that Dekorate is flexible, extensible, and capable of handling a wide range of Kubernetes configurations.

It’s crucial to thoroughly understand the available configuration options to ensure seamless operation and prevent potential errors. You can refer to the github repo with Dekorate Configuration Documentation for detailed guidance.

Setting Up Dekorate in Your Project

Let’s explore how to integrate Dekorate into your Java project using Maven. Gradle users can follow a similar setup with minor adjustments.

1. Adding Dependencies

To begin, add Dekorate dependencies to your pom.xml file:

    <dependencies>
        <dependency>
            <groupId>io.dekorate</groupId>
            <artifactId>kubernetes-annotations</artifactId>
            <version>4.1.4</version>
        </dependency>

        <dependency>
            <groupId>io.dekorate</groupId>
            <artifactId>docker-annotations</artifactId>
            <version>4.1.4</version>
        </dependency>

        <dependency>
            <groupId>io.dekorate</groupId>
            <artifactId>helm-annotations</artifactId>
            <version>4.1.4</version>
        </dependency>

        <dependency>
            <groupId>io.dekorate</groupId>
            <artifactId>dekorate-spring-boot</artifactId>
            <version>4.1.4</version>
        </dependency>

        <!--Transitive dependencies to fix vulnerability of io.dekorate:dekorate-spring-boot:4.1.4-->
        <!-- GHSA-w33c-445m-f8w7 (5.9) Transitive Okio Signed to Unsigned Conversion Error vulnerability -->
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-compress</artifactId>
            <version>1.27.1</version>
        </dependency>
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-core</artifactId>
            <version>1.5.15</version>
        </dependency>
        <dependency>
            <groupId>com.squareup.okio</groupId>
            <artifactId>okio</artifactId>
            <version>3.9.0</version>
        </dependency>

    </dependencies>

For Gradle projects, include the following in your build.gradle file:

dependencies {
    // Dekorate dependencies
    implementation 'io.dekorate:kubernetes-annotations:4.1.4'
    implementation 'io.dekorate:docker-annotations:4.1.4'
    implementation 'io.dekorate:helm-annotations:4.1.4'
    implementation 'io.dekorate:dekorate-spring-boot:4.1.4'

    // Fix vulnerabilities for dekorate-spring-boot transitive dependencies
    implementation 'org.apache.commons:commons-compress:1.27.1'
    implementation 'ch.qos.logback:logback-core:1.5.15'
    implementation 'com.squareup.okio:okio:3.9.0'
}

Or .gradle.kts (Kotlin DSL):

dependencies {
    // Dekorate dependencies
    implementation("io.dekorate:kubernetes-annotations:4.1.4")
    implementation("io.dekorate:docker-annotations:4.1.4")
    implementation("io.dekorate:helm-annotations:4.1.4")
    implementation("io.dekorate:dekorate-spring-boot:4.1.4")

    // Fix vulnerabilities for dekorate-spring-boot transitive dependencies
    implementation("org.apache.commons:commons-compress:1.27.1")
    implementation("ch.qos.logback:logback-core:1.5.15")
    implementation("com.squareup.okio:okio:3.9.0")
}

2. Applying Annotations

With Dekorate, you define Kubernetes configurations using annotations. For example, to generate a Kubernetes Deployment, Service, Ingress, configure helm chart, and docker build, you should create a @Configuration annotated class :

package com.ih0rd.sandbox.config;

import io.dekorate.annotation.Dekorate;
import io.dekorate.docker.annotation.DockerBuild;
import io.dekorate.helm.annotation.HelmChart;
import io.dekorate.kubernetes.annotation.*;
import io.dekorate.kubernetes.config.DeploymentStrategy;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Configuration;

@SpringBootApplication
@KubernetesApplication(
        ingress = @Ingress(
                expose = true,
                ingressClassName = "nginx",
                host = "medium-article-part2.local",
                rules = {
                        @IngressRule(
                                host = "medium-article-part2.local",
                                serviceName = "medium-article-part2",
                                servicePortName = "8080"
                        )
                },
                tlsSecretName = "medium-article-part2-tls-secret",
                tlsHosts = {"medium-article-part2.local"}
        ),
        replicas = 2,
        ports = {@Port(name = "http", containerPort = 8080)},
        labels = {@Label(key = "article", value = "medium-part2-code")},
        livenessProbe = @Probe(
                httpActionPath = "/health/liveness",
                initialDelaySeconds = 5,
                timeoutSeconds = 3,
                failureThreshold = 10
        ),
        readinessProbe = @Probe(
                httpActionPath = "/health/readiness",
                initialDelaySeconds = 5,
                timeoutSeconds = 3,
                failureThreshold = 10
        ),
        requestResources = @ResourceRequirements(
                memory = "64Mi",
                cpu = "1m"
        ),
        limitResources = @ResourceRequirements(
                memory = "64Mi",
                cpu = "1m"
        ),
        rollingUpdate = @RollingUpdate(maxSurge = "50%", maxUnavailable = "50%"),
        deploymentStrategy = DeploymentStrategy.RollingUpdate,
        serviceType = ServiceType.LoadBalancer // Add LoadBalancer for work with Ingress
)
@DockerBuild(image = "custom-image:latest")
@HelmChart(name = "custom-helm-chart")
@Configuration // Just to register for Spring Boot app
public class K8sDekorateAnnotationsConfiguration {
}

3. Generating Manifests

Once the annotations are in place, build your project to generate the manifests. You can run Maven or Gradle or their wrappers (I prefer to use the wrapper’s approach):

./mvnw clean package

# or

./gradlew build

Dekorate will create the Kubernetes YAML(and JSON) files under the target/classes/META-INF/dekorate directory (for Maven) or build/classes/java/main/META-INF/dekorate directory (for Gradle).

Docker images and Helm charts will also be generated in their respective build directories.

├── helm
│   └── kubernetes
│       └── custom-helm-chart
│           ├── Chart.yaml
│           ├── README.md
│           ├── charts
│           ├── templates
│           │   ├── NOTES.txt
│           │   ├── deployment.yaml
│           │   └── service.yaml
│           ├── values.schema.json
│           └── values.yaml
├── kubernetes.json
└── kubernetes.yml

4. Reviewing Generated Manifests

Inspect the generated files to ensure they match your deployment requirements. For instance, a kubernetes.yml might look like this:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    app.dekorate.io/vcs-url: git@github.com:ih0r-d/examples-for-medium-articles.git
    app.dekorate.io/commit-id: 0bd629113c344c4b8948f239d8929fe31a4f87d6
  labels:
    app.kubernetes.io/name: medium-articles-k8s-generation-sandbox
    app.kubernetes.io/version: 0.0.1-SNAPSHOT
    article: medium-part2-code
  name: medium-articles-k8s-generation-sandbox
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: medium-articles-k8s-generation-sandbox
      app.kubernetes.io/version: 0.0.1-SNAPSHOT
      article: medium-part2-code
  strategy:
    rollingUpdate:
      maxSurge: 50%
      maxUnavailable: 50%
    type: RollingUpdate
  template:
    metadata:
      annotations:
        app.dekorate.io/vcs-url: git@github.com:ih0r-d/examples-for-medium-articles.git
        app.dekorate.io/commit-id: 0bd629113c344c4b8948f239d8929fe31a4f87d6
      labels:
        app.kubernetes.io/name: medium-articles-k8s-generation-sandbox
        app.kubernetes.io/version: 0.0.1-SNAPSHOT
        article: medium-part2-code
    spec:
      containers:
        - env:
            - name: KUBERNETES_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          image: custom-image:latest
          imagePullPolicy: IfNotPresent
          livenessProbe:
            failureThreshold: 10
            httpGet:
              path: /health/liveness
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 5
            periodSeconds: 30
            successThreshold: 1
            timeoutSeconds: 3
          name: medium-articles-k8s-generation-sandbox
          ports:
            - containerPort: 8080
              name: http
              protocol: TCP
          readinessProbe:
            failureThreshold: 10
            httpGet:
              path: /health/readiness
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 5
            periodSeconds: 30
            successThreshold: 1
            timeoutSeconds: 3
          resources:
            limits:
              cpu: 1m
              memory: 64Mi
            requests:
              cpu: 1m
              memory: 64Mi
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    app.dekorate.io/vcs-url: git@github.com:ih0r-d/examples-for-medium-articles.git
    app.dekorate.io/commit-id: 0bd629113c344c4b8948f239d8929fe31a4f87d6
  labels:
    app.kubernetes.io/name: medium-articles-k8s-generation-sandbox
    app.kubernetes.io/version: 0.0.1-SNAPSHOT
    article: medium-part2-code
  name: medium-articles-k8s-generation-sandbox
spec:
  ingressClassName: nginx
  rules:
    - host: medium-article-part2.local
      http:
        paths:
          - backend:
              service:
                name: medium-article-part2
                port:
                  name: "8080"
            path: /
            pathType: Prefix
  tls:
    - hosts:
        - medium-article-part2.local
      secretName: medium-article-part2-tls-secret
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    app.dekorate.io/vcs-url: git@github.com:ih0r-d/examples-for-medium-articles.git
    app.dekorate.io/commit-id: 0bd629113c344c4b8948f239d8929fe31a4f87d6
  labels:
    app.kubernetes.io/name: medium-articles-k8s-generation-sandbox
    app.kubernetes.io/version: 0.0.1-SNAPSHOT
    article: medium-part2-code
  name: medium-articles-k8s-generation-sandbox
spec:
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app.kubernetes.io/name: medium-articles-k8s-generation-sandbox
    app.kubernetes.io/version: 0.0.1-SNAPSHOT
    article: medium-part2-code
  type: LoadBalancer

And, let’s imagine how Dekorate integrates into your project, consider the following workflow:

Advantages of Using Dekorate

• Simplified Configuration:
  Eliminates the need for hand-written YAML files.
• Consistency:
  Reduces the risk of configuration drift between code and deployment settings.
• Developer Productivity:
  Speeds up the Kubernetes deployment process, allowing developers to focus on coding.
• Advanced Features:
  Supports CRDs, ConfigMaps, Secrets, Ingress, Docker images, and Helm charts.
• Multi-Platform Support:
  Enables deployment to Kubernetes, OpenShift, Knative, and Helm seamlessly.
• Docker and Helm Integration:
  Automates the generation of Docker images and Helm charts, streamlining complex deployments.
• Testing Support:
  Ensures Kubernetes configurations are tested and validated during development.

Dekorate has a lot of advantages, but for me, the more interesting is testing support, do you ask me what I mean? Let’s see an example of tests for generated manifests.

Tests folder structure:

src/test/java/com/ih0rd/sandbox/
├── DekorateK8sConfigTest.java  // Main test class for verifying Dekorate-generated Kubernetes resources
└── SharedUtils.java            // Utility class for loading and querying Kubernetes resources in tests

• DekorateK8sConfigTest.java:
   — Contains integration tests to validate that Dekorate annotations correctly generate Kubernetes resources (e.g., Deployment, Ingress, Service).
   — Includes methods to check the structure and properties of the generated resources.

package com.ih0rd.sandbox;

import io.dekorate.helm.model.Chart;
import io.fabric8.kubernetes.api.model.*;
import io.fabric8.kubernetes.api.model.apps.Deployment;
import io.fabric8.kubernetes.api.model.networking.v1.Ingress;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;


import java.io.IOException;

import static org.junit.jupiter.api.Assertions.*;

public class DekorateK8sConfigTest {

    private static KubernetesList K8S_RESOURCES;
    private static final String EXPECTED_DEPLOYMENT_NAME = "medium-articles-k8s-generation-sandbox";
    private static final String EXPECTED_IMAGE = "custom-image:latest";
    private static final String EXPECTED_INGRESS_HOST = "medium-article-part2.local";
    private static final String EXPECTED_TLS_SECRET = "medium-article-part2-tls-secret";
    private static final String EXPECTED_HELM_CHART_NAME = "custom-helm-chart";

    @BeforeAll
    static void setupAll() {
        K8S_RESOURCES = SharedUtils.loadKubernetesResources();
    }

    @Test
    public void shouldGenerateDeployment() {
        assertNotNull(K8S_RESOURCES, "Kubernetes resources should not be null");
        Deployment deployment = SharedUtils.findFirst(Deployment.class);
        assertNotNull(deployment, "Deployment resource should exist");
        assertEquals(EXPECTED_DEPLOYMENT_NAME, deployment.getMetadata().getName(), "Deployment name mismatch");

        final AnyType expectedRollingUpdateMaxValue = new AnyType("50%");
        // Validate replicas and strategy
        assertEquals(2, deployment.getSpec().getReplicas(), "Replica count mismatch");
        assertEquals("RollingUpdate", deployment.getSpec().getStrategy().getType(), "Deployment strategy mismatch");
        assertEquals(expectedRollingUpdateMaxValue, deployment.getSpec().getStrategy().getRollingUpdate().getMaxSurge(), "MaxSurge mismatch");
        assertEquals(expectedRollingUpdateMaxValue, deployment.getSpec().getStrategy().getRollingUpdate().getMaxUnavailable(), "MaxUnavailable mismatch");
    }

    @Test
    public void shouldSetContainerImage() {
        Deployment deployment = SharedUtils.findFirst(Deployment.class);
        assertNotNull(deployment, "Deployment resource should exist");

        Container container = deployment.getSpec().getTemplate().getSpec().getContainers().getFirst();
        assertNotNull(container, "Container should exist in Deployment");
        assertEquals(EXPECTED_IMAGE, container.getImage(), "Container image mismatch");
    }


    @Test
    public void shouldExposeServiceAsLoadBalancer() {
        Service service = SharedUtils.findFirst(Service.class);
        assertNotNull(service, "Service resource should exist");
        assertEquals("LoadBalancer", service.getSpec().getType(), "Service type mismatch");
    }

    @Test
    public void shouldGenerateHelmChart() throws IOException {
        Chart chart = SharedUtils.read("META-INF/dekorate/helm/kubernetes/" + EXPECTED_HELM_CHART_NAME + "/Chart.yaml", Chart.class);
        assertNotNull(chart, "Helm chart should exist");
        assertEquals(EXPECTED_HELM_CHART_NAME, chart.getName(), "Helm chart name mismatch");
    }

    @Test
    public void shouldGenerateIngress() {
        Ingress ingress = SharedUtils.findFirst(Ingress.class);
        assertNotNull(ingress, "Ingress resource should exist");
        assertEquals(EXPECTED_INGRESS_HOST, ingress.getSpec().getRules().getFirst().getHost(), "Ingress host mismatch");

        // Validate TLS
        assertEquals(EXPECTED_TLS_SECRET, ingress.getSpec().getTls().getFirst().getSecretName(), "TLS secret name mismatch");
        assertTrue(ingress.getSpec().getTls().getFirst().getHosts().contains(EXPECTED_INGRESS_HOST), "TLS host mismatch");
    }
}

• SharedUtils.java:
   — Provides helper methods to load Kubernetes YAML files generated by Dekorate.
   — Includes utility methods such as findFirst for locating specific resource types within the Kubernetes manifest.

package com.ih0rd.sandbox;

import io.dekorate.utils.Serialization;
import io.fabric8.kubernetes.api.model.HasMetadata;
import io.fabric8.kubernetes.api.model.KubernetesList;

import java.io.IOException;
import java.util.Objects;

import static org.junit.jupiter.api.Assertions.assertNotNull;

public class SharedUtils {

    private static final String K8S_MANIFEST = "META-INF/dekorate/kubernetes.yml";

    public static KubernetesList loadKubernetesResources() {
        return Serialization.unmarshalAsList(Objects.requireNonNull(SharedUtils.class.getClassLoader().getResourceAsStream(K8S_MANIFEST)));
    }

    @SuppressWarnings("unchecked")
    public static <T extends HasMetadata> T findFirst(Class<T> clazz) {
        KubernetesList list = loadKubernetesResources();
        assertNotNull(list);

        return (T) list.getItems().stream()
                .filter(clazz::isInstance)
                .findFirst()
                .orElseThrow(() -> new IllegalStateException("Resource of type " + clazz.getName() + " not found"));
    }

    public static <T> T read(String path, Class<T> clazz) throws IOException {
        return Serialization.yamlMapper().readValue(SharedUtils.class.getClassLoader()
                .getResourceAsStream(path), clazz);
    }

}

After building a project, all tests run and passed

[INFO] --- maven-surefire-plugin:3.5.2:test (default-test) @ medium-articles-k8s-generation-sandbox ---
[INFO] Using auto detected provider org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[INFO] 
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.ih0rd.sandbox.DekorateK8sConfigTest
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.522 s -- in com.ih0rd.sandbox.DekorateK8sConfigTest
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] 
[INFO] --- maven-jar-plugin:3.4.2:jar (default-jar) @ medium-articles-k8s-generation-sandbox ---
[INFO] Building jar: /Users/ihordidyk/Documents/personal/projects/medium-articles-k8s-generation-sandbox/target/medium-articles-k8s-generation-sandbox-0.0.1-SNAPSHOT.jar
[INFO] 
[INFO] --- spring-boot-maven-plugin:3.4.1:repackage (repackage) @ medium-articles-k8s-generation-sandbox ---
[INFO] Replacing main artifact /Users/ihordidyk/Documents/personal/projects/medium-articles-k8s-generation-sandbox/target/medium-articles-k8s-generation-sandbox-0.0.1-SNAPSHOT.jar with repackaged archive, adding nested dependencies in BOOT-INF/.
[INFO] The original artifact has been renamed to /Users/ihordidyk/Documents/personal/projects/medium-articles-k8s-generation-sandbox/target/medium-articles-k8s-generation-sandbox-0.0.1-SNAPSHOT.jar.original
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  3.917 s
[INFO] Finished at: 2024-12-26T19:21:59+02:00
[INFO] ------------------------------------------------------------------------

For a more detailed example, see the code on GitHub

Limitations of Dekorate

While Dekorate offers a host of advantages, it also comes with certain limitations that developers should be aware of:

• Learning Curve:
  The extensive annotation-based configuration requires developers to familiarize themselves with numerous annotations, which can be challenging for beginners.
• Customization Constraints:
  While annotations are a powerful tool, they may not cover all edge cases or provide the flexibility that handwritten YAML files can offer. Currently, annotations do not support Spring Expression Language (SpEL), meaning values cannot be dynamically retrieved from application.properties or similar configuration files, resulting in hard-coded values.
  However, you can combine Dekorate annotations with Spring @Value annotations for more flexible configurations.
  This approach allows you to externalize configuration values while using annotation-based manifest generation.
• Dependency Management:
  The reliance on multiple dependencies might lead to versioning issues or conflicts, especially in large projects.
• Limited Ecosystem for Testing:
  Although integration testing is supported, the ecosystem for advanced testing scenarios (e.g., simulating failures) is still evolving.
• Tight Coupling with Code:
  Embedding Kubernetes configurations directly in the application code can lead to tighter coupling, making the configuration less reusable across projects.
• Build Tool Dependence:
  While Dekorate supports Maven and Gradle, using less common build tools might require additional configuration effort.

Despite these limitations, Dekorate remains a valuable tool for Java developers seeking to streamline Kubernetes manifest generation and deployment.

Next steps

Dekorate has proven to be a great tool for automating Kubernetes manifests, Docker images, and Helm diagrams, as seen in this article. In Part 1: The Problem with Kubernetes Manifests for Java Developers, we discussed common problems that Java developers face when working with Kubernetes manifests, including the difficulty of writing YAML files by hand and managing them.
Dekorate solves many of these problems, but is it the perfect solution?

In the next part of this series, we will dive deeper into Eclipse JKube, a tool that offers more than just manifest generation.
Does JKube simplify the process even more?
Can it provide a more integrated experience for Java developers?

We’ll compare it with Dekorate, explore its strengths and weaknesses, and see which tool is better suited for different use cases.

Stay tuned to see how we take this comparison to the next level and explore the full potential of Kubernetes integration for Java applications!

Resources

Here are some helpful links related to Dekorate and Kubernetes:

• Dekorate Official Documentation— Learn more about Dekorate’s features and configurations.
• GitHub Repository for Dekorate — Access the source code and examples.
• Fabric8 Kubernetes Client — The library Dekorate uses for Kubernetes resource generation.
• Helm Documentation — Learn about Helm charts and their usage.

For Java developers, balancing the complexity of Kubernetes’ manifestations with the intricacies of application logic can be overwhelming.

This article is the first part of a series on “Creating Kubernetes Manifests” that discusses how Java developers can simplify and automate the creation of Kubernetes manifests.

Let’s dive into the agenda and explore how Kubernetes manifests play a crucial role in efficiently deploying Java applications.

• Introduction to Kubernetes manifests and their role.
• Types of Kubernetes manifests.
• Challenges of manual YAML creation (errors, complexity, time).

Short introduction of k8s manifests and their role.

Let’s start from k8s lifecycle:

Lifecycle explanation:

1. Developers write a manifest (e.g., Deployment, Service).
2. The manifest is applied to the cluster (kubectl apply).
3. Kubernetes’ API server processes the manifest and passes the instructions to the scheduler and controller manager.
4. Kubernetes ensures the desired state is achieved and maintains it over time.

For this guide, we’ll focus on Kubernetes manifests — the backbone of deploying applications in Kubernetes. They are YAML or JSON files that describe the desired state of an application, allowing Kubernetes to manage the deployment, scaling, and configuration of your workloads automatically. For Java developers, Kubernetes manifests provide a declarative way to ensure their applications run reliably in production environments.

Why Manifests Are of Crucial Importance?

Manifests serve as the authoritative source of truth for the configuration and deployment of your application. They enable you to:

• Define the number of application replicas to run.
• Specify container images, environment variables, and resource limits.
• Expose your application to the network via Services or Ingress.
• Manage application secrets and configuration using ConfigMaps or Secrets.

Without manifests, deploying and scaling applications in Kubernetes would become a disorganized and error-prone process. However, manually writing and maintaining these files can be challenging, particularly as the complexity of your application increases.

The Challenges of Manual Manifest Management

1. Complexity: Even for a simple application, multiple manifest files may be required. For instance, a basic microservice typically needs a Deployment, a Service, and potentially a ConfigMap or Secret.
2. Error-Prone: YAML syntax is notoriously unforgiving. A misplaced space or indentation can break your deployment.
3. Time-Consuming: Updating manifests manually for every version change or configuration adjustment can consume significant developer time, diverting focus from more critical tasks.

Below are the main Kubernetes manifests for deploying typical Java applications, along with examples, workflows, and brief explanations:

A Deployment defines how your application runs, including the number of replicas and the container details. It ensures high availability by maintaining the desired number of application instances, handling updates and scaling seamlessly.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: java-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: java-app
  template:
    metadata:
      labels:
        app: java-app
    spec:
      containers:
        - name: java-app-container
          image: java-app:1.0.0
          ports:
            - containerPort: 8080

A Service exposes your application to other components or external users, allowing consistent access regardless of Pod IP changes. It serves as a reliable communication endpoint, abstracting the details of individual Pods and ensuring consistent traffic routing to the application, even when Pods are replaced or restarted.

apiVersion: v1
kind: Service
metadata:
  name: java-app-service
spec:
  selector:
    app: java-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

A ConfigMap stores configuration data (like env variables) separately from the application, making it easier to update without redeploying the app. By decoupling configuration from the application, ConfigMaps make it easy to adapt settings for different environments or deployments.

apiVersion: v1
kind: ConfigMap
metadata:
  name: java-app-config
data:
  APP_NAME: "My Java App"
  APP_VERSION: "1.0.0"

Ingress provides external access to your application via HTTP/HTTPS, often with load balancing and SSL termination, handles external HTTP/HTTPS traffic and routes it to the correct Service, enabling seamless external access to your Java app.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: java-app-ingress
spec:
  rules:
    - host: java-app.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: java-app-service
                port:
                  number: 80

A Secret securely stores sensitive data like API keys or database credentials, protecting them from being exposed in plain text, it provides a secure way to manage sensitive data without hardcoding it into your application or configuration files.

apiVersion: v1
kind: Secret
metadata:
  name: java-app-secret
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQ=

# The value is base64-encoded

PersistentVolumeClaim (PVC) requests storage for your application, such as logs or data storage needs, ensuring stable and persistent data availability, it simplifys storage management by abstracting the underlying storage details while ensuring data persistence for your application.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: java-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Thank you for reading! 🙌

In this article, we explored the role of Kubernetes manifests, the common challenges developers encounter when creating them manually, and an overview of the different types of manifests.

In the upcoming “Part 2: Automating Kubernetes Manifests” we’ll delve into strategies for streamlining manifest creation and enhancing your development workflow.

Stay tuned for more insights!🚀

In today’s world of software development, security is paramount. One of the key strategies to enhance security is through sandboxing, which allows code to be executed in a controlled environment.
This article will explore how to implement secure sandboxing in GraalVM, focusing on practical examples, security policies, and best practices.

🛡️Understanding Sandboxing and Its Importance

Sandboxing is a security mechanism used to run applications in a restricted environment. This ensures that even if an application is compromised, the damage it can cause is limited. By isolating the application from critical system resources and limiting its permissions, sandboxing provides an additional layer of security, especially in environments where code from untrusted sources may be executed.

Sandboxing techniques involve creating a controlled execution environment where the application has restricted access to the host system’s resources. This is crucial for mitigating risks such as unauthorized data access, system crashes, and malicious attacks.

In the context of GraalVM, sandboxing can be effectively implemented using the Truffle API and Espresso project. GraalVM’s polyglot capabilities allow for the secure execution of code from multiple languages within the same runtime environment, providing robust security measures.
For an in-depth understanding of GraalVM’s approach to security, visit the GraalVM Security Documentation.

🚀 Introducing GraalVM and Project Espresso

🌐 GraalVM Overview
GraalVM is a high-performance runtime that provides significant advantages for running applications written in various programming languages, including Java, JavaScript, Python, Ruby, and more. It integrates with the JVM and supports ahead-of-time (AOT) compilation, offering substantial performance improvements and reduced startup times.

☕ Project Espresso Overview
Project Espresso is an implementation of the Java Virtual Machine (JVM) on top of the Truffle framework within GraalVM. It allows running Java bytecode with the added benefits of GraalVM’s multilingual capabilities. Espresso enables secure and efficient execution of Java applications by leveraging the Truffle framework to optimize Java bytecode execution.

It encompasses all the essential components of a Java Virtual Machine:

• Bytecode interpreter
• Bytecode verifier
• Single-pass. class file parser
• Simplified object model
• Java Native Interface (JNI) implemented in Java
• Virtual Machine implemented in Java
• Java Debug Wire Protocol (JDWP)

A key aspect of this implementation is that it is entirely written in Java. This makes Java on Truffle essentially “Java on Java”! Achieving self-hosting is considered the holy grail in the research and development of Java virtual machines.

👍 Pros of Using GraalVM and Project Espresso

1. Performance Improvements: GraalVM’s Just-In-Time (JIT) compiler and AOT compilation can significantly improve the performance of Java applications.
2. Polyglot Capabilities: GraalVM allows seamless interoperability between different programming languages, enabling the integration of Java with languages like JavaScript, Python, and more.
3. Advanced Tooling: GraalVM provides advanced tools for profiling, debugging, and monitoring applications.
4. Security Enhancements: Project Espresso allows for sandboxing Java applications, adding an extra layer of security by running code in a restricted environment.
5. Native Image: GraalVM’s native image feature allows Java applications to be compiled into standalone executables, improving startup times and reducing memory footprint.

👎 Cons of Using GraalVM and Project Espresso

1. Compatibility Issues: Some Java libraries and frameworks may not be fully compatible with GraalVM or Project Espresso.
2. Complexity: Setting up and configuring GraalVM and Project Espresso can be more complex than using a standard JVM.
3. Learning Curve: Developers may need to invest time in learning the new tools and features provided by GraalVM and Project Espresso.
4. Limited Ecosystem Support: Although growing, the ecosystem around GraalVM and Project Espresso is still smaller compared to the traditional JVM ecosystem

🛠️ Setting Up Your Environment

To get started, ensure you have GraalVM installed on your system. You can download the latest version from the GraalVM website or use the SDKman tool.

sdk install java 22.3.r17-grl
sdk use java 22.3.r17-grl

Once installed, configure your environment to use GraalVM as the default JVM.

Next, we’ll set up a Maven project with the necessary dependencies. Add the following dependencies to your pom.xml file:

    <dependencies>
        <!-- GraalVM SDK for Java -->
        <dependency>
            <groupId>org.graalvm.sdk</groupId>
            <artifactId>graal-sdk</artifactId>
            <version>24.0.1</version>
        </dependency>
        <!-- Truffle API -->
        <dependency>
            <groupId>org.graalvm.truffle</groupId>
            <artifactId>truffle-api</artifactId>
            <version>24.0.1</version>
        </dependency>
        <!-- Espresso -->
        <dependency>
            <groupId>org.graalvm.espresso</groupId>
            <artifactId>espresso-language</artifactId>
            <version>24.0.1</version>
            <scope>runtime</scope>
        </dependency>
    </dependencies>

📁 Project Structure

🔒 Creating a Secure Context

To create a secure context for running Java applications, you’ll need to configure the polyglot context in GraalVM and disable potentially risky functions such as eval.

Here’s a simple ContextManager to get you started. That provides utility methods to create and manage secured GraalVM Polyglot Context with configurations:

import org.graalvm.polyglot.Context;
import org.graalvm.polyglot.HostAccess;

import static com.github.ih0rd.utils.Constants.JAVA_LANG_ID;

/**
 * The {@code ContextManager} class provides a utility method to create a secured
 * GraalVM polyglot {@link Context} with specific configurations.
 * <p>
 * This class is designed to prevent instantiation and only offers a static method
 * to retrieve a configured {@link Context} instance.
 * </p>
 */
public class ContextManager {

    /**
     * Private constructor to prevent instantiation of this utility class.
     */
    private ContextManager() {
    }

    /**
     * Creates and returns a secured GraalVM polyglot context for Java.
     * <p>
     * The context is configured with various security restrictions to enhance the safety
     * of executing untrusted code. The following restrictions are applied:
     * <ul>
     *   <li>Host access is disabled ({@code HostAccess.NONE}).</li>
     *   <li>File I/O operations are not allowed ({@code allowIO(false)}).</li>
     *   <li>Native access is not allowed ({@code allowNativeAccess(false)}).</li>
     *   <li>Creating new processes is not allowed ({@code allowCreateProcess(false)}).</li>
     *   <li>All access permissions are disabled ({@code allowAllAccess(false)}).</li>
     *   <li>Experimental options are enabled ({@code allowExperimentalOptions(true)}).</li>
     * </ul>
     *
     * @return a {@link Context} instance configured with the specified security restrictions.
     */
    public static Context getSecuredContext() {
        return Context.newBuilder(JAVA_LANG_ID)
                .allowHostAccess(HostAccess.NONE)
                .allowIO(false)
                .allowNativeAccess(false)
                .allowCreateProcess(false)
                .allowAllAccess(false)
                .allowExperimentalOptions(true)
                .option("engine.WarnInterpreterOnly","false")
                .build();
    }

}

Also, we need GraalVMExecutor to manage the execution of operations within a secured GraalVM Polyglot context:

import com.github.ih0rd.exceptions.GraalVMPlaygroundException;
import com.oracle.truffle.api.*;


import org.graalvm.polyglot.Context;

/**
 * A class to manage the execution of operations within a secured GraalVM polyglot context.
 */
public class GraalVmExecutor implements AutoCloseable{

    private final Context context;

    /**
     * Constructs a new GraalVmExecutor with a secured GraalVM polyglot context.
     */
    public GraalVmExecutor() {
        context = ContextManager.getSecuredContext();
    }

    /**
     * Loads a class into the GraalVM polyglot context, creates an instance of the class,
     * and retrieves it from the context's polyglot bindings.
     *
     * @param <T>   The type of the class to be loaded.
     * @param clazz The class to be loaded and instantiated.
     * @return An instance of the class loaded from the context's polyglot bindings.
     * @throws GraalVMPlaygroundException if the class cannot be loaded or instantiated.
     */
    public <T> T loadClassIntoContext(Class<T> clazz) {
        try {
            var instance = clazz.getDeclaredConstructor().newInstance();
            var memberName = clazz.getSimpleName();
            context.getPolyglotBindings().putMember(memberName, instance);
            return context.getPolyglotBindings().getMember(memberName).as(clazz);
        } catch (Exception e) {
            throw new GraalVMPlaygroundException("Failed to load class into context", e);
        }
    }

    /**
     * Executes a specified method of a given class with provided arguments using Truffle.
     *
     * @param clazz      The class containing the method to be executed.
     * @param methodName The name of the method to be executed.
     * @param args       The arguments to be passed to the method during execution.
     * @return The result of the method execution.
     */
    public Object executeMethod(Class<?> clazz, String methodName, Object... args) {
        var runtime = Truffle.getRuntime();
        var javaNode = new JavaNode(clazz, methodName, args);
        var directCallNode = runtime.createDirectCallNode(javaNode.getCallTarget());
        return directCallNode.call(args);
    }


    /**
     * Closes the GraalVM polyglot context if it is open.
     */
    public void closeContext() {
        if (context != null) {
            context.close();
        }
    }

    @Override
    public void close() throws Exception {
        closeContext();
    }
}

The GraalVmExecutor class is designed to manage the execution of operations within a secured GraalVM polyglot context. It demonstrates how to securely load and execute Java classes and methods using the Truffle API, ensuring that an execution is contained within a sandboxed environment. This approach enhances security by preventing unauthorized access and potential vulnerabilities.

For now, we are ready to load some Java implementation from GraalVM. Here’s a correct example to get you started:

public class HelloWorld {
    public void printHello() {
        System.out.println("Hello, secure GraalVM context with Espresso!");
    }

    public int simplyMultiply(int a, int b) {
        return a * b;
    }
}

To demonstrate the practical usage of the GraalVmExecutor class, we can create a simple application that initializes the executor, loads a class, and executes methods within the secured GraalVM context. The following GraalvmPlaygroundApplication class serves as an entry point, showcasing how to perform these operations seamlessly.

import com.github.ih0rd.domain.HelloWorld;
import com.github.ih0rd.helpers.GraalVmExecutor;

public class GraalvmPlaygroundApplication {

    public static void main(String[] args) {

        var graalVMExecutor = new GraalVmExecutor();

        HelloWorld helloWorld = graalVMExecutor.loadClassIntoContext(HelloWorld.class);
        helloWorld.printHello();
        System.out.println("helloWorld.simplyMultiply(2,5) = " + helloWorld.simplyMultiply(2, 5));

        // Execute method via Truffle API & Espresso
        Object printHelloResult = graalVMExecutor.executeMethod(HelloWorld.class, "printHello");
        System.out.println("printHelloResult = " + printHelloResult);
        
        Object simplyMultiplyResult = graalVMExecutor.executeMethod(HelloWorld.class, "simplyMultiply", 2, 3);
        System.out.println("simplyMultiplyResult = " + simplyMultiplyResult);
        
        graalVMExecutor.closeContext();
    }

}

⚙️ Configuring '--add-exports' for GraalVM

The --add-exports options are necessary because they allow the GraalVM runtime to access specific internal APIs required by the Truffle framework and the Espresso project.
These configurations ensure that your application can utilize these APIs without running into access restrictions that could prevent it from functioning correctly. Properly configuring these options is important to avoid errors such as NoClassDefFoundError or ClassNotFoundException.
Proper configuration also enhances security by explicitly specifying which internal packages are accessible, thus preventing unintended exposure other system .

🛠️ Maven Configuration

Add the necessary plugins and configurations to your pom.xml to include the --add-exports options when building your project:

    <properties>
        <java.version>17</java.version>
        <graal.version>24.0.1</graal.version>
        <plugin.encoding>UTF-8</plugin.encoding>
        <manifest.mainClass>com.github.ih0rd.GraalvmPlaygroundApplication</manifest.mainClass>
    </properties>
    
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.13.0</version>
                <configuration>
                    <source>${java.version}</source>
                    <target>${java.version}</target>
                    <release>${java.version}</release>
                    <encoding>${plugin.encoding}</encoding>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>3.4.2</version>
                <configuration>
                    <archive>
                        <manifestEntries>
                            <Add-Exports>
                                org.graalvm.truffle/com.oracle.truffle.api=ALL-UNNAMED,
                                org.graalvm.truffle/com.oracle.truffle.api.frame=ALL-UNNAMED,
                                org.graalvm.truffle/com.oracle.truffle.api.nodes=ALL-UNNAMED,
                                org.graalvm.truffle/com.oracle.truffle.api.source=ALL-UNNAMED
                            </Add-Exports>
                        </manifestEntries>
                        <manifest>
                            <mainClass>${manifest.mainClass}</mainClass>
                        </manifest>
                    </archive>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-shade-plugin</artifactId>
                <version>3.5.3</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>shade</goal>
                        </goals>
                        <configuration>
                            <transformers>
                                <transformer
                                        implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                                    <mainClass>${manifest.mainClass}</mainClass>
                                </transformer>
                            </transformers>
                            <filters>
                                <filter>
                                    <artifact>*:*</artifact>
                                    <excludes>
                                        <exclude>module-info.class</exclude>
                                        <exclude>META-INF/MANIFEST.MF</exclude>
                                        <exclude>
                                            META-INF/services/com.oracle.truffle.api.instrumentation.provider.TruffleInstrumentProvider
                                        </exclude>
                                        <exclude>
                                            META-INF/services/com.oracle.truffle.api.provider.TruffleLanguageProvider
                                        </exclude>
                                    </excludes>
                                </filter>
                            </filters>
                            <createDependencyReducedPom>false</createDependencyReducedPom>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-resources-plugin</artifactId>
                <version>3.3.1</version>
                <configuration>
                    <encoding>${plugin.encoding}</encoding>
                </configuration>
            </plugin>
        </plugins>
    </build>

🖥️ IntelliJ IDEA Configuration

To run your project from IntelliJ IDEA with the necessary --add-exports options, follow these steps:

• Open IntelliJ IDEA:
  - Open your project in IntelliJ IDEA.
• Edit Run/Debug Configuration:
  - Go to Run -> Edit Configurations...
• Select your Application Configuration:
  - select the configuration for your main class, or create a new one if it doesn’t exist.
• Add VM Options:
  - In the VM options field, add the following options to grant access to the necessary packages:

--add-exports=org.graalvm.truffle/com.oracle.truffle.api=ALL-UNNAMED
--add-exports=org.graalvm.truffle/com.oracle.truffle.api.frame=ALL-UNNAMED
--add-exports=org.graalvm.truffle/com.oracle.truffle.api.nodes=ALL-UNNAMED
--add-exports=org.graalvm.truffle/com.oracle.truffle.api.source=ALL-UNNAMED
--add-exports=org.graalvm.truffle/com.oracle.truffle.api.exception=ALL-UNNAMED
--add-exports=org.graalvm.truffle/com.oracle.truffle.api.staticobject=ALL-UNNAMED

🚀 Building and Running with java -jar

To build and run your project using java -jar, follow these steps:

• Build the Project:
  Run the Maven build command to create the shaded JAR:

mvn clean package

• Run the Shaded JAR:
  Use the java -jar command to run your JAR file:

java -jar target/graalvm-playground-0.0.1-SNAPSHOT.jar

🎉 Conclusion

Implementing sandboxing in GraalVM using the Truffle API and Espresso project offers a robust way to securely execute Java applications. By leveraging GraalVM’s capabilities, developers can create controlled environments that limit the access of executed code to the host system, thereby mitigating potential security risks.

In this article, we explored:

• Techniques for Secure Sandboxing in GraalVM:
  Understanding how sandboxing works and how GraalVM, Truffle, and Espresso can be used to create a secure environment.
• Practical Examples and Best Practices:
  Detailed examples demonstrating how to set up GraalVM, configure a secure context and execute methods within the sandbox using the Truffle API.

By following these techniques and best practices, you can enhance the security of your Java applications. GraalVM’s sandboxing capabilities, combined with Truffle and Espresso, provide a powerful toolset for running Java code in a secure and controlled manner. This approach helps in preventing unauthorized access and potential security vulnerabilities, ensuring your applications run safely and securely.

Feel free to reach out with any questions or share your experiences in the comments below. Your feedback is invaluable as we explore the capabilities of GraalVM together. Happy coding!

Check out the complete code and examples on my GitHub repository.

#GraalVM #Java #Security #Sandboxing #ProjectEspresso #TruffleFramework #Polyglot #Programming #DevOps

As a software developer constantly striving to optimize processes, I recently faced a significant challenge: maintaining separate Python services for individual functions in our Java microservice architecture.
It was a hassle, causing unnecessary delays in deployment and adding complexity.

In this article, I’ll talk about GraalPy, which can be used as a platform to execute Python code directly into our Java microservices using the GraalVM Polyglot API, transforming our workflow and saving valuable time.

🔍 The Problem

In our microservices architecture, we relied on Python to perform specific tasks, such as data processing, analytics, or simplex algorithms. At first, we deployed them as separate services.

However, this approach soon revealed its drawbacks. Each minor update required a full deployment cycle, which increased the workload of our DevOps team and led to delays. In addition, maintaining these isolated services created complexity and multiple points of failure in our system.

💡Discovering Graalpy

During one of my research sessions, I came across GraalPy, a project under GraalVM that promised seamless integration of Python code into Java applications.

Although the project is still experimental, embedding Python functions directly into our Java microservices is intriguing. I am hopeful but cautious, as integrating two different programming languages can cause unforeseen problems.

🛠️ The Investigation Journey

Before we begin our research, a few details about the GraalPy, namely Python runtime from the documentation.

GraalPy provides a Python 3.10-compliant runtime. A primary goal is to support PyTorch, SciPy, and their constituent libraries, as well as to work with other data science and machine learning libraries from the rich Python ecosystem. GraalPy is distributed as an ahead-of-time compiled native executable, compact.

Let’s get back to the task, that was simple — to implement a universal approach to executing Python code with a minimum number of external libraries.

🔧 Now, let’s delve into the implementation details.

* Project setup

To begin with, I created a maven project using the following command and the next versions of the tools:
✔ Maven 3.8.4
✔ Java 21.0.3-graal

mvn archetype:generate \
  -DarchetypeGroupId=org.graalvm.python \
  -DarchetypeArtifactId=graalpy-archetype-polyglot-app \
  -DarchetypeVersion=24.0.0

* Dependencies

To integrate Python code into our Java microservices, we utilized the following dependencies, ensuring seamless interaction between Java and Python through Graalpy:

<dependencies>
        <!--
            This dependency includes the necessary polyglot functionalities provided by GraalVM,
            allowing multiple languages to interoperate within the same JVM.
        -->
        <dependency>
            <groupId>org.graalvm.polyglot</groupId>
            <artifactId>${graalpy.edition}</artifactId>
            <version>${graalpy.version}</version>
            <type>pom</type>
        </dependency>

       <!--
            The polyglot library facilitates the execution of code from different programming languages
            in a single application. It provides the core API for embedding and running Python scripts
            within the Java environment.
        -->
        <dependency>
            <groupId>org.graalvm.polyglot</groupId>
            <artifactId>polyglot</artifactId>
            <version>${graalpy.version}</version>
        </dependency>
        <!--
            he python-launcher dependency includes the components needed to launch and manage Python scripts
            from a Java application. It handles the initialization and execution of Python code
            within the GraalVM environment.
        -->
        <dependency>
            <groupId>org.graalvm.python</groupId>
            <artifactId>python-launcher</artifactId>
            <version>${graalpy.version}</version>
        </dependency>
        <!--
            This library provides the necessary tools for embedding Python code directly into Java applications. 
            It ensures that the Python runtime is properly integrated and managed alongside the Java runtime.
        -->
        <dependency>
            <groupId>org.graalvm.python</groupId>
            <artifactId>python-embedding</artifactId>
            <version>${graalpy.version}</version>
        </dependency>
    </dependencies>

These dependencies collectively enable a seamless and efficient integration of Python functions into our Java microservices, leveraging the power of GraalVM for cross-language execution.

* Configuring the Graalpy Maven Plugin

To facilitate the integration of Python code in our Java microservices, we used the Graalpy Maven Plugin. This plugin simplifies the process of embedding Python packages and managing the Python runtime within a Java application. Below is the configuration we used:

<plugin>
    <groupId>org.graalvm.python</groupId>
    <artifactId>graalpy-maven-plugin</artifactId>
    <version>${graalpy.version}</version>
    <executions>
        <execution>
            <configuration>
                <packages>
                    <package>termcolor</package>
                </packages>
                <pythonHome>
                    <includes>
                        <include>.*</include>
                    </includes>
                    <excludes></excludes>
                </pythonHome>
            </configuration>
            <goals>
                <goal>process-graalpy-resources</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Key Configuration Elements

• Execution Configuration: This section configures how the plugin processes GraalPy resources:
• Packages: Specifies the Python packages to include. In this example, we include the termcolor package.
• Python Home Configuration: Defines the files and directories to include or exclude from the Python home. Here, all files are included (<include>.*</include>).
• Goals: Specifies the goal to execute, which in this case is process-graalpy-resources.

Using this configuration, the Graalpy Maven Plugin ensures that the necessary Python packages and runtime configurations are properly processed and embedded within the Java application, streamlining the integration process and reducing the complexity of managing separate Python service

Please be aware that most native extension packages do not provide precompiled binaries for GraalPy. Consequently, these packages will attempt to compile themselves on the user’s computer during installation.
Ensure that you have all necessary libraries and development tools installed beforehand.

The GraalVM team recommends using the Python Compatibility Checker as the first step to determine if a package is compatible with GraalPy.

* Implementing a Universal Approach with Reflection and Generics ⚙️

After setting up the project, let’s dive into the Java implementation. I’ve used reflection and generalization to create a universal approach for integrating Python functions. Here is a detailed guide on how to achieve this:

In our Java implementation, I defined several constants to manage paths and configurations efficiently. Here’s a breakdown of these constants and their usage:

//    This constant holds the string "python", representing the Python programming language.
//    It's used to specify the language context within the GraalVM.
    String PYTHON = "python";

//    This constant defines the prefix for the virtual environment (venv) directory.
//    It's used to specify the path where the Python virtual environment is located.
    String VENV_PREFIX = "/vfs/venv";

//    This constant sets the prefix for the home directory within the virtual file system (vfs).
//    It helps in organizing user-specific data.
    String HOME_PREFIX = "/vfs/home";

//    This constant defines the prefix for the project directory within the virtual file system.
//    It is used to structure project-specific files and resources.
    String PROJ_PREFIX = "/vfs/proj";

//    This constant retrieves the current user directory where the Java application is running.
//    It is dynamically set using System.getProperty("user.dir").
    String USER_DIR = System.getProperty("user.dir");

//    This constant retrieves the current user directory where the Java application is running.
//    It is dynamically set using System.getProperty("user.dir").
    String RESOURCES_PREFIX = USER_DIR + "/src/main/resources";

//    This constant creates the full path to the project resources directory by 
//    concatenating RESOURCES_PREFIX with PROJ_PREFIX.
    String PROJ_RESOURCES_PATH = RESOURCES_PREFIX + PROJ_PREFIX;

Python code located in the resources folder:

src/main/resources/
└── vfs
    └── proj

After building the project with Maven, the GraalPy plugin installs the specified packages and sets up the necessary directories, including home, venv, and other required subfolders/files.

target/classes/vfs
├── home
│   ├── lib-graalpython
│   │   ├── modules
│   │   └── patches
│   └── lib-python
│       └── 3
├── proj
└── venv
    ├── bin
    ├── include
    └── lib
        └── python3.10

The overall structure of the project is as follows:
12 directories

Let’s delve into the core implementation magic with an example of using Python code for a simplex algorithm 🧐.

The simplex method is a technique for solving linear programming models manually. It involves using slack vars, tables, and pivot variables to find the optimal solution to an optimization problem. Linear programming aims to achieve the best result (maximum or minimum) within given linear constraints. For more details, you can read these.

Simplex algorithm - Wikipedia

GraalVM exported the Python class to Java as our explicit interface with the Java side.
What does this mean in practice?

• optimize_service.py contains the class implementing the simplex method.
• OptimizeService.java defines the interface on the Java side, serving as a contract with the Python implementation.

[NOTES]
You need to carefully export the implication through the polyglot package (line 476 in the image)

What Did I Implement?

To realize this approach, I used the Reflection API along with a configured polyglot context and generics to achieve the following steps:

1. Configure Polyglot Context: Set up the GraalVM polyglot context to allow interoperability between Java and Python.
2. Retrieve Methods from Interface: Obtain a list of methods from the Java interface using reflection.
3. Verify Method Presence in Python Class: Check if the corresponding methods exist in the Python class.
4. Invoke Methods Dynamically: Utilize reflection to dynamically invoke these methods, ensuring a seamless integration between the Java interface and the Python implementation.
5. Leverage Generics: Implement generics to handle different input and output types, enhancing flexibility and type safety.

This implementation leverages the power of reflection, a configured polyglot context, and generics to bridge the gap between the Java interface and the Python class. It enables flexible and dynamic method invocation while ensuring type safety and seamless integration.

* Example usage simplex method from Python implementation:

* PythonExecutor

The PythonExecutor a class implements the evaluation logic for both parameterized and non-parameterized methods. This class can handle methods that return values as well as void methods using reflection's invokeMethod. Here's a technical breakdown:

• Method Invocation: It supports both methods with and without parameters.
• Handling Return Types: The methods in PythonExecutor can manage both void and non-void methods. For methods that return values, the result is processed and returned.
• Return Values Management: The methods return a Map containing the returnedType and result. For void methods, the result is represented as Optional.empty().
• Method mapValue return maps a polyglot value to a value with a given Java target type.

This approach ensures flexibility and type safety, allowing for dynamic method invocation and handling various method signatures seamlessly.

* PolyglotHelper

The PolyglotHelper the utility class to configure context, source and options for VirtualFileSystem and managing embedded resources such as project and home files.

* Real-world Impact

The benefits were immediate and significant. Deployment times were reduced since we no longer needed to deploy separate Python services. Our architecture became cleaner, with fewer moving parts and less maintenance overhead. Overall, the integration streamlined our workflow, allowing us to focus more on development and less on operational issues.

Lessons Learned

This experience taught me several valuable lessons:

1. Integration Simplicity: Tools like Graalpy can significantly simplify cross-language integration.
2. Performance Considerations: While the integration was smooth, monitoring performance is crucial to ensure it meets your application needs.
3. Documentation and Community Support: Leveraging well-documented tools with active community support can mitigate many integration challenges.
4. Ease of extension: If you need new functionality, add a Python implementation and a corresponding Java interface, and you can easily use it through the PythonExecutor

Conclusion

Integrating Python code into our Java microservices using GraalPy was a game-changer. It not only streamlined our deployment process but also reduced the complexity of our architecture. If you have faced similar challenges, I recommend you explore this approach. It could save you time and effort, just as it did for us.
If you are interested in my realization, you can see it on GitHub

Call to Action

Have you tried integrating different programming languages into your projects? Share your experiences and the best tips you have in the comments below!
If you enjoyed this article, follow me for more insights on software development and microservices.