As a casual Google Chrome user it took me quite a time today to get the browser ignore my SSL verification problem. Finally I found the solution on the Internet.

Launch Chrome with this command-line argument:

--ignore-certificate-errors

Source: How to get over with SSL Cert verification on Google Chrome

I hope this helps others to find the solution to this problem faster than I did today.

Thanks Very thanks!!! Some problem! Solved!

Braian. (July 10, 2013 at 7:22 pm)

how do you do it? not everyone using the internet is a computer engineer 

smkerr2013 . (October 16, 2013 at 7:20 pm)

I’m sorry, but this blog addresses computer engineers. This tip is for those who want to launch Chrome from the command shell (non-developers usually won’t do this).

If you want to give it a try: Open a command shell (also known as: console, terminal, anything that gives you a prompt), find the chrome executable (e.g. on windows C:\Program Files (x86)\Google\Chrome\Application\chrome.exe) and type

“C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” –ignore-certificate-errors

The icon you may click or double click to start Chrome usually also allows to add command line arguments. It depends on your operating system how to do this.

Hope this helps (at least to give you a few search terms ).

Robert. (October 16, 2013 at 8:34 pm)

In our article API Change that breaks at Runtime we discussed an API change in our smartics-commons library. We introduced a new class called Arg that allows to check method arguments. It has a slight improvement for its usability compared to the old Arguments class.

This post will show you the actual API change in action.

Failing fast

To follow the path of fail-fast a method should check its arguments prior to actually using it. This allows to spot the source of the problem quickly. In Design-by-Contract this is a precondition to be met before the execution of some code starts.

This is how an argument check in Java looks like:

public void add(final Item item) {
  if(item == null) {
    throw new NullPointerException("item must not be 'null'!");
  }
  
  items.add(item);      
}

Preferable would be to make this check in a single line like this:

public void add(final Item item) {
  Arg.checkNotNull("item", item);
    
  items.add(item);      
}

Arg allows to write the check in one line instead of three. A more compact representation that is easier to read.

Exception in ... 
  de.smartics.util.lang.NullArgumentException: item must not be 'null'.
	at de.smartics.util.lang.Arg.checkNotNull(Arg.java:87)
	at de.smartics.util.lang.Arg.checkNotNull(Arg.java:64)
        ...

This way the error message also adheres to the same wording for each raised exception.

It also states the problem more clearly than if the code just runs into a NullPointerException:

Exception in thread "main" java.lang.NullPointerException
	at MyClass.add(MyClass.java:29)
	at Somewhere.something(Somewhere.java:42)
        ...

That’s why the method requires the name of the argument to be passed as the first argument. If you do not feel comfortable with that, have a look at one of the following alternatives:

1. Java 7: Objects
2. Apache commons-lang: Validate
3. Google guava-libraries: Preconditions

Apache’s and Google’s version provide much more methods on checking values than our class does, but they all three either provides a generic message or you have to pass in the message you want to be displayed in case of detecting an illegal argument.

NullPointerException or IllegalArgumentException?

Due to Java conventions the exception de.smartics.util.lang.NullArgumentException does not derive from IllegalArgumentException as one might expect.

If a caller passes null in some parameter for which null values are prohibited, convention dictates that NullPointerException be thrown rather than IllegalArgumentException.

Joshua Bloch. Effective Java – Second Edition, p. 248

So we should follow this convention. For more information on this topic please refer to this mailing list posting: commons lang3: NullArgumentException missing?

Declare raised Exception

There is a discussion (e.g. at stackoverflow) whether or not runtime exceptions should be declared. For me, as an API user, declaring the raised exception helps to know how to use a particular piece of an API.

/**
 * ...
 *
 * @param item the item to add to the list of items.
 * @throws NullPointerException if {@code item} is {@code null}.
 */
public void add(final Item item) throws NullPointerException {
  Arg.checkNotNull("item", item);
  
  items.add(item);      
}

This clearly shows that passing a null value for an item is not allowed.

Blank Strings considered

Besides checks for illegal null arguments we often check for String instances to be not blank, i.e. not null, not empty, and not only containing whitespaces.

