ClassCastException on RemotePortableObject.narrow

Been working on EJB with JBoss and Eclipse. I must say the XDoclet (with Ant) was a greate help in generating beans and doing packaging. Despite great tools, I met with a major error that had me stumped for 4 hours.

InitialContext ic = new InitialContext();
Object obj = ic.lookup("...");
SomeHome home = (SomeHome)PortablRemoteObject.narrow(obj, SomeHome.class);

A simple lookup like this, with a ClassCastException on the 3rd line. A class cast means the lookup was successful, someHomeObj is not null, but is not of type SomeHome (which happens to be an interface).

It usually means you’re casting to the wrong type, probably a typo or type confusion. But for my case I checked and rechecked and it was no error. No matter what I did couldn’t make the exception go away. This includes reflecting on the class, superclass and the interfaces of the object, to convince myself the types were correct.

// prints $Proxy157

// prints java.lang.reflect.Proxy

// prints SomeHome, Handle
for (Class c : obj.getClass().getInterfaces())

!!! The class actually implements SomeHome!!! But fails the narrow!!! *fumes* I even tested each line inside the narrow() implementation, and despite having implemented SomeHome, it cannot be cast into or assigned as SomeHome. (instanceof SomeHome == false, isAssignableFrom(SomeHome.class) == false, instanceof org.omg.CORBA.Object == false)

After hours of twiddling I finally found out it was because there were TWO of this interfaces being deployed, one in my ejb .jar, the other in my .war classes. The lookup returned the interface from the ejbjar, and was trying to cast it into the war interface. Therefore even though they had the same interface name (from the same package), they were 2 different classes.

To fix this i adjusted my package build, to EXCLUDE the interface classes from my war. A simple rebuild and the narrow works.

Sun Java goes Open Source!

After 2 years of pressure from the open-source community, Sun has finally decided to open-source Java. Sun was previously worried about compatibility and forking, since people could make their own versions or move towards other goals, making Java lose focus. The prime example was Linux. Some say Sun was afraid of losing control of Java. Whether they are really convinced now that open source is the way to go, or to pull up their stagnant stock prices…

In one of the issues in 2004, the president of the Open Source Initiative (OSI) dropped an open letter to then Sun CEO Scott McNealy touting that Sun is just using open-source as marketing but not really supporting it [1]. He compared Java and Sun to Tiger Woods and his dad, who supported his child by recognizing and letting him achieve his full potential from an early age. He says Sun is restricting Java’s potential, and it would not help even if Sun releases it later, as Woods would not have done it too if he started only later.

The saga went on with Sun spokesman replying to the media (but not to the sender) rebutting each of his points in exact quotes, and OSI president writing a second open letter in response…

Sun have announced that they’re doing it for sure, but its CEO is seeking advice on HOW it should be done.

[3] … ource-java

Get Real! No Perfect Code

No commercial system is perfect – I added “commercial” because you could technically create a one-liner program that prints text to the screen. It matches your specifications exactly to print a line of text, thus perfect code.

Commercial systems, one that you can really sell and earn bucks, are far less than perfect. Bugs occur due to individuals – pure carelessness, lack of skill, too much code to handle for a single programmer; due to team – poor design, poor management, poor leadership, wrong use of tools, technology, architecture, design; due to customers – poor requirements, miscommunication, scope creep; plus so many other reasons for any bug.

Level 1 people still expect bugless code: clients who do not accept products with known bugs, or developers who try to fix every known bug to try achieve the bugless state. Level 2 developers understand this imperfection, but anyhow choose bugs to fix: the most common mistake is fixing bugs that are “easy to fix”. However, that bug may not have a big impact or severity, instead increases chances of introducing new bugs (as described below). High-level people like Eric uses a process to determine which bugs are worth fixing.

Eric approaches bugs in a well-defined process: After a bug is reported and confirmed, a decision must be made to FIX or NOT FIX the bug. This is because:

  1. There is a time constraint to fix all bugs
  2. Fixing a bug may introduce more bugs

