Java Tips

javax.activation.UnsupportedDataTypeException

Nothing like starting yout Monday morning with a Java classloader issue. My fix to the problem is here: JavaMailFun.

Cannot run this command because Java services are not enabled

When connecting to Sybase via jconn3 and Spring 2.0, you receive the error:

Cannot run this command because Java services are not enabled

This can be caused by passing a char type as on of the arguments. Example:

char gender = 'M';
jdbcTemplate.queryForObject(
                "SELECT top 1 first_name from people where gender = ?",
                String.class,
                gender);

Fix: Simply convert the char to a String. I.e., String.valueOf(gender).

xml-rpc and Weblogic 9.2

xml-rpc with Basic Authentication works fine in Resin, but not Weblogic. This turned out to be a new feature in 9.2 which forces authentication checks when you specifically don't want one.

Basic Authentication does not work with WebLogic 9.2. (Issue #55793)

Workaround: If users do NOT want to authenticate basic authentication headers, they need to add this to their config.xml. Add this element:

<enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials> to the last line of <security-configuration> in config.xml for the users domain, usually in /bea/user_projects/domains/mydomain/config/config.xml. This keeps WebLogic from trying to authenticate basic authentication headers.

Use platform dependent end of line character

  private static final String EOL = System.getProperty("line.separator");

See http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#getProperties()

Use ant to create a properties java file which can be compiled

    <target name="build-properties">
       <copy todir="src">
            <fileset dir="src">
                <include name="**/*.hava"/>
            </fileset>
           <globmapper from="*.hava" to="*.java"/>
           <filterset>
               <filtersfile file="src/resources/messages_en_AU_company.properties" />
           </filterset>
        </copy>
    </target>

Replacement for StringBufferInputStream

[Bug ID: 4217782] States that StringBufferInputStream is depreciated and should be replaced with StringReader, but StringReader is not an input stream. I frequently need to turn a String into a stream for testing, so I created this class:

class StringReaderInputStream extends InputStream {

    private final StringReader reader;

    public StringReaderInputStream(String s) {
        reader = new StringReader(s);
    }

    public int read() throws IOException {
        return reader.read();
    }
}

replaceAll Backreferences

Regex functions can give you fast replacements in Java, along with the readability of Perl.

        String account = "1234567890123456";
        String replacement = account.replaceAll("(\\d{4})(\\d{2})(\\d{6})(\\d{4})", "$1 $2XX XXXX $4");
        assertEquals("1234 56XX XXXX 3456", replacement);

StringBuilder

StringBuilder is a drop in replacement for StringBuffer. Today, after much pulling out of hair, I discovered neither override the equals method.

    public void testStringBuilderWTF() {
        StringBuilder a = new StringBuilder("foo");
        StringBuilder b = new StringBuilder("foo");
        assertEquals(a, b);
    }

junit.framework.AssertionFailedError: expected:<foo> but was:<foo>

StringUtil.java

Handy collection of functions for Strings. The pluralize function was ported from Ruby.

• StringUtil.java [view] [download]

• StringUtilTest.java [view] [download]

RFC-822

I'm not sure why Java doesn't have any built in support for generating or parsing RFC-822 dates. I noticed Google has a class which does this: http://code.google.com/apis/gdata/javadoc/com/google/gdata/data/DateTime.html. It would be nice if they would add it into the DateFormatter class. Until then, CPP (copy-paste programming) will have to do.

    // The publication date is in RFC 822 format which is in english
    // see http://blogs.law.harvard.edu/tech/rss
    SimpleDateFormat rfc822Format = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss Z", Locale.ENGLISH);

unmappable character for encoding UTF8

I received this error today when compiling a Java program, that has been compiling for quite a long time. Turns out the cause was I switched to the Java 1.5.0_02 compiler, and this one is a little more strict than the previous ones. Sun's bug id 5071879 states this is not a 'bug', but rather a side affect of the compiler being more strict. Generally, your source code is written in 8-bit ASCII, and when the compiler reads the file it has to translate it into 16 bit unicode characters. On *nix platforms, javac apparently figures out which encoding to use based on your LANG environment variable. However, you can also specify a -encoding option with the compiler. Probably the best solution is to use proper unicode escape sequences in your source file. So instead of something like:

char currency = '£'

write

char currency = '\u20A4'

This way you code will compile the same regardless of the users local character set. Where this doesn't make a lot of sense is in comments. Many people like to use the copyright