Annotations and Decorators in Java

Annotations on the code or decorators have become very common. They allow the programmer to add additional useful information about how to improve the code or change how to compile / run a particular class. They are a Java extension to allow aspect-oriented programming.

We have three types of annotations based on the moment of usage:

Information for the Compiler

These annotations allow the compiler to indicate whether or not to ignore errors and warnings or what to do with them. If you’ve worked with a Java IDE (like eclipse) probably you would have used this type of annotations. For example, you can use @Override on a function to indicate that you are overwriting a method defined on a parent class. 

This annotation is completely optional, but allows both the compiler and the developer to check that they are indeed overwriting existing hierarchical functionality.

For example:

public class Parent {     
    public void do(){
        System.out.println("Parent");
     }
}

public class Son extends Parent{     
    @Override
    public void do(){
        System.out.println("Son");
     }
}
Compiler-time and deployment-time processing

These annotations allow the compiler to add extra information about how to generate the code. By adding or modifying functionality from that in the source code you can alter how a class behaves. Also to create new classes (based on a file descriptor), etc …

These annotations will only be visible at this point. They are not compiled to the .class files. Therefore they are not available at runtime.

Runtime Annotations

You can use this annotations on runtime and they work on a very similar way as an interface.

Let’s see an example on how to create a Runtime Annotation and how can we use it. The annotation named MyAnnotation can be applied to elements oftype field:

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
     public @interface MyAnnotation {
}

Now we can create an annotated class by this annotation:

public class myObject
 {
 @MyAnnotation
 public String field;
 }

This way, we can check by reflection if an object has an annotated field on any part of the code:

Class<?> res = objeto.getClass();
for (Field f : res.getFields()) {
     if (f.isAnnotationPresent(MyAnnotation.class)) {
          System.out.println("OK");
      }
}

More Information:

Notes of the gvSIG 2.0 workshop

This are the notes that I took over gvSIG 2.0 on the latests Jornadas GvSIG.

Pre-requisites

  • Java
  • Eclipse
  • Ant (should)
  • Maven (should)
  • gvSIG (this is recursive :))

The main advantage of gvSIG 2.0 is that you can create a new plugin without knowing how does gvSIG work or having to compile it. We already have a gvSIG installation that deploys the binaries to the workspace. But we don’t have to change the source code. Unless, of course, something doesn’t work (bugs) or we have to add some new functionality to the core. Better if you don’t touch it, ask the developers and they will take care.

Creating the workspace

With the binary, there is a wizard which creates an Eclipse workspace with a default template. That leaves all set up but to compile our extension. It also includes a wizard to easily generate installables. These wizards are accessible through the application, at the application menu.

Org.gvsig.tools is the basic infrastructure library to develop plugins. The main functionality is focused on the registration of extension points, utilities to separate API, implementations, SPI (service provider), and monitoring tasks (which in version 1.0 used to freeze the application). This library also supports events, persistence, etc …

gvSIG Plugins

A library is a jar. When our application contains the jar, org.gvsig.tools prepares and initializes this library within the core. The classes in the library implement the interface Library (AbstractLibrary).

The managers (PluginsManager) is the entry point of the features. They are like factories (singletons) (at least one per library) that raises the request of the functionality included in the library. It also saves the configuration of the module.

The locators (PluginsLocator) allow to register implementations of managers.We can recover a specific manager API. “Give me the manager of this library.”

A Plugin is a piece that adds a functionality: buttons and toolbars, menu options, data providers and types of documents. Andami has not evolved much since version 1.x. Andami is the framework for the plugins.

The plugin will always have at least two files:

  • config.xml indicating the classes that implement the plug-in units and menus
  • package.info indicating the version, name, build, … of the plugin.

gvSIG Extensions

An extension (IExtension) is a set of tools associated with a plugin inside a toolbar or menu and they work together. A group of plugins, you may say. The extension that implements ExclusiveUIExtension specify what tools are or not visible, without touching the core code.

To create a new plugin, we make use of the tool menu generation of plugins available from the development version. This generates the workspace automatically and installs the plugin from which we generated the plugin. If you have no development release, you will have to compile the sources.

You should be starting a plugin with the wizard while reading this notes or you will be lost.

The plugin consists of two maven projects: org.gvsig.plugin and org.gvsig.plugin.app. org.gvsig.plugin provide the functionality of the library independently of gvSIG (business logic). May have library dependencies, but should be able to operate without having to open the application. That is, it requires nothing of Andami, for example. In org.gvsig.plugin.app.mainplugin (within org.gvsig.plugin.app) we will implement the functionality.

The “api” packages should contain interfaces and the “impl” packages should contain implementations.

Now the workspace is ready to work with Eclipse if we import the project with the maven plugin. If we took an appropriate template to generate the plugin sources, almost all the work is done (except for the exact business logic of our plugin).

Final Advices

It is important to have a java project to test our plugin with its own main, without having to start gvSIG. Also it is recommended that the library has unit tests. That is, we can make an application with the full power of gvSIG, but without using gvSIG itself, ie as if it was a powerful library GIS. Conclusion: if we do well, we could even use our plugin into another no application … as Gofleet.

Each plugin contains own installer, which created by a wizard inside the application.

High Concurrency

When facing high concurrency applications, we often find a number of generic problems. In this article I will focus on the problems of resources (CPU and memory). For now on, I will focus on the most typical and most direct solutions.

When we discover threads and the advantages of parallel processing it can happen that we end up abusing their use. We have a lot of threads (100 ¿? 1000?) simultaneously, and the processor will be jumping from one to another without stopping, not letting them finish, no matter how fast is their real excution. And over time there will be more and more threads only slowing down the process. To the cost of execution of each thread, we must consider also the added cost of creating and destroying threads. It can can become significant when we talk about so many threads at once.

High Concurrency with the Thread Pool Pattern
High Concurrency with the Thread Pool Pattern

Threads: the holy grail

In this case, the first method that we think of is the Thread Pool Pattern . This pattern will limit the number of threads running at the same time.
Instead of creating new threads, we create tasks, which are piled. Also, we have a pool of threads that will work picking these up and running as soon as possible. A classic example of this thread can be found on SwingWorker. If we want to implement bare hands our own pattern, we should take a look at the interface ExecutorService.

If you have a background thread that is making heavy use of processor, but we do not mind slowing it down for performance, we can use the command sleep ( Thread.sleep (...)) to periodically release the thread processor, allowing other threads to run faster .

This is useful for threads running in maintenance mode, which must be kept running but do not have to respond in real time. Another way to temporarily stop a running thread while another is using the method join ( Thread.Join () ), which makes a thread wait until another thread ends. Although more useful if we have a clearly higher priority thread than another, it is not viable if we can not have a reference to a higher priority thread from the lowest priority to tell which thread has to wait.

High Concurrency issues

But the high turnout is not given only by the use of the processor. It may be that multiple threads need access to large amounts of information almost simultaneously. These threads will not only be repeating the information in memory but often will be repeating the entire process of extracting that information.

This problem is usually solved in the majority of data access libraries (mostly database). For example, we have ehcache , which uses threads to store information ( Thread-Specific Storage Pattern ). This way, access and storage of this information is shared. Thus decreasing both the memory usage required and the processor time required to extract and shape information. As the threads wants to process this information, they will be asking ehcache for the data, which will optimize these hits.

To improve this solution have the concurrent collections. This allow different threads to use the same objects without any problems of concurrency.

There are more solutions to improve the high turnout (without going into optimizations to the code itself). But those described here are usually good ideas to start.

Useful References: