Wednesday, December 10, 2008

Reflection with Generics

I ran into some pretty interesting reflection problem today, and thought to jog down some notes here. In Java Generic, concept introduced with Java 5, is implemented pretty much as a compiler trick which performs the type check then generates the same byte code as the non-generic code, and inserts casts for the generic code automatically. The following two code samples will generate identical byte code by the compiler.


void doSomething(List ids)


vs.


void doSomething(List<Long> ids)


* That's also why code like: list instanceof List<Long> does not work in Java since this information is not available at runtime

So now lets imagine you try to use the reflection to find the method with a List<Double> at runtime, you will actually be able to find the method doSomething(List<Long> ids) and you can even invoke the method without any problem since at the byte code level this method is really taking a non-generic List. Now the problem arise, in the method since you already specify the generic parameter thus you probably will not check the element of the list again but rather use foreach loop as shown in the following code sample:


for(Long id : ids){
...
}


This code works fine without reflection since the compiler will force the type check, but while working with reflection you can basically pass in any List at runtime, hence you will get a class cast exception at the start of this loop. Fortunately the generic type information is not all gone at the runtime. They do get compiled into meta information for the class so using reflection you can retrieve this kind of information at the runtime, although I have to say I am not a big fan how this generic related type API was designed in the reflection package, its very inconvenient to use to say the best. If you are interested IBM Developer Works has an excellent article on this topic.

In summary, keep in mind generic is just a compile time transformation and be very careful when using reflection with generic.

Wednesday, December 03, 2008

Implement Flash socket policy file server

Recently I had to implement a Flash socket policy file server. Here are a few things I discovered while creating the server.

Why socket policy file server?

Since Flash player 9 you can no longer use the HTTP based crossdomain.xml file to specify cross-domain policy for socket based server as part of the on-going security enhancement from Adobe. Therefore a specialized socket file server (default on 843 for master policy) needs to be created to return the policy file(s) for the socket based client. See Policy file changes in Flash Player 9 and Flash Player 10 for more details.

Whats the expectatoin?

The basic idea behind this file server is fairly simple. The server will wait for the policy file request from the Flash player sent directly by the Flash player. The policy request is just a string of followed by a NULL byte (00), upon receiving the request the server will return the content of the policy file.

Whats the catch?

1. String chararacter set

In Adobe's document there was no mentioning of the encoding charset for the returning string, and based on my experiment I found the Flash player did not like the UTF-8 encoding in Java. Probably because Java DataOutputStream uses a modified UTF-8 encoding. At the end I found that ISO-8859-1 worked out pretty well with the Flash player, and since your policy file should not contain any unicode character anyway I think this is a pretty good approach.

2. Write timing

One interesting thing I found is although Adobe mentioned in their documentation the request handling should be in the following sequence:
  • Receive request
  • Verify request
  • Write policy content
  • Close socket
I found the Flash player is happy even if you just simply write policy content as soon as the socket is accepted. Although if you are writing your own file server you probably should stick with Adobe's spec not only because it makes sense but also because the undocumented Flash player behavior might change without notice in the future release.

3. Close your socket

In Adobe's documentation it mentioned that the Flash player will close the socket as soon as it received the policy file, but based on my experiment it seems that Flash player performs less consistent if the server does not close the socket right after the content is written.

Hope this information will help you save some time while implementing your own policy file server.


More reference: