DEV Community: Efim Smykov

Using ArC outside Quarkus

Efim Smykov — Mon, 20 Mar 2023 09:30:00 +0000

What is ArC

ArC is build time oriented implementation of CDI 2.0 - Contexts and Dependency Injection specification. ArC created by Quarkus team and used for DI in Quarkus. In this topic we will try use it not in Quarkus application.

How to use it

Bean definition

Because ArC based on CDI, for defining beans we will use standard annotations @ApplicationScoped for defining bean and @Inject for injecting beans into each other. It will look something like this:


import javax.inject.Inject;
import javax.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class ServiceImpl implements Service {

    @Inject
    Service2 service2;

    @Override
    public void serve() {

    }

}

Bean processing

Entry point for processing beans is BeanProcessor. It can be created via builder. And then we can use method process, which will resolve beans and generate resources for fast application startup.

Implementation

Maven plugin

We will be using ArC in Maven application. To modify build process we need to create plugin. We need to have access to application .class files and all compile and runtime dependencies. It looks something like this:

package com.nutrymaco.arc.maven.plugin;

import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugins.annotations.LifecyclePhase;
import org.apache.maven.plugins.annotations.Mojo;
import org.apache.maven.plugins.annotations.Parameter;
import org.apache.maven.plugins.annotations.ResolutionScope;
import org.apache.maven.project.MavenProject;

@Mojo(name = "build", defaultPhase = LifecyclePhase.PACKAGE, requiresDependencyResolution = ResolutionScope.COMPILE_PLUS_RUNTIME, threadSafe = true)
public class BuildMojo extends AbstractMojo {

    @Parameter(defaultValue = "${project}", readonly = true, required = true)
    private MavenProject project;

    @Override
    public void execute() {
            // build logic
    }

}

Bean processing

BeanProcessor need index for all classes that needed our application. So we use Jandex for creating index of all classes.

Indexer indexer = new Indexer();

// add all .class files to index
indexJar(project.getArtifact().getFile(), indexer);

for (Artifact artifact : project.getArtifacts()) {
    indexJar(artifact.getFile(), indexer);
}

Index index = indexer.complete();

Then we can create BeanProcessor

BeanProcessor.builder()
    .setApplicationIndex(index)
    .setComputingBeanArchiveIndex(index)
    .setImmutableBeanArchiveIndex(index)
    .setGenerateSources(true)
    .setOutput(new JarResourceOutput(generatedJarCreator))
    .setTransformUnproxyableClasses(true)
    .build();

JarResourceOutput writes generated by ArC classes and service provider files into JAR

switch (resource.getType()) {
    case JAVA_CLASS:
        jar.addFile(
            target.resolve(resource.getName()) + ".class",
            resource.getData());
        break;
    case SERVICE_PROVIDER:
        jar.addFile(
            target.resolve("META-INF")
                  .resolve("services")
                  .resolve(resource.getName()).toString(),
            resource.getData());
        break;
    case JAVA_SOURCE:
        break;
}

Runtime

In main class we should initialize container and then we can request for beans.

public class AppMain {
    public static void main(String[] args) {
        var container = Arc.initialize();
        var service = container.select(Service.class);
        service.serve();
    }
}

Summary

As the result we add build time DI for our application. For that we created maven plugin in which we useBeanProcessor for processing bean definitions. Then in runtime we initialize container using Arc.initialize(). You can use it like this or use Quarkus to get more performance optimizations and features without extra actions like creating plugins.

Sidecar pattern use cases

Efim Smykov — Fri, 17 Mar 2023 09:30:00 +0000

Sidecar pattern use cases

Essence of pattern is that you have main container and sidecar container. They run on the same Pod, so they share networking and storage resources. Let’s discuss in what cases it can be useful.

Proxy server

Sidecar pattern behave like proxy for main container. It does not perform any business logic. For example, you can add HTTPS to your old service without changing service itself.

Dynamic configuration

Sidecar container acts like API for changing configuration. Service, in turn, should have some mechanism to fetch changes.

Reusable functionality

Sometimes it is useful to extract some common (more likely technical) service logic into separate container. You can implement, for example, resource monitoring service once and use it for all services, regardless technologies they based on.

Extending service API

You can implement new API in separate service and deploy it as sidecar. It is useful if:

you have not access to application sources
application based on legacy technologies
application sources are too legacy to try change it

Summary

Basically, Sidecar pattern is useful when you can’t modify container, but want to implement some new functionality or want to implement some reusable technology-agnostic functionality.

Why () -> {throw e} is more Supplier than Runnable

Efim Smykov — Sun, 12 Mar 2023 21:00:00 +0000

Recently, while writing test, I encountered enexpected (for myself) Java behaviour. In simplified form, the situation was as in the code below. I expected that the testRunnable would invoke run(Runnable) method, but instead run(Supplier) was invoked.

public void testRunnable() {
    run(() -> {
        throw new RuntimeException();
    });
}

public void run(Supplier<?> supplier) {
    supplier.get();
}

public void run(Runnable runnable) {
    runnable.run();
}