The bug is analysed in terms of Severity, Frequency, Cost, Risk. The first 2 relate to the client: what the impact is and how often is occurs. The last 2 relates to the developers: how difficult / how long to fix it and the probability of introducing more bugs.

The recommendation is to plot the first 2 factors on a graph. Always fix stuff in the top right corner and never fix stuff in the bottom left. The factor ratings might change over time, such as a miscalculated risk. Re-visiting these factors when they change can allow us to make better decisions (including rollback bugfixes).

[1] is a condensed version of what Eric wrote in [2] originally.

[1] … 95,00.html
[2] … tions.html

RFID = vulnerable

RFID, short for radio frequency identification, is becoming the de facto identification mechanism recently. There is no need for line-of-sight, can be embedded as passive emitters (no onboard battery), and can be small enough to be implanted into the human skin.

However, like the early Internet stages, security was not a concern and was not considered in its design. This leads to problems especially when many RFID are used in security areas such as building passes and passports. Other uses include tracking shipment, retail stores, library books. The tags may store credit information, which can be used in gaming centers, public transport, petrol stations and toll gates.

Data on an RFID can be easily tapped by a scanner. They are usually unencrypted AND unlocked, meaning they can be read in clear and even overwritten. People have tried tapping a hotel keycard and transferring the information onto a cream cheese (retail food product) with an RFID tag. He then used the cheese to open his hotel door!

Building passes can also be scanned by just walking past the person who keeps the pass in his wallet or bag. The signal can be re-emitted at the building door to gain access easily. Walking along a shelf of library books using an emitter can potentially erase all information in those tags if they are left unlocked. Free gas top-ups are possible and are tried and tested.

I wonder if our EZLink, ERP, NLB, and building passes in Singapore have the same security issues…

VS2005 – First Chance Exceptions

When running CF apps in debug mode using VS2005, I could always see messages like:

A first chance exception of type "System.FileNotFoundException" occured in mscorlib.dll

Why are the core libraries throwing exceptions and how to avoid them? It turns out that first chance exceptions occur whenever exceptions are thrown (duh). If they are caught (with a try/catch clause) the application continues to run normally, but the debugger will print that line into the output. If the exception is uncaught, the debugger is notified again and the application breaks into debug mode. This is known as “second chance exception”. So far from what I see, it means you cannot avoid getting the first chance exceptions.

According to the links below, VS can be configured to react differently at the chance exceptions. Different actions may be taken for different exceptions or exception groups (exceptions hierarchy). … 38061.aspx … ptions.asp

Java Puzzles

Nothing new for a week, but saw a set of puzzles which attempt to promote “good” programming and awareness of bugs that may crop up when bad programming practices are applied.

Some of the morals in the 8 puzzles include:

  • Avoid mixed-arithmetic computation
  • Use parenthesis to make clear your comparison intention
  • Use .equals() for object comparison instead of ==
  • Do not depend on interned string for program correctness
  • Do not assign to a single variable twice in a single statement
  • The postfix ++ operator increments the value, but returns the old value.
  • Document your intention when using & and |. Usually && and || should be used.
  • Never use exceptions for normal flow.
  • Avoid complicated initialization sequences, choose EITHER lazy or eager init, but never both.
  • int arithmetic overflows silently.
  • Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE
  • If you can’t see a method, you cannot override it.
  • Don’t use background threads in initialization – leads to lock-free deadlock!


I tried OpenID last month if i remember correctly, after I saw it in LiveJournal. Basically I searched for a PHP OpenID server solution and “installed” it on my server, and set up an identity for myself. I tested the identity by using it on LiveJournal comments. LiveJournal is the main website that supports OpenID, though some other sites are beginning to offer OpenID as an alternative authentication mechanism.

