Alternative approaches for Maps with primitive values

While profiling the current state of OpenPatrician I noted that there are maps that are quite memory intensive and they have primitive values. As the map cannot hold primitive values they need to be boxed into their corresponding object, which adds overhead. Therefore I asked about alternative approaches. To figure out what meets my requirement best I did a small benchmark of my own comparing some of the available collection libraries.

„Alternative approaches for Maps with primitive values“ weiterlesen

Documentation generation with the Compiler API

Documentation of code has a tendency to become obsolete quickly. For that reason most often the only documentation is the code itself and if you are lucky some JavaDoc that is more or less up to date. For that reason I already started some time ago to generate additional documentation by doing static code analysis on my OpenPatrician project. So far this was done mainly with the Reflection API and it was sufficient to figure out what Spring beans there are and where they are used.

The next documentation task was to figure out which class posts what event type on which EventBus and which class handles the event. Or more simple what are the Event producers and what are the Event consumers and mapping them to see how the event messages flow. As the publishing of the events (in the terminology of Guava EventBus ‚post‘) happens within a method, simple reflection will not yield the desired results. Therefore I turned to the Compiler API that can be found in the tools.jar. As that API is poorly documented by JavaDoc and there are not that many examples, I decided to write this post as a means to provide another example.

„Documentation generation with the Compiler API“ weiterlesen

Package private beans

Thinking about separation in my code the question of package private beans popped up. The general pattern here is to have interfaces defined. The implementing classes however are package private. Instances are generated through a factory. I looked around to find some documentation how this can be done with a Spring context, but found none, so here it is. Special interest is the Spring configuration with Java.

The package private beans are annotated and the classpath is scanned. These classes are discovered, as this basically involves reflection. The beans however cannot be instantiated in the configuration, as the beans are not visible in the package of the configuration class. This is where the factory comes in. The factory resides in the same package as the beans however is a public @Service and so is available in the application context.

I tried this out with two beans:

package ch.sahits.spring.bean.internal;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

import java.util.Random;

@Component
class PackagePrivateBean {
    @Autowired
    private Random rnd;

    public Random getRnd() {
        return rnd;
    }
}
package ch.sahits.spring.bean.internal;

import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;

@Component
@Scope(value = "prototype")
class PackagePrivatePrototype {
    private final int a;

    public PackagePrivatePrototype(int a) {
        this.a = a;
    }

    public int getA() {
        return a;
    }
}

The configuration looks like this:

 

package ch.sahits.spring;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

import java.util.Random;

@Configuration
@ComponentScan(basePackages = {"ch.sahits.spring.bean.internal"})
public class PackagePrivateSpringConfiguration {
    @Bean
    public Random rnd() {
        return new Random();
    }

}

The factory:

package ch.sahits.spring.bean.internal;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.stereotype.Service;

@Service
public class PackagePrivateBeanFactory {

    @Autowired
    private ApplicationContext context;

    public PackagePrivateBean getBean() {
        return context.getBean(PackagePrivateBean.class);
    }

    public PackagePrivatePrototype getBean(int i) {
        Object[] args = new Object[]{Integer.valueOf(i)};
        return (PackagePrivatePrototype)context.getBean("packagePrivatePrototype", args);
    }
}

I tested this with a Test-Case:

package ch.sahits.spring;

import ch.sahits.spring.bean.internal.PackagePrivateBeanFactory;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.support.AnnotationConfigContextLoader;

import static org.junit.Assert.assertNotNull;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes=PackagePrivateSpringConfiguration.class, loader=AnnotationConfigContextLoader.class)
public class PrivatePackageConfigurationTest {
    @Autowired
    private PackagePrivateBeanFactory factory;

    @Test
    public void factoryShouldNotBeNull() {
        assertNotNull(factory);
    }

    @Test
    public void packagePrivateComponentShouldNotBeNull() {
        Object o = factory.getBean();
        assertNotNull(o);
    }

    @Test
    public void packagePrivatePrototypeShouldNotBeNull() {
        Object o = factory.getBean(47);
        assertNotNull(o);
    }
}

The curious thing is that the PackagePrivateBean is by default of scope Singleton and thereby has to be created on application context startup. As this happens through reflection of the default constructor this is even possible even though the bean itself is not visible and can therefore not be defined through the configuration class. This is a case, where you get an instance through the package scan that cannot be done through explicit definition. This applies in the same manner for XML configuration. Defining a package private bean in XML would cause a runtime exception when reading the XML application context.