Orika (formerly hosted at google code) claims to be a simpler, lighter and faster Java bean mapping. And it really is.

It allows you to convert objects by copying its attributes from one to another. It performs this by using Java introspection, instead of XML configuration or something like that. It uses code generation to create the mappers, and it has an interesting strategy for its core classes that allows you to optimize the performance.

It is completely configurable, for instance, the java code generator by default is Javassist, but you can use EclipseJdt or even use another provider by implementing the appropriate interface.

Finally, it’s a very well documented project, with clear explanations and useful code.

I really like it.

If you want to try it, just add the next dependency to your maven project:

<dependency>
			<groupId>ma.glasnost.orika</groupId>
			<artifactId>orika-core</artifactId>
			<version>1.4.5</version><!-- or latest version -->
		</dependency>

Or download the library along with three required libraries:

• javassist (v 3.12.0+)
• slf4j (v 1.5.6+)
• paranamer (v 2.0+)

Main concepts

There are two core classes, the first one is MapperFactory, the class to configure the mappings and to obtain the second core class: MapperFacade, that actually provides the service of a Java bean mapping.

MapperFactory

By using a fluent API, you can construct a MapperFactory via its main implementation, DefaultMapperFactory and its static class helpers intended for building the MapperFactory.

Then you can obtain a ClassMapBuilder from the MapperFactory in order to declare the mapping configuration in a fluent-style, that is: mapping fields (bi-directional by default, or in one direction if you’d rather), excluding fields, specifying constructors and customizing mappings of Lists, Sets, nested fields and so on.

There is a default mapping that maps fields with matching names between two classes, and you can also register the mapping in the MapperFactory (the ClassMapBuilder is built with the very MapperFactory as atribute). Both operations have the appropriate methods to be called.

Let’s see an example:

We have two classes: PersonDTO and Person, and we want to convert one object for the former class to an object of the latter one, so let’s configure the MapperFactory:

MapperFactory mapperFactory = new DefaultMapperFactory.Builder().build();
mapperFactory.classMap(PersonDTO.class, Person.class) //A ClassMapBuilder<PersonDTO, Person>
        .field("lastNames", "surnames") //Register field mappings
        .field("streetAddress", "address.street")
        .field("city", "address.city")
        .field("postalCode", "address.zipCode")
        .byDefault() //the remaining fields on both classes should be mapped matching the fields by name
        .register(); //register the mapping with the MapperFactory.

The ClassMapBuilder provides interesting mappings for excluding fields, mapping fields in one direction only (as I mentioned above, mapping is by default bi-directional) and so on. See the Declarative Mapping Configuration and Advanced Mapping Configurations for more options.

MapperFacade and BoundMapperFacade

The MapperFacade performs the actual mapping work, for doing so, you have to obtain the MapperFacade from the MapperFactory and then use its map methods. There are two general options, map(objectA, B.class), which will create a new instance of B.class and map the property values of objectA onto it, or map(objectA, objectB), which copies properties from objectA onto objectB, being both of them not null.

Let’s see an example:

MapperFacade mapper = mapperFactory.getMapperFacade();
PersonDTO personDTO = new PersonDTO();
//Set values here
Person person = mapper.map(personDTO, Person.class);
//Alternatively:
//Person person = new Person();
//mapper.map(personDTO, person);

The BoundMapperFacade is intended to be used with a pair of types to map and no further customization needed. It provides improved performance over use of the standard MapperFacade and it has the same usage plus a mapReverse method for mapping in the reverse direction.

See below an example:

BoundMapperFacade<PersonDTO, Person> boundMapper = mapperFactory.getMapperFacade(PersonDTO.class, Person.class);
PersonDTO personDTO = new PersonDTO();
//Set values here
Person person = boundMapper.map(personDTO);
//Alternatively:
//Person person = new Person();
//boundMapper.map(personDTO, person);
//Map in the reverse
PersonDTO personDTO = boundMapper.mapReverse(person);
//Alternatively with no null objects:
//boundMapper.mapReverse(person, personDTO); //curiously, it returns an A object instead of void

If you’re primarily concerned with the mapping of a particular type to another, and your object graph has no cycles, use BoundMapperFacade because it has better performance, since you avoid the overhead of looking up an appropriate mapping strategy for the fields of the objects to be mapped, that happens when you call the map method.

Performance

The most expensive operations are instantiation and initialization of the MapperFactory, and the MapperFacade which is obtained from it.

Both of them are thread-safe objects, thus singletons or static access for them are a very recommended approach.

For instance, you can consider an static acces to the MapperFactory:

package com.malsolo.orika.test.domain.mappers;

import ma.glasnost.orika.MapperFactory;
import ma.glasnost.orika.impl.DefaultMapperFactory;

public class BaseMapper {
    final static MapperFactory MAPPER_FACTORY = new DefaultMapperFactory.Builder().build();
}