OpenID asserts that you own a particular URL, meaning it authenticates your identity. It does not provide trust or authorisation. It is advertised as a true decentralized authentication system, as opposed to other central authentication system like Microsoft Passport. We’ll look at how it works, and followed by all the other benefits that OpenID says it achieves.

From the user point-of-view, he accesses a web site which requires his identity. An OpenID logo is available with a textbox for him to type his OpenID identity. He submits his identity URL and his identity server login is displayed. Once he logs in using his identity server’s id/password, he is returned to the original web site and he is authenticated with the identity.

Behind the scenes, once the original web site picks up the identity URL, it accesses that URL to pick up the identity server location inside the URL’s header. The site redirects the user to the identity server site, along with the URL that the identity server is supposed to return to after authentication. The identity server takes over, authenticates the user, and redirects the user back to the URL given by the original website, along with a “key”. The user submits this key to the orignal website, and the web site verifies this with the identity server, to check if the key is valid. The original web site is then satisfied that the identity URL provided belongs to the user.

The good things about this are:
(warning: example URLs are ficitious, they may not represent actual web sites)

1. Only HTML required for identity URL.
Any web page can be your identity URL, you need not have PHP or ASP running, just HTML. This is because you just need to insert a special tag in the HTML section, which points to your identity server. The identity server can be total different from your identity URL.

E.g. your identity is where you can only put HTML pages, and you registered your OpenID with

2. Single ID
The OpenID can be used on any site that supports OpenID, it does not require you to have an account with the site you are visiting. You do not have to sign up or remember multiple passwords. You just need one OpenID identity.

E.g. You leave comments at using you OpenID registered at, without a livejournal account.

3. Decentralized autentication, Freedom to choose identity server
There is no central OpenID server that stores all your login information. All of it is in your identity server, which can be run by any company. Even if your identity server goes out of business, or turns evil and start charging $, you can switch to another OpenID server, but preserve your identity URL by just changing the tag in you to point to the new server.

E.g. You identity is and you use as your identity server. Later you change your server to, but still use as your identity.

Yet with all these benefits, adoption is slow. Use of OpenID is now still only seen in blog comments. This is because while OpenID can establish you own that identity, the web site has to TRUST the identity server. I can easily set up my own identity server, which authenticates myself irregardless of the id/password I use. (tried and tested). However, once a trusted network of OpenIDs is set up and used by popular web sites, it may be possible to become a widespread identity system.

Microsoft Enterprise Library DAAB (Data Access Application Block)

For introduction sake, the Microsoft Enterprise Library is a set of open-source libraries that developers can freely use, extend, and modify to build better “enterprise” applications [1]. (weird isn’t it? Microsoft — Open Source, they probably realized that few MS developers really knew how to code properly) The library contains a suite of classes (known as application blocks) for the following areas:

  • Caching
  • Configuration
  • Data Access- Cryptography
  • Exception Handling
  • Logging and Instrumentation
  • Security

The DAAB is one of the blocks, and supposedly simplify database code by abstracting it from

SqlConnection myConnection = new SqlConnection("..");
SqlCommand myCommand = new SqlCommand("..", myConnection);
SqlDataReader reader = myCommand.ExecuteReader();


Database db = DatabaseFactory.CreateDatabase();
IDataReader reader = db.ExecuteReader(CommandType.Text, "..");

Not much of a difference, the important thing is that the implementation is now more database independant, and configuration of using which database are stored in complex XML files (using the Configuration Application Block).

The old syntax was inherited all the way from DAO days, and I’m expecting they’ll be shifting this Object Oriented Enterprise way like DAAB into Vista next time. Performance-wise, this blog says DAAB vs DataAdapters give identical results [2]… anyone else ran different tests?

Java developers have absolutely no problem with this, because from Day one they were taught to use DriverManager.getConnection() and the Connection, Statement, ResultSet interface instead of ODBCResultSet or OracleResultSet.? 🙂

Connection conn = DriverManager.getConnection("...");
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("...");

