Archive for the 'Java' Category

August 5th, 2017
11:22 am
Using Java EE/JSR-330 annotations like @Inject in Spring

Posted under CDI & Spring
Tags

I came across a Spring Boot app which clearly used Spring for its IOC (@Configuration classes defining Spring Beans with  @Bean)

The app also used @Inject/javax.inject which initially led me to think it was using CDI/Weld, i.e. was using 2 IOC frameworks.

However, Spring also supports the basic Java EE annotations via JSR-330. JS-299 is the full CDI/Weld spec, but there was robust debate about Spring taking on board the full JSR-330 spec, and in the end they just went for a small subset which became JSR-299.

This includes among other things @Inject, so this can be used as a synonym for @Autowired.

Adam Bien describes the difference between JSR-299 and JSR-330 very well in this post here.

This blog post by David Kessler describes and investigates the use of both in code very well.

No Comments »

March 11th, 2017
12:08 pm
WebStorm/IntelliJ–Performance Problems/tweaking the IDE

Posted under IntelliJ & WebStorm
Tags ,

I hit issues with Webstorm, pregnant pauses and hanging for a few seconds.

The following points/posts offer help on tweaking:-

  1. Firstly it helps to see current VM usage. This is not on by default but if you tick Show Memory Indicator in Settings/Preference/Appearance it will then show at the bottom right of the status bar.
  2. VM can be tuned by editing the VM options as per this post here, but note that bigger is not necessarily better. Some of the hanging can be caused by excessive Garbage Collection when too much memory has to be GCd in one go. This post here goes into this. The tuning process can be informed by checking the memory indicator to see what you actually use.
  3. Excluding unwanted directories from indexing is important – see this post for details on doing this.

No Comments »

October 21st, 2013
3:55 pm
Translating a string Enum value into an Enum given an Enum class object

Posted under Java

You can translate a string Enum into its corresponding Enum using the Enum in this way :-

 

//Assuming Fields is the target Enum
String fieldName = “myField”;
Fields field = Fields.valueOf(fieldName);

 

However this can also be done if you are given a class object of the Enum:-

 

//Assuming fieldClass is a class object for the Fields Enum
String fieldName = “myField”;
Fields field = Enum.valueOf(fieldClass, fieldName);

No Comments »

March 29th, 2012
1:33 pm
CVS error on commit: “added independently by second party”

Posted under CVS
Tags , , , ,

I received this error whilst performing a commit via Eclipse:-

The server reported an error while performing the "cvs add" command. cvs server: xxx added independently by second party

The error related to some test database scripts in the project. I searched for solutions to this, and found some comments about tagging the files as merged, but this was not really any help.

In the end, I examined the files using TortoiseCVS, and noted that the offending files were not flagged as being under source control – they did not have any icon decoration on them.

In the end the following steps solved the problem:-

  1. I made sure I had copies of them elsewhere, and then deleted them from the (TortoiseCVS managed) directory under the eclipse project.
  2. I then did an Update with TortoiseCVS – this reloaded the latest versions from CVS, and this time they were correctly icon-decorated as managed.
  3. I then copied the new versions in to replace these. When I did this, the new versions were correctly decorated in red as updated versions but known to CVS/Tortoise.
  4. I then did a commit with Eclipse, and this now proceeded without error.
  5. Finally to be safe, I did a file compare to check that the correct latest versions were in place.

This solved the problem. It appeared that somehow I had lost the required CVS metadata such that the files did not appear to be CVS managed. Tortoise was very helpful here – if you see files with no icon decoration, this is immediately suspicious.

No Comments »

February 27th, 2012
9:32 am
Passing the “this” reference for a subclass from a self-referential generic superclass

Posted under Java
Tags , , ,

Update 7/12/22

Previously I have implemented a composite iterator for iterating a tree of tags from a search on a PropertyTree implementation. Note that in this case, the abstract base class for the composites was a TagTree, and the concrete subclasses were a TagList and a Tag. As a Tag did not need a list, the list of children was in the concrete TagList and not the TagTree. Therefore, the TagTree did not need to have generic references to self referential subtypes in the way the example below does – in fact it did not need to be generic at all. Therefore it did not suffer this problem. For further clarity see the example below from Angelika Langer here. In her code, the list is in the abstract superclass which is why it suffers the problem below and potentially needs the infamous getThis trick per below.

Original Post

Some generic classes are recursively self-referential, such as in the following abstract class statement for a tree node :-

public abstract class Node <N extends Node<N>>  {

}

In this situation it is sometimes necessary for example to pass a reference to this from the superclass to a specific subclass which expects an argument of type N :-

public void methodA(N node) {
//do something with the passed node
}