And then use this class for registering class maps and access to the MapperFacade in a customize way:

package com.malsolo.orika.test.domain.mappers;

import com.malsolo.orika.test.domain.Customer;
import com.malsolo.orika.test.dto.CustomerDTO;
import ma.glasnost.orika.MapperFacade;

public enum CustomerMapper {
    
    INSTANCE;
    
    private final MapperFacade mapperFacade;
    
    private CustomerMapper() {
        BaseMapper.MAPPER_FACTORY.classMap(CustomerDTO.class, Customer.class)
                .byDefault()
                .register();
        mapperFacade = BaseMapper.MAPPER_FACTORY.getMapperFacade();
    }
    
    public Customer map(CustomerDTO customerDTO) {
        return this.mapperFacade.map(customerDTO, Customer.class);
    }
    
    public CustomerDTO map(Customer customer) {
        return this.mapperFacade.map(customer, CustomerDTO.class);
    }
}

In this case I’m using two new classes: Customer and CustomerDTO.

Finally, just use this helper classes:

CustomerDTO customerDTO = new CustomerDTO();
//Setters at will
Customer customer = CustomerMapper.INSTANCE.map(customerDTO);

How it works and Customization

The best way to understand how Orika works is to read the FAQ, but the source code is very clear and easy to follow, just in case you want to take a deeper look to the details.

“Orika uses reflection to investigate the metadata of the objects to be mapped and then generates byte-code at runtime which is used to map those classes […]”

“Orika mapping is configured via Java code at runtime, via a fluent-style ClassMapBuilder API. An instance is obtained from a MapperFactory which is then used to describe the mapping from one type to another. Finally, the specified ClassMap is registered with the MapperFactory for later use in generating a byte-code mapper.”

To configure Orika, the author recommends to extend the ConfigurableMapper class, and I will use this approach for using Orika with Spring (see below)

If you want to configure the code generation, compilation and so on, see how to do this using the MapperFactory in the next topic.

MapperFactory Configuration

The core class MapperFactory is instantiated as you’ve seen above, by building the provided implementation: DefaultMapperFactory. It uses a set of Strategy and factory objects for resolving constructors, for compiling code (actually, they belong to its inner static class MapperFactoryBuilder that is extended by its other inner static class that you use to instantiate the MapperFactory: the Builder), for resolving properties, and specially for building class maps.

So you can customize all of them after calling Builder() and before the build() method:

new DefaultMapperFactory.Builder()
.constructorResolverStrategy(new SimpleConstructorResolverStrategy()) //By default, you can extend it or implement your own ConstructorResolverStrategy
.compilerStrategy(new JavassistCompilerStrategy()) //By default, you can extend it, implement your own CompilerStrategy or use EclipseJdtCompilerStrategy
.propertyResolverStrategy(new IntrospectorPropertyResolver()) //By default, you can extend it or implement your own PropertyResolverStrategy
.classMapBuilderFactory(new ClassMapBuilder.Factory()) //by default. You can use //enabled by default or //enabled by default.Factory
.useAutoMapping(true) //enabled by default
.mapNulls(true) //enabled by default
.build();

Custom Mappers

A Mapper<A, B> copies the properties from one object onto another and it’s used internally by Orika (MapperFacade, MapperGenerator and MapperFactory use it, but it isn’t really interesting for this post, actually)

If you want to take control of how properties of one object instance are copied to another object instance (not null), just extends the abstract class CustomMapper<A,B>.

Then, you can register your custom mapper in the MapperFactory via its method registerMapper(Mapper<A, B> mapper).

It’s intended to be used when the mapping behavior configured via the ClassMapBuilder API doesn’t suit your purposes, but only to copy properties, that is, the destination object already exists. If you want to control instantiation, use a CustomConverter or ObjectFactory which both return an instance. See below.

If you need to map nested members of the given object, you can doing so by using the current MapperFacade that it’s accessible via a protected mapperFacade variable.

I’ve used converters in a Spring applications as components that can be scanned and used to configure the MapperFactory by extending ConfigurableMapper as I mentioned above and I’ll show below.

Object Factories

An ObjectFactory<D> instantiates objects. You can implement this interface and register your implementation in the MapperFactory via their method registerObjectFactory (there are a couple of them)

I’ve never used this option.

Custom Converters

A Converter<S, D> combines both ObjectFactory and Mapper together, returning a new instance of the destination type with all properties copied from the source instance.

When you want to take complete control over the instantiation and mapping, just extend CustomConverter<S, D> to create the new instance and to provide it the properties from the source object.

Then, you can register your custom converter in the MapperFactory by obtaining its ConverterFactory via the getConverterFactory() method and then using one of its registerConverter() methods.

I’ve found this option useful when you want to create some hard conversion between classes that has the same meaning in your code but are not really related in terms of Java. Well, it’s a conversion, let’s say, from a date represented in a String and a date that has to be a Calendar. You have to use some formatter for doing so.