But it is not a bug, run(Supplier) was chosen because it has more specific signature. There is method for this - com.sun.tools.javac.comp.Resolve#signatureMoreSpecific. In simplified form it looks like code below.

boolean signatureMoreSpecific(Method m1, Method m2) {
  var methodInstance = instantiate(m2, m1.args)
  return methodInstance != null;
}

How this method works will be clearer with more obvious example. Let’s say we have method print(String) and print(Object). Then we try to instantiate print(Object) with String argument. Obviously it will be instantiated successfully. Then we try instantiate print(String) with Object argument. It will fail, because we can’t pass Object in method which consume String.

signatureMoreSpecific("print(String)", "print(Object)") 
    -> instantiate("print(Object)", "String") 
    -> success
    ->  true

signatureMoreSpecific("print(Object)", "print(String)") 
    -> instantiate("print(String)", "Object") 
    -> fail
    ->  false

So method signature is more specific if it can be passed into other method and signature of this method can’t be passed into first method.

Method mostSpecific(Method m1, Method m2) {
  boolean m1SignatureMoreSpecific = signatureMoreSpecific(m1, m2);  
  boolean m2SignatureMoreSpecfic = signatureMoreSpecific(m2, m1);
  if (m1SignatureMoreSpecific && m2SignatureMoreSpecific) {
    // …
  } 
  else if (m1SignatureMoreSpecific) return m1;
  else if (m2SignatureMoreSpecific) return m2;
  else throw e;
}

Static proxies in Quarkus

Efim Smykov — Sat, 11 Mar 2023 23:10:36 +0000

In previous post, Quarkus build process was described and how it helps to do DI in build time. In this post we discuss standard approaches for proxy creation and how Quarkus does it.

CDI and interceptors

All Quarkus applications use CDI - Contexts and Dependency Injection. It has annotation for declarative creating interceptor. As a result for target class creating proxy with interceptor logic. But how proxy is created depends on implementation.

How proxy can be created

First, let’s see example of interceptor. GreeterInterceptor - interceptor and WorkService, ServiceImpl, and FinalService - bean classes which will be proxied.

GreeterInterceptor interceptor - printing greeting from intercepted bean

@Greeter
@Interceptor
public class GreeterInterceptor {

    @AroundInvoke
    public Object greet(InvocationContext ctx) throws Exception {
        System.out.println("Hello from " + ctx.getTarget());
        return ctx.proceed();
    }

}

WorkService bean - not implementing any interfaces

@Singleton
public class WorkService {

    @Greeter
    public void serve() {
        System.out.println("I'm doing work");
    }

}

ServiceImpl bean - implement interface Service

@Singleton
public class ServiceImpl implements Service {

    @Greeter
    @Override
    public void serve() {
        System.out.println("I'm doing work");
    }

}

FinalService bean - not implementing interfaces, has final modifier

@Singleton
public final class FinalService {

    @Greeter
    public void serve() {
        System.out.println("I'm doing work");
    }

}

Dynamic proxy

Dynamic proxy is a proxy created at runtime. There is 2 way to do this: bytecode generation and Java Dynamic Proxy Class API.

Java Dynamic Proxy Class API

With this API you can create proxy via code like this

InvocationHandler handler = new MyInvocationHandler() {
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        // proxy logic
    }
}
Service f = (Service) Proxy.newProxyInstance(
                        Service.class.getClassLoader(),
                        new Class<?>[] { Service.class },
                        handler);

Main limitation of this API, that you can only create proxy for interfaces, so it can only be used for ServiceImpl bean in our examples.

Runtime bytecode generation

This approach can be implemented using bytecode generation libs such as cglib (but they do not support JDK17+) or ByteBuddy. With bytecode generation you can create proxy for WorkService and ServiceImpl from our examples. But bytecode generation can’t help if target class is final like FinalService.

Proxy creation in Quarkus

Unlike in cases described above Quarkus knows which class need proxy at build time. So bytecode for proxy can be generated at build time without wasting resources at runtime, so it called a static proxy.

Also Quarkus can modify bytecode of classes with final modifier, so they can be proxied. As a result Quarkus can create proxy for all our examples - WorkService (ordinary class), ServiceImpl (implementing interface) and FinalService (class with final modifier).

Summary

In this topic we discussed main approaches for creating proxy - bytecode generation and Java Dynamic Proxy Class API. Quarkus combines bytecode generation, bytecode transformation and knowledge about all classes to generate proxy at build time. Thereby giving better perfomance at runtime and possibility for creating proxy for final classes.

How Quarkus use build time to start your application faster

Efim Smykov — Tue, 28 Feb 2023 22:31:08 +0000

In this topic, we will try to undestand basics of how Quarkus augments application. We will cover how build process works, structure of resulted artifact and how it is launched.

What is Quarkus

Quarkus is framework for Java (primary) and Kotlin with focus on the cloud development.

What are benefits of Quarkus

Quick startup
Low memory consumption
Build time DI resolution

How Quarkus build application

At build time (also referred to as deployment time), Quarkus does most of the work. Let's establish the basics of how Quarkus builds our application.

