Dazed & Confused

E-week has a writeup of Rod Johnsons talk at The ServerSide Symposium here. He talks about AOP, need for Standards and the death of in house frameworks. Some of them which he touched upon during the seminar I attended.

Towards the end a point is beeing made about how you should always look at the TCO when using open source. I completely agree, but it is also an extremely difficult judgement to make. If you have two competing frameworks, one commercial and one opensource, my experience says that the commercial should be pretty damn good to justify buting it and paying for support. First of all it costs money to buy, second it costs money for support and third it’s usually harder to find information when you run into problems.

If you buy support from a commercial vendor you will have guarantees about the support. But I’m not convinced you save much time or costs by this. Usually you spend most your time explaining your problem to some tech-person that asks you if you’ve updated Internet Explorer to the newest version. 😉 Beeing able to debug the source and asking questions on the often active forums usually takes a much shorter time than working through the support systems. Maybe I just havn’t seen an effective support organisation at work yet. 🙂

Matt Raible has a post about using Json-RPC here. Also contains links to some other frameworks too. Check the comments for even more.

Internationalisation and character sets can be a pain in the ass. I avoid it as much as I can, and did until today because I reconed Java always runs UTF-16 and that it shouldn’t be a problem. 😉 It does run UTF-16 internally always, but the transition from webrequests into the JVM can be a bit tricky.

We need to accept special characters for all of Europe, and got tons of errors when we finally started testing with Greek characters. I found a couple of articles describing it that helped me solve it:

• Developing J2EE Global Applications : Character Encoding
• Developing Multilingual Web Applications Using JavaServer Pages Technology

It surprised me a bit that the web-client does not specify which encoding it submits back in. If the page that was received from the server and is beeing submitted, is in UTF-8 the client submits back UTF-8. But because it doesn’t specify the encoding on submit, the webserver must know/remember which encoding the pages were sent out in. This is not done by default in J2EE, so the encoding in the request is set to null. Because we run UTF-8 on all our pages (which is recommended practice), we just set the encoding in a filter for each request. If you have different users that might use different encodings you’ll have to keep track of it in a session or something like that.