It’s also very easy to configure converters as Spring components if you need so.

Using Orika with Spring

Since the Orika core classes MapperFactory and the MapperFacade obtained from it are very expensive to instantiate and initialize, but at the same time are thread-safe, they should be shared as singletons. That is, they are good candidates for being Spring beans with singleton scope.

Let’s start with using spring-framework in a maven project,just add the next dependency to the pom.xml file:

<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-context</artifactId>
			<version>4.1.1.RELEASE</version><!-- or latest version -->
		</dependency>

The Spring application

Let’s create a couple of beans to obtain a Person and a PersonDTO, let’s call them service and repository respectively:

package com.malsolo.orika.test.spring;

import com.malsolo.orika.test.domain.Person;

public interface PersonService {
    
    public Person obtainPerson();
    
}

package com.malsolo.orika.test.spring;

import com.malsolo.orika.test.dto.PersonDTO;

public interface PersonRepository {
    
    public PersonDTO obtainPerson();

}

And their implementations, the one for the service will use the repository interface, and the one for the repository will be a simple in-memory implementation.

package com.malsolo.orika.test.spring;

import com.google.common.collect.ImmutableList;
import com.malsolo.orika.test.dto.PersonDTO;
import java.util.Random;
import org.springframework.stereotype.Repository;

@Repository
public class PersonRepositoryImpl implements PersonRepository {
    
    Random random = new Random();

    @Override
    public PersonDTO findPerson() {
        return this.createPersonDTO(random.nextLong());
    }

    private PersonDTO createPersonDTO(long l) {
        PersonDTO dto = new PersonDTO();
        dto.setId(l);
        //More setters here
        return dto;
    }
}

Note that the service will need to convert from the DTO to the domain object, so let’s inject a mapper.

package com.malsolo.orika.test.spring;

import com.malsolo.orika.test.domain.Person;
import ma.glasnost.orika.MapperFacade;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class PersonServiceImpl implements PersonService {
    
    @Autowired
    private PersonRepository personRepository;
    
    private MapperFacade mapper;

    @Autowired
    public void setMapperFactory(MapperFactory mapperFactory) {
        this.mapper = mapperFactory.getMapperFacade();
    }
    
    @Override
    public Person obtainPerson() {
        return mapper.map(this.personRepository.findPerson(), Person.class);
    }

}

As you can see, I used setter injection (via autowiring) to provide a MapperFactory in order to obtain from it a MapperFacade. I’m using the suggestion of having the MapperFactory as singleton, that it’s easy to achieve with Spring.

Since MapperFactory has a particular way to be instantiated, the best option is to create a factory for exposing it, a FactoryBean:

package com.malsolo.orika.test.spring;

import ma.glasnost.orika.MapperFactory;
import ma.glasnost.orika.impl.DefaultMapperFactory;
import org.springframework.beans.factory.FactoryBean;
import org.springframework.stereotype.Component;

@Component
public class MapperFactoryFactory implements FactoryBean<MapperFactory> {

    @Override
    public MapperFactory getObject() throws Exception {
        return new DefaultMapperFactory.Builder().build();
    }

    @Override
    public Class<?> getObjectType() {
        return MapperFactory.class;
    }

    @Override
    public boolean isSingleton() {
        return true;
    }

}

This approach has been selected just in case I want to use a BoundMapperFacade, but it’s possible to use a MapperFacade directly by creating a MapperFacadeFactory.

Now, let’s configure the Spring application

package com.malsolo.orika.test.spring;

import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

@Configuration
@ComponentScan
public class OrikaSpringTest {
    
    public static void main(String... args) {
        ApplicationContext context = 
          new AnnotationConfigApplicationContext(OrikaSpringTest.class);
        PersonService personService = context.getBean(PersonService.class);
        Person person = personService.obtainPerson();
        System.out.printf("%s\n", person.toString());
    }

}

This is enough for the project to run:

Person{id=0, name=Name 0, surnames=null, address=null}

But pay attention, the mapper didn’t work, because there are differences between the two classes (tow attributes with different names, and the same concept, address, with different types)

Plugging in Orika Mappers and Converters with Spring

Orika provides custom converters and mappers, so the only thing we need is to configure them as spring beans in the application context. Let’s see how to do this.

First, we need a custom mapper. We annotate it as component to be discovered (via component scanning) by Spring.

package com.malsolo.orika.test.spring;

import com.malsolo.orika.test.domain.Address;
import com.malsolo.orika.test.domain.Person;
import com.malsolo.orika.test.dto.PersonDTO;
import ma.glasnost.orika.CustomMapper;
import ma.glasnost.orika.MappingContext;
import org.springframework.stereotype.Component;

@Component
public class PersonDtoToPersonMapper extends CustomMapper<PersonDTO, Person> {