public void methodB(N node) {
node.methodA(this); // error – incompatible types
}

In the above fragment, the error is because this in the superclass has a type of Node<N> which does not match N.

Another related use case is where a fluent API returns a ‘this’ reference from each of the fluent methods. If for example a fluent method in an abstract base class needs to return a ‘this’, as above the reference needs to be for the concrete subclass so the same problem occurs.

The topic is discussed in detail in Java Generics and Collections, section 9.4 on the Strategy pattern. The section from the book may be viewed online at Flylib here.

Angelika Langer also discusses it in more detail her Generics FAQ here

In the above case, the problem can be solved with the so-called getThis trick. An abstract getThis method is defined in the superclass, and implemented in each subclass:-

Superclass

protected abstract N getThis();

Subclass

protected Subtype getThis() {return this}; // where Subtype is the concrete subtype of N

Now the superclass can obtain a type correct reference to this and pass it without error:-

public void methodB(N node) {
node.methodA(getThis()); // this time it works
}

As Angelika Langer points out in her examples, there can be other ways around this kind of problem depending on the situation, but sometimes you do need the getThis trick.

No Comments »

February 21st, 2012
3:57 pm
CDI Interceptors not called on local call to service layer EJB method

Posted under CDI
Tags , ,

When a service layer EJB method is called locally from within the same class, any CDI interceptors on the method are not invoked. This is standard CDI behaviour, as interceptors are only designed to be called when a method is called from an external client.

I hit this issue when my OptimisticLockInterceptor (which converts OptimisticLockException to ChangeCollisionException) was not being called, and OptimisticLockExceptions where being propagated all the way up to the view layer -  Mantis issue 120 details this.

The solution to this is to ensure that any required interceptors are annotated on methods at the point of call from an external client. If they then call another EJB method locally, any interceptors on the second method will not be called, but this is not a problem if the first method is correctly annotated. If the second method is also used externally, then its interceptors will be correctly invoked.

No Comments »

February 14th, 2012
3:11 pm
Using a Message Bundle to make Dialog sizes locale dependant

Posted under JSF
Tags , , , , ,

A common issue I have found is setting confirmation dialog widths correctly to hold the target message neatly.

With a Primefaces p:confirmDialog for example, the height auto adjusts but the width defaults to 300 pixels, and is set via an integer width attribute.

When supporting multiple languages, message sizes and sentence structure obviously differ, and it can be desirable to change the dialog width for example. Whilst a large width could be chosen which is likely to support any language, this can look less than perfect due to the extra unwanted space.

One simple solution which I came up with is just to store the dialog width in the Message Bundle along with the message. This way, the dialog width will automatically adjust to the value set for the target locale when switching locales. The same idea could be used to set a width etc. via CSS as well.

Whilst I am in no way suggesting turning a message bundle into a style sheet, this is a clean solution for this particular simple case and others like it, especially as the width is set as a component attribute and not in CSS, so style sheet localisation is not a possibility. Style sheet/resource localisation is available in JSF 2, but is somewhat non-intuitive. (Core JSF 3 p113-114 opines that it is an unappealing solution, and hopes for a better implementation in a future JSF release.)

No Comments »

February 13th, 2012
2:42 pm
CDI/Weld fails to inject a reference with nested parameterised types

Posted under CDI
Tags , , , ,

Weld 1.0 was failing with “WELD-001408 Injection point has unsatisfied dependencies” when nested parameterised types were present.

The referenced bean was correctly present and annotated.

I found that I could work around the problem by simplifying/removing some of the generics. This allowed the beans to inject, but also gave warnings about the use of raw types. For example:-

//Original code
    private @Inject TableCtrl<TreeNodePath<TaxonomyNode>, RowMetadata> selectionTable;

//was replaced with the following
    private @Inject TableCtrl<TreeNodePath, RowMetadata> selectionTable;

Attempts to use a CDI extension to find out more about what was happening did not reveal any more insight. This post discusses Weld performance and debugging and refers to a Stack Overflow post on the subject.

My solution to the problem (which I have also logged on Mantis) is  as follows :-

  1. Injecting the bean into a raw type does not suffer from the problem.
  2. I therefore inject into a temporary raw type, and cast that to the correct type.
  3. Wrapping this in a method annotated with @Inject neatly solves the problem, as the method can take the raw types as arguments, and cast to the correctly parameterised fields in the method.
  4. As all this is done in a method, warnings can be suppressed for the method. This is a tidy solution, as the method only has this specific purpose, and no other warnings in the class are incorrectly suppressed.
  5. This is far better than the original workaround which involved hacking the generics back to non nested parameterised types throughout – this meant hacking a number of classes. The current solution entirely isolates the issue and allows the desired generics to be correctly used everywhere.

