Archive for the ‘java’ Category
Thursday, July 6th, 2006
I’ve been whining for quite a while to some friends and coworkers about how checked exceptions have ruined and will continue to ruin our codebase, because it leads those lesser disciplined developers to doing blindly either “throws Exception” or “catch(Exception)”. So naturally I found it very interesting reading Paul Watson’s blog on Checked Exceptions, and the articles collected there. Just wanted to echo to those.
Posted in java | No Comments »
Thursday, July 6th, 2006
I have been wanting to give postgresql a try for some time. The reasons are manifold – the clean coming BSD license for a starter, a somewhat more standard compliant SQL engine compared to MySQL and even some commercial products, etc. But my postgresql experience takes a blow right in the face at the first attempt to start the server – more…
Posted in LAMP, java | 3 Comments »
Sunday, June 4th, 2006
I’ve been using the Panel component in YUI(Yahoo UI Library) to build an AJAX page, which as part of the whole web application is wrapped by the standard boilerplate via sitemesh. It worked out all well and fairly straightforward – well, at least in Firefox and Opera, but in the dreaded, we-render-pages-with-lots-of-imagination IE 6, the panel showed up with a totally messed up layout, and worse, under the modal mode the entire page, including the panel itself, was masked with a 0.5 opaque layer and refused to take any input. more…
Posted in java, web-design | 3 Comments »
Sunday, May 7th, 2006
Spring 2.0 supports injecting beans into an arbitrary POJO, which isn’t necessarily instantiated by a Spring bean factory. This powerful feature is mostly used in injecting into domain objects whose life cycle is usually managed by ORM tools such as Hibernate. But we don’t have to stop here, e.g., JSP tags can also be injected the same way. Here’s how: more…
Posted in aop, java, spring | 8 Comments »
Thursday, May 4th, 2006
Reading The Daily WTF has lately become my, well, daily entertainment. Most of the stories are like the IT version of Dude, Where’s My Car. But, today’s entry, Hungry, Hungry HIPAA, did not read funny to me at all. Here are two of the most insightful commentaries from the readers showing why it did not -
“This goes to show that no matter how secure your technology may be, it can be completely circumvented by the simplest (and dumbest) of human actions.” -RyanD
“When I see things like this I get a real urge to contact the responsible autority and get those idiots removed from the IT genepool. This is actually as scarey as it is funny. There could be muppets like this working at your bank!” -voyager
Posted in fisheye, java | No Comments »
Saturday, April 22nd, 2006
Chintan Zaveri did some research and posted a rather nice collection of portlets he found as a comment to this JBoss Portlet & Liferay review I wrote a while ago. I felt that it was informative enough to become an entry by itself. So here it goes, with a little cosmetic formatting. more…
Posted in java | No Comments »
Monday, April 17th, 2006
I hacked together a simple JSP page that allows remotely submitting and executing BeanShell commands in any servlet container. A primitive “allowed” list is built-in to control access to the page. By default only users from the localhost can access. more…
Posted in java | 3 Comments »
Sunday, March 19th, 2006
I have recently been asked to review some development team’s Java coding convention. Just when I was about to flip over the page that says “the maximum line width is 80 characters,” I had this sudden realization that we were actually in the year 2006 now. This is the age in which we use GUI IDE’s that are capable of displaying and printing over 100 characters per line at normal font sizes, and the age in which we tend to use long names for variables, methods, and classes. Why are we still limiting ourselves to the 80-character limit which is basically a relic from when we had to telnet to a server, and vi our code?
Posted in fisheye, java | 6 Comments »
Sunday, February 19th, 2006
Class java.lang.Package provides a few methods that returns certain manifest attributes such as Specification-Version or Implementation-Vendor. These attributes are loaded from the jar file in which the package is located.
The gotcha comes when you have the same java package spreaded over more than one jar file. Since there is always only one Package instance for all the classes belonging to this package (within each classloader’s scope, of course), it’s pretty much up to a classloader implementation to choose which MANIFEST.MF from all those jar files should speak for the entire package. Usually, for the obvious caching reason, the first one wins.
The worst scenario happens when you have an exploded class directory at the beginning of the classpath, in which a single class from package foo.bar (say a patch class) would cause all the classes in foo.bar, albeit well contained in a jar themselves, to lose their manifest attributes.
The “phew” part in this story is this: the Sealed attribute is an exception to the above behavior – at least in the case of the Sun JRE. An exception is always thrown properly no matter when it’s a sealed jar loaded after an unsealed jar containing the same package or the other way around.
Posted in java | 2 Comments »
Tuesday, February 14th, 2006
Hibernate 3 added a new persist() method to the Session interface. It came from the EJB3 Entity Manager spec. In case you are also wondering whether to migrate to it or just stick to the good old save() method to insert a new object, here’s what I found out:
A discussion on Hibernate Forum
A JIRA ticket
Posted in hibernate, java | No Comments »