    @Override
    public void mapAtoB(PersonDTO a, Person b, MappingContext context) {
        b.setId(a.getId());
        b.setName(a.getName());
        b.setSurnames(a.getLastNames());
        //I could use the protected mapperFacade if I need to map a particular field
        //this.mapperFacade.map(sourceObject, destinationClass);
        Address address = new Address();
        address.setStreet(a.getStreetAddress());
        address.setCity(a.getCity());
        address.setZipCode(a.getPostalCode());
        b.setAddress(address);
    }

    @Override
    public void mapBtoA(Person b, PersonDTO a, MappingContext context) {
        a.setId(b.getId());
        a.setName(b.getName());
        a.setLastNames(b.getSurnames());
        Address address = b.getAddress();
        if (address != null) {
            a.setStreetAddress(address.getStreet());
            a.setCity(address.getCity());
            a.setPostalCode(address.getZipCode());
        }
    }

}

Finally, we have to plug in mappers and converters that belongs to the Spring application context, into the MapperFactory. If we extend ConfigurableMapper we will have a MapperFactory created for us, and later on, the chance to access the application context itself to look up for the custom mappers and converters that are Spring components to register them in the MapperFactory.

Let’s show the code:

package com.malsolo.orika.test.spring;

import java.util.Map;
import ma.glasnost.orika.Converter;
import ma.glasnost.orika.Mapper;
import ma.glasnost.orika.MapperFactory;
import ma.glasnost.orika.impl.ConfigurableMapper;

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

@Component
public class SpringConfigurableMapper extends ConfigurableMapper {

    private ApplicationContext applicationContext;

    private MapperFactory mapperFactory;

    @Autowired
    public void setApplicationContext(ApplicationContext applicationContext) {
        this.applicationContext = applicationContext;
        addSpringMappers();
        addSpringConverter();
    }

    @Override
    protected void configure(MapperFactory factory) {
        super.configure(factory);
        this.mapperFactory = factory;
    }

    private void addSpringMappers() {
        @SuppressWarnings("rawtypes")
        final Map<String, Mapper> mappers = applicationContext
                .getBeansOfType(Mapper.class);
        for (final Mapper<?, ?> mapper : mappers.values()) {
            addMapper(mapper);
        }
    }

    private void addMapper(Mapper<?, ?> mapper) {
        this.mapperFactory.registerMapper(mapper);
    }

    private void addSpringConverter() {
        @SuppressWarnings("rawtypes")
		final Map<String, Converter> converters = applicationContext
                .getBeansOfType(Converter.class);
        for (final Converter<?, ?> converter : converters.values()) {
            addConverter(converter);
        }
    }

    private void addConverter(Converter<?, ?> converter) {
        this.mapperFactory.getConverterFactory().registerConverter(converter);
    }

}

Some important things to note here:

• Our class SpringConfigurableMapper is a @Component

When Spring instantiates it, it will call its constructor that is inherited from ConfigurableMapper and it calls an init method that creates a MapperFactory and allows you to configure via the overriden method.

So, the first method called is configure(MapperFactory).

Furthermore, don’t create your own MapperFactory as I did above, because it won’t be the one you’ll use to register the mappers and converters, on the contrary, this class will create a new MapperFactory.

• Our class SpringConfigurableMapper has the ApplicationContext @Autowired

It’s the same as if you implement ApplicationContextAware, but I’d rather this approach.

Besides, it implies that the method will be called after all the beans have been created. Since you already have a MapperFactory, you can then search for custom components and converters that are spring beans and register them in the MapperFactory.

• Our class extends ConfigurableMapper that implements MapperFacade

So, you have to slightly change the PersonServiceImpl and it’s better to not have a MapperFacadeFactory or you will have an autowiring exception because there would be two beans of the MapperFacade class:

package com.malsolo.orika.test.spring;

import ma.glasnost.orika.MapperFacade;

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

import com.malsolo.orika.test.domain.Person;

@Service
public class PersonServiceImpl implements PersonService {
    
    @Autowired
    private PersonRepository personRepository;
    
    @Autowired
    private MapperFacade mapper;

    @Override
    public Person obtainPerson() {
        return mapper.map(this.personRepository.findPerson(), Person.class);
    }

}

Now, if you run the Orika with Spring main class, OrikaSpringTest, everything will run as expected:

Person{id=85, name=Name 85, surnames=[S., Surname 85], address=Address{street=My street 85, city=City 85, zipCode=code 85}}

Resources

• Source code for this post
• Orika User Guide
• Orika and Spring Framework = easy bean mapping by Ken Blair
• Spring Framework Quick Start
• Spring Framework Reference Documentation (Meatier examples)
]]> http://malsolo.com/blog4java/?feed=rss2&p=465 1 http://malsolo.com/blog4java/?p=228 http://malsolo.com/blog4java/?p=228#comments Fri, 08 Aug 2014 12:52:45 +0000 http://malsolo.com/blog4java/?p=228 Continue reading →]]> Not only for fun. It’s also to open my mind.