An example of the correct generic declarations and the method used follows :-

public abstract class TreeBrowser<N extends TreeNode<T>, T extends Tree<N>, P extends TreeNodePath<N>>
                            implements Serializable, BreadcrumbCtrlEvent<N> {

    private CrumbComparator<N> crumbComparator;
    private BreadcrumbCtrl<N> breadcrumb;   
    private TableCtrl<N, RowMetadata> treeNodeTable;
    private TableCtrl<P, RowMetadataStatusMap> trayTable;

    @Inject
    @SuppressWarnings({"rawtypes", "unchecked"})
    void injectWeldUnsatisfiedGenericBeans(CrumbComparator crumbComparator, BreadcrumbCtrl breadcrumb,
                           TableCtrl treeNodeTable, TableCtrl trayTable) {
        this.crumbComparator = crumbComparator;
        this.breadcrumb = breadcrumb;
        this.treeNodeTable = treeNodeTable;
        this.trayTable = trayTable;
    }

 

This solved the problem.

No Comments »

February 9th, 2012
12:01 pm
EJB methods–returning status codes vs throwing exceptions

Posted under EJB
Tags , , ,

Exceptions are hotly debated on line, as is this issue as to whether to return status or throw an exception. There is no straight answer for all cases, but for the projects I am working on, I am adopting the following.

  1. Many EJB methods return data as lists of entities for example, and to return a status code as well is a nuisance as you need to build a wrapper class for this.
  2. My present way forward therefore is to throw exceptions in the EJB methods, for example when you attempt to delete a non existent row.
  3. Even though some methods like delete have no return and could return a status, others do return data and could not easily do it this way. I prefer to be consistent in my approach.
  4. Therefore, I will throw checked exceptions for these ‘important’ ones like non existant data, that the caller should check for.
  5. If I am using  a command pattern as per my post on this here, I will then catch these in the command objects,  and convert to one of the status enum values I have proposed for my Command Pattern implementation. This is an ideal place to do it, exceptions are not friendly to the command pattern mechanism if you want to continue from one, and I have already added the generic status enum idea.
  6. For cases when I do not use command patterns, a similar approach could be used by catching the exceptions in the model layer and converting to a status enum there. My model layer is stateful, and typically my fetch methods in the model populate result properties and then return void. These would be ideally placed to catch any exceptions from the service layer and return a status enum instead (or just return the enum status from a command if that was used).
  7. Coupling and isolation of the status enum needs to be considered. Where the enum is defined in the model, the view/controller layer has no dependency on the service layer. However, if the enum were to be defined in the service layer, the view then has a dependency on it as it uses that enum. This is (perhaps to a lesser extent) also true if the enum is defined in a command class, as these are also service layer classes. I may therefore decide to map them to a model specific enum (which may be similar).

No Comments »

January 29th, 2012
3:26 pm
Cannot obtain a class literal for a concrete parameterised type

Posted under Java
Tags , , , , , ,

Update 30/1/2012

After further testing, I have found more issues trying to use a parameterised concrete class in a JPA constructor expression. EclipseLink was throwing MethodNotFoundException complaining that it could not find the constructor method for the class, due to the use of the parameterised type in one of the constructor arguments. The precise circumstances where this does and does not work are not clear.

My solution has been to not use a parameterised class at all in a JPA constructor expression. To avoid most of the code duplication, what I did was to subclass the parameterised class for each concrete type I was using, i.e. I created a concrete subclass which only contained a constructor calling the superclass constructor. This then allowed me to use a typed query in JPA, as the returned class was now non-parameterised and so I could create a class literal for it.

 

Original Post

Whilst in some situations this may be an issue, it is also a statement of fact!

This is due to type erasure at run time, and cannot be done.

It means, for example, that in some cases it is not possible to completely eliminate unchecked warnings.

One example of mine was the use of a parameterised type in a constructor expression class in JPA. I had a requirement to do fetches which involved returning an entity plus another column that could not be handled as a relationship/JPA entity property. The property in question was the count of children for a tree node entity. As I was using path enumeration to describe the tree, I could not use JPA relationships to handle it, and so had to return the child count separately. I had more than one type of tree, all handled polymorphically, and so wanted to re-use the constructor class by making it parameterised.

This all worked fine but the class could not have its class literal passed when created a TypedQuery to fetch the results back. The solution was to use some casting isolated in a specific method, and to suppress the generic warnings via @SuppressWarnings("unchecked").

The following posts detail this issue:-

http://stackoverflow.com/questions/2390662/java-how-do-i-get-a-class-literal-from-a-generic-type

http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#Why is there no class literal for the concrete instantiation of a parameterized type?

No Comments »