Stay SOLID!

From time to time, in a break between fierce battles with code, requirements and time each of us starts asking questions more sophisticated than "how to write another freakin' routine". One of the most frequently repeated is how to check if a OO code is really well designed (and later implemented).
Let's forget for now about the "big" architecture and concentrate on the "small" one - single components/packages. Some advices and concepts (as DRY or GRASP) can be found here and there - for example in excellent book "Effective Java" by Josh Bloch. Additionally, tons of useful yet short articles are published by recognized authors as Martin Fowler or Robert "Uncle Bob" Martin.
The latter one created short, concise list of Object Oriented Design principles under the clever name - SOLID. In short, those are as follows:

• S(RP) - Single responsibility principle - "an object should have only a single reason to change".
• O(CP) - Open/closed principle - “ability to extend class behaviour without modifying it”.
• L(SP) - Liskov substitution principle - "subtypes must be substitutable for their base classes, without modifying program's correctness".
• I(SP) - Interface segregation principle - "create fine grained interfaces for specific purposes".
• D(IP) - Dependency inversion principle - "depend on abstractions, not on concretions"

SOLID is few years old, but still managed to gain some attention, so web is filled with articles discussing all principles in details. One particularly interesting resource is old Uncle Bob blog post here. Also, Lost Techies has an article filled with Java examples.

Looking from experience's point of view, after some years of code crunching SOLID principles come intuitively. SRP, OCP are basic concepts understood quite early. DIP is adopted swiftly after meeting DI containers. LSP looks a bit more complex, but is in fact substantial when dealing with complex models with inheritance.
All in all, it's good to keep SOLID as a reference. Reviews can only benefit from using such simple yet useful checklist :-)

Spice up your Java with Lombok

Verbosity of Java language has been discussed for years. Almost since inception developers keen on clean and concise code were complaining about writing resource management code (lengthy if-try-catch with JDBC) or creating getters/mutators in Java beans. Simply put, Java language forces devs to write lots of boilerplate code. Some most painful spots are being addressed by language enhancements, like Automatic Resource Management (ARM) in Java 7. Yet this process is complex, cumbersome and takes time.
Is there any better (faster) relieve then? It seems there is! Presenting Project Lombok. Nice utility to speed-up development using source-code annotations. Some most useful features are as follows:

• @Getter/@Setter - simply annotate any field to have appropriate method generated. What's more, getter can be "lazy" without any explicit locking code.
• @Cleanup - ARM is here, no need to wait for version 7 release.
• @NoArgsConstructor, @RequiredArgsConstructor, @AllArgsConstructor - used along with @NotNull instruct Lombok to generate appropriate constructors with arguments checking. Beautiful :)

Full list can be found here.

To entice you more, just take a look at following example:

@RequiredArgsConstructor(staticName = "of")
@AllArgsConstructor
public class Bean {

    @NotNull @Getter private String name;
    @Getter @Setter private String value;
    @Getter @Setter private int count; 
}

Isn't that appealing? ;-)

Shrink your JAR

Releasing your small project / library into public? Think about shrinking it beforehand - it's always nice to save some bandwidth if possible. There is nice (free!) tool for this purpose - ProGuard. Results, as published on the web, are quite encouraging. For example Apache Ant went down to 242K from 2.4M and that's staggering 90%.
What's more, ProGuard can do more that mere shrinking. Dead code listing (optimization) and obfuscation all come bundled.
To sum up, one quick run of this handy tool can make your release smaller and less prone to reverse-engineering. Give it a try!

Why is "your Agile" failing?

Have you ever wondered why is this famous "Agile" failing in your company? Why, after spending some time and money on various consultants it doesn't give expected performance/quality/customer satisfaction boost?
If so, check out this talk by Dan North from ThoughtWorks: http://vimeo.com/10380489. It may shed some light ;-)

SMTP in Java with javax.mail

JavaMail API (aka javax.mail, available here) is a great library for sending/receiving mails straight from a Java code. Web is crammed with basic examples how to use it. It's however much more difficult to find an example with secure SMTP working with "real" server, like GMail.
In fact, there are two standardized types of secure mail sending:

• ESMTP protocol, working with or without encryption. Requires "pure" (non-SSL) sockets to be used. With "starttls" command, communication can be upgraded to full SSL. RFC-defined port is 587.


• SMTP protocol over the SSL transport. Requires SSL sockets to be used from the beginning. RFC-defined port is 465.

In order to configure JavaMail for ESMTP, following code is needed:

Properties properties = new Properties();
properties.put("mail.smtp.starttls.enable", "true")
final javax.mail.Session session = javax.mail.Session.getInstance(properties);

while for SMTP over SSL, use following:

Properties properties = new Properties();
properties.put("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory");
final javax.mail.Session session = javax.mail.Session.getInstance(properties);

That's basically it. I tested following properties with GMail account, using both "SMTP over SSL" and "ESMTP with STARTTLS" options and it worked smoothly.
Following some most commonly experienced errors/exceptions with short descriptions:

1. com.sun.mail.smtp.SMTPSendFailedException: 554 5.7.1 Sender address rejected.
   In case of many providers (like "o2.pl") means that only account owner (like "user@o2.pl") is allowed as the message sender.


2. javax.mail.MessagingException: Could not connect to SMTP host: smtp.live.com, port: 465; nested exception is: java.net.ConnectException: Connection timed out
   Basically thrown when requested port isn't open. In the mail world usually means that server doesn't offer configured secure protocol (for example Hotmail doesn't offer pure SSL connection)


3. com.sun.mail.smtp.SMTPSendFailedException: 553 From address not verified
   Means that sender address needs to be verified (enabled) in account's configuration. Can be experienced with for example Yahoo! free accounts.


4. javax.mail.AuthenticationFailedException: 535-5.7.1 Username and Password not accepted.
   Send by server if user or password used for authentication failed. Usually means that server requires full user name (user@server.com) to be used.

If above solution fails (or experienced exception is different than listed), you can always enable JavaMail debug with following property:

properties.put("mail.smtp.debug", "true");

There is also nice shell tool, very useful for checking secure SMTP account's features, called "smtp-cli". You can grab it here.