Introduction

Since a few years ago, I try to use several OS in order to improve my computing skills: Windows 7/Vista, OS X (Lion currently) and my favorite Linux distribution, Ubuntu (Sheldon Cooper dixit). You can also include Android (my wife’s smartphone) and iOS (my iPhone and our iPad)

Suddenly, I realize that I’ve been enriched, and you’re able to do a lot of more things because you have your mind really prepared for thinking instead of conditioned by a single line of sight.

I observed the same improvement when I began to use Maven for Java development. I didn’t quit my IDE, but regarding compilation, the important things are the source code and bytecode. You shouldn’t think about settings, preferences, project configuration and some other artificial stuff that the IDE needs, but that is not your concern.

So I’ve decided to try the 3 most popular IDEs for Java currently available.

Context

During the last 2 months, I’ve been changing between projects I work in more quickly than I used to be accustomed, and that has allowed me to choose the IDE for working.

The title says it’s been for fun, but I’m using them in professional environment. Besides, the goal is not to decide which is better (it’s hard to be that rude with the others) or worst (well, it seems it’s an easy decision, because the worst Java IDE is JDeveloper, doubtless). What I want to find out is which of them is more productive for me.

Let’s see the first impressions.

Eclipse

Actually I don’t use Eclipse, but Spring Tool Suite, “an Eclipse-based development environment that is customized for developing Spring applications”. You know, Eclipse on Spring steroids.

I’ve been using Eclipse as my main IDE for years, even before it was released (Visual Age for Java was the IDE that I used in my first professional project). Thus, I’m very used to writing programs with Eclipse.

The version that I’m currently using is 3.6.0, that is based on Eclipse 4.4 (Luna)

Let’s summarize my first impressions:

Pros:

• It comes in a compressed file, no native installer. That allows me to place the program in the same location on every OS (in my case, an Application folder within my user home)
• The shortcut keys
• Typing assistant. I love to type “main” and have an entire main method written, or “sysout” and obtain a complete log sentence.
• The view and the perspectives is the most interesting way of organizing the IDE

Cons:

• It crashes from time to time. Annoying.
• It seems to consume a lot of memory
• The TC server that it includes is based on Tomcat 7, so it doesn’t recognize Servlet 3.1 projects
• A custom way of building code. No native support for tools like maven, gradle or ant. There are appropriate plugins, but having to update Eclipse projects to reflect maven changes is somewhat annoying
• On Ubuntu and on OS X, the icon in the Docker runs the previously installed 3.5.1 version. Maybe is the OS fault, due to the lack of installation.

NetBeans

I’m talking about NetBeans 8.0.

It’s hard for me to evaluate Eclipse, because it is the IDE that I use on a daily basis since a long years ago.

On the other hand, it’s very easy to describe the first impressions with NetBeans.

The installer works fine and the application runs smoothly, but I miss the way Eclipse are organized and its shortcuts (delete line: Ctrl/Cmd+D vs Ctrl/Cmd+E)

However NetBeans is likely the best among the three IDEs (not so hard to decide, apparently)

I got used to NetBeans in a few hours. Yes, hours. NetBeans has the more natural appearance for programming.

Actually, it includes all the options that Eclipse has, but sometimes with different key combination.

Besides, NetBeans is pure Java using external tools for compiling (maven, for instance)

Furthermore, it comes with Tomcat and GlassFish and a several of useful tools easy to configure with pluggins.

Does it have flaws? Of course, sometimes it get locked in a long wait operation and you can do nothing but wait.

Another tricky issue is that it uses an external tool to compile, maven for instance, so the program doesn’t exist until the project is built and neither you have the dependencies until maven downloads them. But worst than that is, if you compile successfully, but later on you introduce a compilation error, when you execute again, it runs the previously compiled version, because the current can’t be compiled due to the error.

Eclipse shows you an alert if there are compilation errors in your project before executing it.

IntelliJ IDEA

I’m sure that this is the best IDE ever, it seems so, but it makes me a little bit unproductive.

Eclipse is some kind of a de facto standard, and NetBeans is an easy to use program. But thanks to IntelliJ IDEA 13.1, the JetBrains Web Help has been the most visited page this week.

Besides, I don’t know what is doing the IDE. I don’t know whether the files are saved automatically, I don’t know when compilation is performed, and so on.

The worst thing in my humble opinion is that it doesn’t have any application server in the community edition. Please, at least Tomcat. But it has not.

Regarding shortcuts, it uses Ctrl/Cmd+Y for deleting lines, seriously?, the universal shortcut for “redo”? Yepes. And the rest of shortcut keys are really hard to do (Ctrl+F4 for closing a file)

I will try it later again, but currently it’s not my preferred choice.

However, once you discover how to use it, it’s the one that runs better. It seems not consume a lot of memory and it never blocks nor has crashes.