public void doSomething(final String input)
  throws NullPointerException, IllegalArgumentException {
  Arg.checkNotBlank("input", input);
 
  ...
}

And there is a special version if you allow a value to be null, but not empty or only containing whitespaces.

Arg.checkNotBlankExceptNull("input", input);

Constructors

The technique of failing-fast is especially useful on construction of an instance of a class. This is because a failure may be encountered much later than when the bug was introduced.

public Item(final String name) {
  this.name = Arg.checkNotBlank(name);
}
 
public int displayWidth() {
  return name.length(); //  <-- problem if not checked at construction time
}

This short version is possible since the release of version 0.4.0. Prior to that we had to use two lines of code, instead of one.

public Item(final String name) {
  Arguments.checkNotBlank(name);
  this.name = name;
}

Conclusion

This has been a short information on checking preconditions with Arg with references to interesting articles and posts to this topic on the web.

For more information on our small Java library, please refer to smartics-commons or directly to the project’s site.

There are a couple of tools that allow to produce appealing API documentation with Javadoc.

UMLGraph is one of them.

Using UMLGraph

The Doclet allows to render UML diagrams automatically in Javadoc reports like this:

This gives a good overview over the relationships of the highlighted class. It also allows navigating to another class by clicking on it.

Maven Configuration

To integrate this in your Maven build, use this configuration for the Maven Javadoc Plugin:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-javadoc-plugin</artifactId>
  <configuration>
    ...
    <doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
    <docletArtifact>
      <groupId>org.umlgraph</groupId>
      <artifactId>UmlGraph</artifactId>
      <version>5.6</version>
    </docletArtifact>
    <additionalparam>
      -inferrel -inferdep -quiet -hide java.*
      -collpackages java.util.* -qualify
      -postfixpackage
      -nodefontsize 9 -nodefontpackagesize 7
    </additionalparam>
    ...
  </configuration>
</plugin>

This snippet shows only the relevant part for the integration of the doclet.

Limitations

Since the UML diagram is drawn automatically, you have no control over the layout.

This may result in a diagram not worth showing:

Or you may encounter a diagram that simply tells to much:

Despite this minor limitations we usually include the automatically generated diagrams in our Javadoc reports. If you want to add manually crafted diagrams, please have a look at our article Using PlantUML (this can probably also be done with UMLGraph).

References and other Resources

• taglets.sourceforge.net - for more information on this library.
• Using PlantUML - shows how to use PlantUML from within Javadoc.
• Appealing API Documentation with Taglets - short article on how to use taglets in Javadoc.
• Doclet - more information about doclets as part of Javadoc.

There are a couple of tools that allow to produce appealing API documentation with Javadoc.

The taglets library is one of them.

Using taglets

The taglets library has defined a couple of visually attractive taglets that allow to highlight important information within an API or even render Java source code (e.g. for example usage scenarios). Here is an example from the API documentation of one of our projects (it shows an element of an annotation):

Maven Configuration

To integrate this in your Maven build, use this configuration for the Maven Javadoc Plugin:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-javadoc-plugin</artifactId>
  <configuration>
    ...
    <taglets>
      <taglet>
        <tagletClass>net.sourceforge.taglets.Taglets</tagletClass>
        <tagletArtifact>
          <groupId>net.sourceforge.taglets</groupId>
          <artifactId>taglets</artifactId>
          <version>2.0.3</version>
        </tagletArtifact>
      </taglet>
    </taglets>
    ...
  </configuration>
</plugin>

This snippet shows only the relevant part for the integration of the taglets library. The artifact can be found on our Nexus server.

References and other Resources

• taglets.sourceforge.net - for more information on this library.
• Using PlantUML - shows how to use PlantUML from within Javadoc.
• Appealing API Documentation with UMLGraph - short article on how to use UMLGraph in Javadoc to automatically generate UML class diagrams.
• Taglet - more information about taglets as part of Javadoc.

The library smartics-commons for Java has been released with version 0.4.0.

A new helper class called Arg to check arguments has been introduced. The old class Arguments has been marked as deprecated.

We also made information relevant to developers to decide about using this library more easily accessible from the project's homepage.