Quarkus application build flow

Once all application classes are compiled, Quarkus build starts. During bootstrap, it prepares for the build, e.g. resolves all application dependencies. Next, Quarkus performs deployment (build) and produces an artifact. Let's take a closer look at each step related to Quarkus.

Bootstrap phase

Before run build Quarkus does:

Resolve application dependencies.
Build build chain.
Produce initial build items into build chain.

Core build components

Build process consists from two basic blocks build step and build item.

Build item

They can be:

initial and non-initial
simple and multi

Initial Build Items

Initial build items are created and passed to the build chain by Quarkus and cannot be produced by build steps.
For example, the LaunchModeBuildItem indicates the launch type, such as production, development, or testing.

Simple build item

Can only be produced in one instance (and by only one build step)
For example, the CombinedIndexBuildItem contains index, which build from the application classes and dependencies that contain a certain marker file.

Multi build item

Can be produced any amount of time by any amount of build steps
For example, the AdditionalBeanBuildItem is produced by extensions to dynamically specify a bean.

Build step

Method with @BuildStep annotation.
Consume build items.
Produce build items by returning a value from a method or using BuildProducer<BuildItem>
Can be recorded and invoked at application startup.

Build step recording

The build step recording process works as follows:

A proxy is created for the recorder passed in method using an InvocationHandler
The proxy records all invocation information.
Also proxy is created for all returned values from the invoked methods.
Bytecode to be invoked at application startup is recorded based on the information gathered by the proxies.
Recorded bytecode produced as StaticBytecodeRecorderBuildItem or MainBytecodeRecorderBuildItem and collected in MainClassBuildStep where runner class is generated.

InvocationHandler dummy implementation:



new InvocationHandler() {


  @Override

  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

    // do something on method invocation

  }

}

(Simplified) Build process

Build chain model

The resulting build chain can be represented as an oriented graph, with build items and build steps as nodes. Quarkus determines which build steps do not depend on any other build steps and starts their execution. After they have finished, it counts down the counter at the dependent build steps; if the counter equals 0, they start execution. All executions are done in parallel.

Pre DI build phase

This scheme illustrates how Quarkus collects bean archives for dependency injection (DI). The process begins by collecting all archives, regardless of whether they contain beans or not. Next, Quarkus selects the bean archives from the collected archives.

Initially, collect all application classes. In case of a multi-module application, only classes in the main application module are indexed at this step, while others are treated as dependencies.

Next, the ApplicationArchiveBuildStep processes all application dependencies. Dependencies are indexed if they meet at least one of the following criteria:

Dependency contains one of the specified marker files, such as META-INF/jandex.idx or META-INF/beans.xml. Additional marker files can be specified using the AdditionalApplicationArchiveMarkerBuildItem
Dependency is included in one of the produced IndexDependencyBuildItem
Dependency is included in one of the initial AdditionalApplicationArchiveBuildItem build items, which cannot be produced by the user.

Also Quarkus index all classes specified in AdditionalIndexedClassBuildItem

These archives combined into CombinedIndexBuildItem, which consumed by BeanArchiveProcessor

Then BeanArchiveProcessor create bean archives index. Archive is treated as a bean archive if it meets at least one of the following criteria:

Archive contains META-INF/beans.xml
Archive contains at least one class with bean defining annotation, for example @ApplicationScoped
Archive specified as bean archive in BeanArchivePredicateBuildItem

DI build phase

During build time, Quarkus performs the following tasks:

Resolves all injection points.
Generates static proxies for beans to avoid reflection.
Generates bytecode to set up DI at application startup.

Create artifact phase

Result artifact generated in JarResultBuildStep. Quarkus has several artifact formats. For JVM default and recommended is fast-jar. It has followed structure.

How Quarkus starts application

Quarkus offers several launch modes, but here we will focus only on the production mode.

To start the application in production mode, launch the target/quarkus-app/quarkus-run.jar JAR. The QuarkusEntryPoint main class will be loaded from lib/boot/

The next step is for QuarkusEntryPoint to read the quarkus-application.dat file, from which it creates the RunnerClassLoader, the class loader for the Quarkus application. Using the information from quarkus-application.dat, the RunnerClassLoader will attempt to load a class from the parent class loader (JVM class loader) or from indexed jars, which is faster than the JVM class loader.

Then, the generated ApplicationImpl runs, where the static block contains static recordings, and the start method contains runtime recordings. It looks something like this:



// $FF: synthetic class

public class ApplicationImpl extends Application {

  static Logger LOG;

  public static StartupContext STARTUP_CONTEXT;

public ApplicationImpl() {

    super(false);

  }

static {

  // invoke static recordings

  }

protected final void doStart(String[] var1) {

    // invoke runtime recordings

  }

protected final void doStop() {

    STARTUP_CONTEXT.close();

  }

public String getName() {

    return "simple-app";

  }

}

Summary

We covered class indexing, build-time preparation for dependency injection, artifact structure, and application startup. While there are other important topics such as native executable creation, more advanced overview of dependency injection, and server implementation, it would be best to address them separately.