On Ubuntu, I have to start it via command line.

Summary

Of course the three programs are very good IDEs, but one by one:

• I feel a little bit lost with IntelliJ IDEA. It’s great but it’s hard to find the standard options.
• I love Eclipse and its shortcut keys, and I don’t care its flaws because I’m used to them after all these years. It will be my preferred IDE for a while, but NetBeans is now here.
• I didn’t like NetBeans, but the version 8 is a great program. It doesn’t matter if you haven’t use it before, is a very natural program. It makes Java development the way it has to be. Now I like it a lot.

Some final words: they are all very good and easy to use for Java debugging. And I’m glad now I can use any of them if I had to.

An alternative for short projects is a text editor (Sublime Text, for instance) and a good build tool (maven or gradle, as you wish)

I have to try Web Based IDEs, as Alexander J Turner suggested.

That’s all for now.

]]> http://malsolo.com/blog4java/?feed=rss2&p=228 2 http://malsolo.com/blog4java/?p=198 http://malsolo.com/blog4java/?p=198#comments Wed, 23 Jul 2014 11:36:44 +0000 http://malsolo.com/blog4java/?p=198 Continue reading →]]> Liferay, Alfresco, Activiti, BPM, BPMN, ECM.

Liferay Portal is a Java-based open source portal. A portal is generally defined as a software platform for building websites and web applications, with features for building the views and accessing data repositories. It is used also for Web Content Management System (accesing documents), and as a platform for collaboration or social interaction.

Alfresco is a Enterprise Content Manager (ECM), that is, a software for Document Management, Collaboration (external access to the documents), Process Management (definition of process) and more.

Activiti BPM Platform is a Java light-weight workflow and Business Process Management (Business Process ManagementBPM) Platform with a BPMN 2process engine. It’s open-source and distributed under the Apache license.

Business Process ManagementBusiness process management (Business Process ManagementBPM) is a management discipline for defining process of an organization with the goal of optimization. In practice, Business Process Model and Notation (BPMN) is used for provide a graphical representation of the business processes in a business process model (Business Process ManagementBPM).

]]> http://malsolo.com/blog4java/?feed=rss2&p=198 0 http://malsolo.com/blog4java/?p=195 http://malsolo.com/blog4java/?p=195#comments Wed, 23 Jul 2014 11:02:35 +0000 http://malsolo.com/blog4java/?p=195 Continue reading →]]> Vert.x, C10k problem, Node.js, MongoDB.

Vert.x is a application platform, that claims to be lightweight and high performance, and it’s for the JVM. To summarize, is a Java (and JavaScript, CoffeeScript, Ruby, Python or Groovy) Async I/O platform.

Node.js is a platform built on Chrome’s JavaScript runtime. Once again, event-driven, non-blocking I/O model.

Both of them are intended for solving the C10k problem.

For doing so, they follow the Reactor Pattern. It consists in an event loop that waits for Events that are handle concurrently by delivering these events to the appropriate service handler.

The main differences between Vert.x and Node.js is that the former has several threads as event loops (one per core) and the latter has one thread only, besides, Vert.x has special components (called Worker Verticles) for writing blocking code (long-lived computationally intensive operation, calling third party components, as JDBC queries), so that you can avoid to block the event loop.

C10K problem is the problem of having to handle suddenly a thousand of clients at the same time with a server that has to handle only several requests as its normal task (I mean, it’s a huge waste to configure this server for an average of thousands of connections only for occasional peaks)

MongoDB is an open-source document database, NoSQL database. It claims to provide high performanc (fast reads and writes), high availability (with replicated servers), and easy scalability (with automatic sharding among the servers).

]]> http://malsolo.com/blog4java/?feed=rss2&p=195 0 http://malsolo.com/blog4java/?p=79 http://malsolo.com/blog4java/?p=79#comments Fri, 18 Jul 2014 08:28:22 +0000 http://malsolo.com/blog4java/?p=79 Continue reading →]]> A friend of mine has requested me some help for improving his skills in Java EE and Spring Framework.

An exciting question, indeed.

The general context

He’s working for a company since 2008. To work for a company for a long time has a lot of pros, but a couple of drawbacks, being one of them a little bit worrying: the chance of obsolescence.

If you’re using the same environment along the years, let’s say IBM products, you’ll loose the chance to discover other approaches, for instance Oracle solutions, or even better, open source projects.

Even worst, if the company are not willing to upgrade their products (that is very reasonable if there are budget concerns) or their libraries (that is really unwise, or the direct consequence that you don’t have a good testing process) suddenly you find yourself that you’re out of the market.

This is not really a problem as long as your current technology is the best technology for your needs, but sooner or later you have to face to the technical debt (a really interesting topic that you should care about). This day will happen when you’re spending more time in fixing issues than in adding new features to your software.

The problem continues if you try to reinventing the wheel or if you don’t realize that the plane is already invented. It’s 21st century, you can fly with the appropriate machine.

