Archive for May, 2006

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.

Comments (2)

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