How not to check for null

There are some clever tricks how to deal with null values. Usage of guava's Optional is one of them. But this is not one of them:

    final Optional<MilestoneDocument> documentOfVersion = findDocumentOfVersion(documentType, documentVersion);
    if (documentOfVersion == null) {
      throw new IllegalStateException();
    }
    if (documentOfVersion.isPresent()) {
      return documentOfVersion.get();
    }

user friendly search on windows

Windows with its cmd.exe seems not to be user friendly environment for developer. But this may be changed easily, you need only to install few programs we miss from normal systems. See http://gnuwin32.sourceforge.net and download coreutils, findutils, sed, awk, grep etc. and put them to PATH. As find.exe confilicts with windows file.exe I always rename it to gfind.exe . You have to be careful with quoting - only double quote is welcomed. Also paths may be tricki, remember to replace / with \. Eg. xargs needs extra backslash to interpret one properly.

Let's find all inserts in sql files.

find . -name '*.sql' | xargs grep insert 

It is the win32 version:

gfind . -name "*.sql" | sed s!/!\\\\!g | xargs grep insert

Summary: having in mind few simple rules you may make your system much easier to talk to.

picking up python

Recently I dived into jython, which is now scripting layer of application I' maintaining. Coming from Java/Scala I have some notices:

• indentation matters
it actually does not matter that much, as I indent my code :>
• method's first argument is always self
this point may have some exceptions, but for me a thumb rule is :%s/()/(self)/ in my vim :>
• there is no null, but None
even if it's still jvm
• None starts with capital letter, just like False, True and some others...
this one really surprised me
• you do not write new to create new object
just call constructor, but
• you have to return explicitly
which hurts when you're used to scala's brevity

strange exception under JSF+JSP

Since we combined JSP with JSF 1.2 on websphere community edition (wasc 2.1.1.4) (same for apache geronimo/apache tomcat), i often see mysteriously looking exception: A literal value was specified for attribute actionListener (see below for stack). This looks like we cannot use #{...} expressions used by faces but only ${...} used by JSP. This is the exception itself:

Caused by: org.apache.jasper.JasperException: /portal/activity/ActivityResultInfo.jsp(377,8) A literal value was specified for attribute actionListener that is defined as a deferred method with a return type of void. JSP.2.3.4 does not permit literal values in this case
 at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
 at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407)
 at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:148)
 at org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes(Validator.java:1119)
 at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:846)
 at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1530)
 at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2361)
 at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2411)
 at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:865)
 ...

Fortunately we have not only found the problem but also a cure. Assuming web.xml for server is located in C:\Tools\WASC 2.1.1.4\var\catalina\conf, make sure it contains following entries:

  
        jsp
        org.apache.jasper.servlet.JspServlet
 
        modificationTestInterval
        0
    
        
            development
            true
        
        
            fork
            false
        
        
            xpoweredBy
            false
        
        
            engineOptionsClass
            org.apache.geronimo.jasper.JspServletOptions
    
    
        scratchdir
        c:/Tools/WASC 2.1.1.4/var/catalina/worker1/

    
    
        keepgenerated
        true
    
        3
    

keepgenerated = true is very important. Now, you can get rid of problem undeploying app, stopping your app server, cleaning scratch dir and redeploying app back. Then faces should run normally.

Do NEVER let user type in country name

It's really easier to maintain full list of countries in DB than end up with such (growing day by day) list for Great Britain only (authentic data from production):

CENTRE LONDON 
UNITED KINGDOM
U?K
NORTHERN IRELAND
WEST MIDS
CENTRE LONDON
WEST YORKSHIRE
ENGLAQND
UK 
?UK
GB,UNITED KINGDOM
GB
ENGLAND
N.IRELAND
MIDDLESEX
CORNWALL
GREAT BRITAIN
U.K.
WALES
NIRELAND

using Spring RestTemplate with parameters

I had to use HTTP today to get some data of remote service.
Usually I rather write a servlet on server side, so my first idea was to use simply java.net.URL to perform this task.
First you create URL, then openConnection, then open stream... and so on. Btw. how to issue POST request?
I just thought that it could be useful to use some more specialized API, but is it sensible to include e.g. Apache HttpClient into project just to issue a few simple requests?
And all code around the URL...

Why there is nothing like JdbcTemplate from Spring to operate on Http?
But wait... Let's look perhaps there is something?
Well smart guys from Spring Source already made it - the RestTemplate class.
Tada!
 Now my operation can look like this:

String pong = new RestTemplate().getForObject(address + PING, String.class);
Validate.isTrue(PONG.equals(pong));

And perhaps you may want to use POST with parameters via RestTemplate?

 HttpHeaders  headers = new HttpHeaders();
 headers.setContentType(MediaType.APPLICATION_FORM_URLENCODED);
 HttpEntity req = new HttpEntity<>(urlEncodeYourParams(), headers);
 RestTemplate rest = new RestTemplate();
 ResponseEntity result = rest.postForEntity(address, req, String.class);
 System.out.println( result.getBody() );

Really nice.

---Edit:
To

import org.springframework.web.client.RestTemplate

there is needed dependency on right spring project, as there are lot of there I always have problem to pick up the one, which is:

    org.springframework
    spring-web
    4.1.6.RELEASE

Value Objects + microinterfaces + generics

I guess readers are already aware of reasons why separation of application layers has positive impact on project's architecture. For more-than-simple application we usually want to ensure that any change in entity will not broke our webservices or web interfaces. And we want to be warned in compile time if there is any mismatch between what is behind other layer's boundary. That is why we introduce Value Objects, DTOs etc. - not going into details simply beans. This pattern has been recently used in my project. Let's assume we have an entity:

@Entity
class Product { 
 private Integer id; 
 private String name;
 private String description; 
// and some other stuff...

// and all setters and getters
}

and we have also corresponding bean, related to some limited functionality:

class ProductBean {
 private Integer id;
 private String name;
 private String description;
// basically same what is in entity
// but in future we expect that this will no longer be true
}

I have created some procedures that work on our beans:

class Operation { 
 private ProductBean product;
 
 public SomeResult operate() {
  //this can be some operation with lots of invocations of bean's properties
 }

}

Now my architect comes and says: 'No, it is logic layer, you should use actual entities, not beans for this operation'. But in other functions I will still be using beans.
What to do?
There are some options.

• Use copy and paste, have same code for every combination of entity and DTO. Your manager is happy until first change is made to the functionality. You know it today.
• Use reflection based stuff. Like BeanUtils from Apache Commons. Or use some dynamic language. But then you loose static type checking. You better have good test coverage or you may like surprises. Compile time error detection is valuable.
• Go agile. Use entity everywhere. Result as in previous point. And perhaps your customer has not paid for changing 30 vies where you use Product?
• Introduce common interface for entity and beans. This will asure static type checking. But then your entities and beans are coupled. If your logic depends on interface you will end up changing both kind of objects. Or worse: you will have interfaces like Product_V_8_6_1.

After taking above stuff into consideration, I decided to use some other approach.
Let's introduce specialized small interfaces like:

interface HasId {
 Integer getId();
 void setId(Integer id);
}

interface HasName {
 String getName();
 void setName(String name);
}

and so on... used per property.
My operation changes then to:

class Operation <PROD extends HasId & HasName & HasDescription > {
 private PROD product;
 
 public SomeResult operate() {
  //with no changes - I use entities, beans with no distinction now
 }

Now I have type safe generic operations not depending on specific type. If I introduce compatible change to my entity I may or may not touch my bean and I have previous application logic unchanged. With zero effort.
I depend only on properties not on owning them classes. And thanks to generics I still operate just like on types.