The particular concern

As I said at the beginning of this entry, he is a Java EE developer that uses Spring Framework in his daily work. But he still has to program for WebSphere Application Server 6.1 (a.k.a. WAS 6.1, that is Java EE 1.4 compliance using Java 5 SE) using Spring framework 3 (2.5 for some projects)

At the time of this writing, Java EE 7 is already released and the current version of Spring Framework is 4.0.6. Not mentioning that Java 8 is now with us.

Thus, he wants to get up to date for improving the way he writes code that will be profitable for the company he works for.

I appreciate his request, because I’ll have to review what I really know.

Well. Enough introduction. In coming posts I will write about my particular thoughts of what you can do to know Java a little better.

Next, a summary of the topics that I want to talk about:

Suggested topics

• Java SE

The Java EE platform is built on top of the Java SE platform. The Java EE platform provides a particular API for server programming. So,it’s very reasonable to have a good knowledge of Java SE.

In particular, I assume that you have basic knowledge of Java.

But if you want to improve, you need to know the new features that have been published during the last years:

• Java 5

Generics, enhanced loops, autoboxing, enums (I love them), varargs, static import, and maybe the most important: annotations (they change our life as Java developers)

• Java 6

JDBC 4.0, Support for the Web Services stack and XML processing, and many more.

• Java 7

A quite handy features for developing like Strings in switch statements, Binary integral literals and underscores in numeric literals, Multi-catch and more precise rethrow, diamond operator, try-with-resources, Simplified varargs method invocation.

As Java 8 has been released very recently, you can skip it for a little while.

• Java Concurrency

Why a specific section for Java SE Concurrency?

Because in Java SE 5 everything changed. Concurrency in Java was improved in a way that provides a more natural approach to multi-threading (I had great joy with two of the enhancement of Java 5: Generics and Callable) and at the same time it avoids the long-term errors that the concurrency library had: the method Thread.stop() (actually, it already exists, and I don’t know why)

Not only you need to try not using Thread.start() anymore, try ExceutorService instead, you also need to know about Future and the new way to synchronize threads for understanding new features for concurrency of Java EE 7.

Besides, it’s really an improvement to know about Executor Framework in Java.

There are a couple of good Java Concurrency tutorials:

• Vogella’s Java concurrency (multi-threading) – Tutorial
• Jenkov’s Java Concurrency / Multithreading Tutorial and Java Concurrency Utilities
• Java EE 7

In spite of there are only a few Java EE 7 compatible servers, it’s time to know about the exciting new features that will allow you to create better and faster applications:

• HTML5 (WebSockets and JSON)
• Simplified JMS 2.0 API
• Batch applications
• Concurrency utilities (at last JSR 236 is finished)
• Context Dependency Injection (CDI. Yeah, introduced in Java EE 6, it has been enhanced to compete with Spring’s @Autowired)
• Java API for RESTful Web Services (JAX-RS) 2.0 (webservices, clients and more)
• Servlet 3.1
• Spring Projects

I want to create particular blog entries for each Spring project that I’ve worked with, but in the meantime, the best way to getting started would be to take a look to the guides that they provide.

• Other technologies good to know

Since you’re using Java for writing programs to build solutions for business, it’s good to know the new environments that provides modern approaches for the current challenges.

You have to take a look to NoSQL, being MongoDB the most popular, with good documentation, including programming with Java.

The next step should be Big Data. Hadoop is the project that you have to pay attention for, but it’s so big, with several related projects, and so complex, that I still haven’t found a good introductory tutorial.

Finally, Asynchronous I/O, that is the new solution for a problem that has been created by the new economy based on the internet of the things, that is, the need of handle scaling transactions from hundreds, thousands, even millions of users and the requirement of high-performance, high-speed for these operations.

There are several new frameworks that are worth it: Akka, Vert.x, Reactor (a foundational framework for asynchronous applications on the JVM, by Spring, but it’s not part of the portfolio) and Node.js (yes, it’s JavaScript)

That’s all for now. I hope my colleague finds this entry interesting and I wish it is the first of a series of articles.

Let’s see.

]]> http://malsolo.com/blog4java/?feed=rss2&p=79 0 http://malsolo.com/blog4java/?p=35 http://malsolo.com/blog4java/?p=35#comments Tue, 08 Jul 2014 13:29:29 +0000 http://malsolo.com/blog4java/?p=35 Continue reading →]]> What is Vert.x?

In my humble opinion, Vert.x is a poorly documented platform for creating server applications intended to be scalable by using an event-driven, non-blocking I/O in the JVM.

The first definition for Vert.x I heard was “it’s like Node.js but in the JVM”. (Yeah!, part of my first definition has been copied from the description that can be found at Node.js)

OK! Let’s take a look to the Vert.x site:

“Vert.x is a lightweight, high performance application platform for the JVM that’s designed for modern mobile, web, and enterprise applications.”

