Java Tips
RegexFieldValidation
JavaNaming
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.
How to test System.exit
Why I dislike mocks
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.
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