[2] … e75d1.aspx

AJAX – Asynchronous Javascript And XML

A discussion on using AJAX instead of traditional binding to build datagrids prompted me to write this. AJAX, still considered new technology, is being tried out by many developers, but sadly in more wrong ways than one.

Since AJAX involves Javascript and XML, it can be used in most web-based projects, including Java (servlets), PHP, .Net, etc. AJAX allows creating a XMLHttpRequest using Javascript and call server-side functions and returning XML responses. The response can be used to update the GUI using DHTML without refreshing the whole page.

So far the most common example I’ve seen is free-text auto-completion, such as sending a web-based email. The user types a few letters and a combo-box like list appears below, allowing the user to select a completed email address retrieved from the user address book in the server.

Other valid uses I’ve seen is using AJAX to update RSS tickers (starbean forum), and using AJAX to update dependant combo-boxes (selecting category updates list of products). Generally I feel that use of AJAX should be for a updating information on a page that otherwise required a “postback” type of update in Web 1.0. (btw if you’re not sure about Web2.0 or Web1.0 go google it up)

Talking about all these good points, here comes the bads, and WHY I personally think it’s bad:

1. Using AJAX to emulate server-side include (eg separate menu.html and use AJAX to load menu.html on every page)

AJAX is aimed at updating the UI after it has been displayed. To use AJAX to load another page during onLoad is making the client-side browser make another server request, during the server request. The code required (at the moment) is also much more complicated and bug-prone. If the server software (such as IIS/Tomcat/Apache) supports server side includes (SSI), PLUS most of the time the page already requires generation by the server, why not use it? Using SSI causes the page to be created completely on the server side and sent to the client directly.

2. ELIMINATE page refresh by loading all links using AJAX (eg. all links and form submits are AJAX calls that rewrites the current page)

For what? Don’t like the “Loading …” in the status bar? Maybe you shouldn’t be using web then. This requires the entire site’s logic to be embedded in one single page. You get the idea.

3. Databinding using AJAX

This point is arguable, it depends on the implementation. If the purpose is to update the table after it is displayed, it may still be justifiable. But if the binding is done during onLoad, it violates the same purpose as point 1. BTW I don’t think it should be directly binded. Instead AJAX can be used to download updates of the table periodically.

4. Server-side client-side validation

OK this came from thedailywtf, but this guy really doesn’t know what he was doing. He somehow felt the client side date validation was so difficult, that he wrote his Javascript validation function to make an AJAX call to the server, which implemented a Web Service that accepts a String and returns whether the input was a valid date. This could have been accomplished by using CLIENT-SIDE javascript, and various FREE ready scripts are available for download. For one good thing, AJAX works well with web services as they communicate in the same language – XML, but one bad thing is enough to kill many other goods.

If you think otherwise, drop me a comment.

SWT & JFace – Standard Widget Toolkit

SWT is an alternative to AWT and Swing, supported by the Eclipse community. Together with JFace it can be used to build RICH clients. SWT use native widgets, yet code is portable to other platforms. This is achieved by a JNI call-through to the OS library [1]. Widgets are simply Components and JComponents in AWT/Swing, which includes text boxes, push buttons, etc.

JFace provides a higher-level API for SWT widgets, such as an ApplicationWindow or Tables and Trees backed with a data model. JFace also allows direct access to the underneath SWT widgets, so that developers can easily change whats beneath. The whole API is very exposed, in fact, even the threading model and event loop is totally exposed. Whatever thread that created the display becomes the GUI thread, and other resource extensive tasks have to be thread-spawned by the programmer hiimself. The good thing is SWTException is thrown if UI manipulation was not done in the GUI thread.

For existing Swing developers, [2] provides an extremely simple introduction, with several tables to show the relationship between Swing components and SWT Widgets. Also see [3] for a nice list of widget screenshots.

[1] … ign-1.html
[2] … jface.html