IBM to buy Sun?

Lots of chatter this morning about Sun trying to sell itself to IBM. This of course could have many indirect impacts. Wither Netbeans, Glassfish and even Swing? This could affect the balance of power in the JCP back toward frameworks you need to buy. On the positive side I guess we might see aspects in JDK 1.7+.

In general though I can't see a Sun under IBM being as much fun, although possibly more profitable. I do wonder if IBM will understand the consumer part of the business or just run it down, it would be a shame to see project such as JavaFX still born. (Although some would argue this is already the case)

Perhaps going forward IBM might spin of the core java stuff into a separate foundation along the line of Mozilla that other companies can support. This might be the best bet for the long term future of Java as a platform.

Interesting times...

Global URI re-writing with jax-ws-catalog.xml

Spending a little bit of time looking into jax-ws-catalog files in order to add support for a future version of JDeveloper. JAX-WS appears to have good support for the OASIS Catalog specification: so as well as providing indirections for individual URLS:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="system">
  <system systemId="http://localhost.localdomain:7101/Application1-Project1-context-root/HelloPort?WSDL"
          uri="http://production:7101/Application1-Project1-context-root/HelloPort?WSDL"/> 
</catalog>

the catalog can also be used to re-write all URLS:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="system">
  <rewriteURI
    uriStartString = "http://localhost.localdomain:7101/"
    rewritePrefix = "http://production:7101/" />        
</catalog>

Although you could create a catalog file for WAR and JAR in your project, you can just create the file once at the EAR file level. For JDeveloper users this can be created directly under "Application Resources".

This catalogue file will be used by all the proxies, you will find that due to a bug in weblogic the service will fail to deploy if the original URL is not available. So for the moment this is a useful hack for non-production environments only with weblogic; but will probably work fine for other application servers. Also do remember this is only going to work for JAX-WS services.

JDeveloper code editor "rabbit in a hat" magic trick

Sometimes it is not the bug itself; but how you report them that gets the smile. Take for example this test case for a bug in JDeveloper provided by fellow web service team member Alan Davis.

Create a new java file called Class1 and paste in the following text.

package project1

public class Class1
{
   public void method()
   {
     /** */
     class Foo extends ArrayList
     {
         /*
          *          /| |\
          *         | |_| |
          *         | |_| |          And for my next trick,
          *         | . . |          not only will I make the
          *         \  @  /          rabbit disappear, but
          *       ===========        I will make the hat
          *       |_       _|        vanish too...
          *         |      |
          *         |      |
          *         |______|
          */
     };
   
     doIt(); // Comment
   }
   void doIt() {}
}

Then accept the import assistance on the ArrayList import. Ta-daa. For weeks Alan was wondering why we kept on deleting his code... now we know it was just a magic trick. Fortunately you need a very specific combination of code structures and comments to exercise this bug so you shouldn't see this using 11 day to day.

Sci-Fi Season on UK Radio

Lots of good stuff here including a dramatization of "Rama" and this week the "Death of Grass". For people outside of the UK avoid the iPlayer links; but otherwise I think you can hear most content.

orapki, made up of bits installed with JDeveloper 11

You may for whatever reason want to use orapki to examine the contents of cwallet.sso; but find that JDeveloper doesn't come with the executable. It seem though with the right jar files you can get this tool back. (Replace 11.X.X with the version of JDeveloper you are using.)

[gdavison META-INF ] java -cp %ORACLE_HOME%/jdeveloper/modules/oracle.pki_11.X.X/oraclepki.jar:%ORACLE_HOME%/jdeveloper/modules/oracle.osdt_11.X.X/osdt_core.jar:%ORACLE_HOME%/jdeveloper/modules/oracle.osdt_11.X.X/osdt_cert.jar oracle.security.pki.textui.OraclePKITextUI wallet display -wallet cwallet.sso

You get an output like:

Oracle PKI Tool : Version 11.1.1.0.0
Copyright (c) 2004, 2009, Oracle and/or its affiliates. All rights reserved.

Requested Certificates:
User Certificates:
Oracle Secret Store entries:
oracle.wsm.security@#3#@keystore-csf-key
Trusted Certificates:
Subject:        OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Subject:        OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Subject:        OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Subject:        OU=Secure Server Certification Authority,O=RSA Data Security\, Inc.,C=US
Subject:        CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US

Note there might be jar file missing as my testing was far from exhaustive, let me know if you find a problem. Actually extracting the password, which is what started me down this track, is not possible with this tool: for that you need java-ju-ju and that is a topic for another day.

Remember that as used in JDeveloper cwallet.sso only obfuscates the passwords and doesn't provide full security as the wallet has no password by default. You have to secure access to the wallet if it contains anything important.

Possibly going to JavaOne 2009

We, my self and Manoj, have had a revised version of the Asynchronous Web Service paper we presented last year to be accepted at JavaOne 2009. Got to look at whether I can get travel approval in this economic climate though otherwise Manoj will be presenting on his tod. Hopefully I can get some time to catch up with some friends while I am there.

Busy fixing bugs in JDeveloper at the moment. In case you are interested we have a special song we sing when fixing bugs and it sounds a bit like this. (Requires an install of iTunes, possibly a mac, this might also work.).

Building JDK 7 on a mac

If like me you are stuck with a bunch of 32bit Mac or just want to play with JDK 7 on your 64bit intel mac then you might like to consider building the OpenJDK version from source. This will get you a X11 based version of Java; but it will do the trick for most purposes.

Before you start the instructions here you might like to make sure you have the following dependencies:

• X11, the installer is on your OS install disks
• XCode, about a gig download required for mac and a bunch of header files.
• MatPorts, so you can download and install mercurial
• SoyLatte 1.0.3, so you can boot strap the build process. Not required if Apple has bless you machine with its own JDK.

The entire process should take around 3-4 hours including downloading all the bits and not paying attention. Future rebuild should only take around ten minutes. Couple of things I tripped up on though: "fclone" is not a typo it is an extension to mercurial added by the previous step; and when copying build.sh from the wiki page you might find you end up with spaces after the "\" line separators. Remove them will a tool of your choice.

Now one of the reasons I was doing this was so I could run the latest version of JDeveloper on my Mac, I am still having trouble getting the installer to run due to it incorrectly claiming I have disk space issues. I am working on a solution for that. I am using JDK 7 as this is where are the development is at so in many ways it is more capable and stable than the aging SoyLatte 1.0.3 build.