NoSuchAlgorithmException: SunTlsRsaPremasterSecret after Java upgrade on Mac OS X

I've this weird problem after upgrading to new Java version on Mac. My (maven) project ran OK from command line but got the "SunTlsRsaPremasterSecret" error in Eclipse.

Caused by: java.security.NoSuchAlgorithmException: SunTlsRsaPremasterSecret KeyGenerator not available
at javax.crypto.KeyGenerator.<init>(DashoA13*..)
at javax.crypto.KeyGenerator.getInstance(DashoA13*..)
at com.sun.net.ssl.internal.ssl.JsseJce.getKeyGenerator(JsseJce.java:223)
at com.sun.net.ssl.internal.ssl.RSAClientKeyExchange.<init>(RSAClientKeyExchange.java:89)

The solution was to remove Installed JREs in Eclipse configuration and add them again (using the "Search..." button).

Java for Mac OS X 10.5 Update 7 causes problem with Eclipse SVN

Yesterday I updated my Mac Java version to Update 7 - it's always better to use new things, isn't it ? :) Alas, after the upgrade my Eclipse Subversion plugin stopped working - every attempt of interaction with SVN (browsing, commit etc) caused freezing.

After long and painful investigation I've narrowed the problem: it occurs when using SVNKit with some (not all) SVN servers that use HTTPS client certificate authentication. It turned out that Java Update 7 fixes a security vulnerability by disabling SSL renegotiation. As the server tries to renegotiate SSL session and client (using JSSE) refuses, the whole process enters infinite loop with SVNKit log showing "javax.net.ssl.SSLHandshakeException: renegotiation is not allowed".

The workaround is to re-enable SSL renegotiation in JSEE (yes, this means exposing yourself to the vulnerability again). To do this, set the JVM option allowUnsafeRenegotiation:

-Dsun.security.ssl.allowUnsafeRenegotiation=true

In case of Eclipse, it can be set in eclipse.ini.

Loading Java properties in UTF-8

One of the latest stupid problems I've encountered: Java *.properties files are always loaded in ISO-8859-1 encoding and there is no way to change that. But in our project we wanted to have them in UTF-8 so that non-Latin files could be human readable. We use JSTL "fmt" tag library which loads messages from *.properties files (and guess in which encoding).

The simple solution I've come up is build-time native2ascii conversion. This can be done using the native2ascii-maven-plugin. This example shows what to add to pom.xml (assuming that your *.properties files are in src/main/resources/l10n):

<build>
 ...
 <resources>
     <resource>
         <directory>src/main/resources</directory>
         <excludes>
             <!-- exclude resources handled by native2ascii-maven-plugin (otherwise they will be overwritten again) -->
             <exclude>l10n/*</exclude>
         </excludes>
     </resource>
 </resources>

<plugins>
 <plugin>
     <groupId>org.codehaus.mojo</groupId>
     <artifactId>native2ascii-maven-plugin</artifactId>
     <executions>
         <execution>
             <goals>
                 <goal>native2ascii</goal>
             </goals>
             <configuration>
                 <src>src/main/resources</src>
                 <includes>l10n/*</includes>
                 <encoding>UTF8</encoding>
             </configuration>
         </execution>
     </executions>
 </plugin>

BigDecimal gotchas

The BigDecimal class is full of gotchas. Today's gotcha is:

new BigDecimal("1").equals(new BigDecimal("1.00")) == false

To avoid this problem, use compareTo instead of equals.


Another nice gotcha is:

new BigDecimal(1.23) == 1.229999999999999982236431605997495353221893310546875

The correct way:

new BigDecimal("1.23")