Terrific! Furthermore:

• It’s polyglot: you can write your application components in Java, JavaScript, CoffeeScript, Ruby, Python or Groovy. And you can even mix all these languages. Sincerely, I don’t find this feature exciting.
• It has a simple APIs for writing non-blocking network enabled applications.
• It’s scalable because it uses non blocking I/O to serve many connections with minimal threads plus passing messages to handle the logic of the application.
• It provides a simple actor-like concurrency model, so that you don’t have to worry about multi-threaded programming anymore.

Well! I still miss something here.

Taking a look to the Key Features you’ll learn that Vert.x has an Event Bus, a kind of Queue that will use the Vert.x components, called Verticles, to communicate between them regardless their programming language. It uses WebSockets and SockJS to achieve the JavaScript penetration that they claim.

Vert.x is a platform that you invoke from the command line, vert.x run for single Verticles or vert.x runmod for the encapsulation system that Vert.x provides: the module system (that can be shared via Maven repository or Bintray and can be registered in the module registry). But it also can be embedded in a Java application.

Install Vert.x

Installing Vert.x is very easy:

1. You need a Linux, OS X or Windows with JDK 1.7.0 or later installed (try javac -version in order to ensure that you have the JDK bin directory on your PATH).
2. Download the latest release of Vert.x, 2.1.1 at the time of this writing.
3. Decompress the download file. I like to have an Applications directory in my home directory, so: tar -zxf ~/Applications/vert.x-2.1.1.tar.gz will work right.
4. Add the Vert.x bin directory to your PATH environment variable.

Now you can check the version:

$ vertx version
2.1.1 (built 2014-06-18 14:11:03)

The first example

Testing the install is as easy as write a simple web server. This example will show the main features of Vert.x: simplicity, scalability, concurrency. With a few more examples, the polyglot would be showed as well.

Copy the following into a text editor and save it as Server.java

public class Main {
import org.vertx.java.core.Handler;
import org.vertx.java.core.http.HttpServerRequest;
import org.vertx.java.platform.Verticle;

public class Server extends Verticle {

  public void start() {
    vertx.createHttpServer().requestHandler(new Handler<HttpServerRequest>() {
      public void handle(HttpServerRequest req) {
        //String file = req.path().equals("/") ? "index.html" : req.path();
        //req.response().sendFile("webroot/" + file);
        req.response().end("Hello World!");
      }
    }).listen(8080);
  }
}

Now run this Verticle (more on the Vert.x concepts later) by opening a console in the directory where you saved the file, and typing:

~/Documents/vert.x$ vertx run Server.java
Succeeded in deploying verticle

To ensure that you have really succeeded with this verticle, open a web browser and go to http://localhost:8080 (see above the highlighted line 15, if you want to change the port number)

You have to see “Hello World!” (without the quotes)



Hello vert.x

Now you can stop the server by using Ctrl+C (Command-C in OS X)

^C
~/Documents/vert.x$

Regarding polyglot, you can find more or less the same sample at in JavaScript, Ruby, Groovy, Python and Clojure

You can see with this example another feature of Vert.x: you don’t need to compile Java code. I suppose that the authors wanted to give the same facilities that the other languages have, but they are script languages. I don’t find interesting this option, and it’s totally useless for big projects, that is better to be distributed as modules.

Next steps

We have seen almost nothing of Vert.x but the installation and a dumb test. In later posts, I will explain the Core Concepts and I will develop a Java Vert.x application using maven.

]]> http://malsolo.com/blog4java/?feed=rss2&p=35 0 http://malsolo.com/blog4java/?p=30 http://malsolo.com/blog4java/?p=30#comments Mon, 07 Jul 2014 12:52:12 +0000 http://malsolo.com/blog4java/?p=30 Continue reading →]]> I always wanted to have my own website but I don’t have enough skills as web developer to create one from scratch.

I’m a Java EE developer, so I have to work with HTML/CSS/JavaScript/JQuery on a regular basis. But I’m not a web designer. Actually, I’m really bad at designing.

But I love programming and one day I discovered Yeoman (the web’s scaffolding tool for modern webapps, as they claim)

The problem here is the usual when you discover a new tool, suddenly you need to know a lot of related stuff. That is, Node.js, NPM, Grunt, Bower, and a lot of intimidating names.

Youtube to the rescue. Find this video “Yeoman tutorial – Master Front-End Workflow with Yeomaman, Grunt and Bower” and you will have your website up and running in a few minutes.

That’s not totally true. I’ve had to download jpegtran-bin and I’ve spent a lot of time with minor details with some layouts.

Well, it’s been funny to work as web developer by editing my HTML files, testing them locally (with the server created by grunt server) and then uploading the files to the server (after creating a minified site with grunt build)

And here it is: Malsolo website.

]]> http://malsolo.com/blog4java/?feed=rss2&p=30 0