There are many candidates available now, all with something problematic about them it seems. Bit of a PITA.
On my radar are the following:
The P900 sounds great, but for the Memory Stick slot that can only handle up to
128MB cards. The Treo 600 has a terrific form factor, but comes without Bluetooth or a high resolution screen. In addition, Handspring is not confirming that a
quality J2ME implementation will be available for it.
Ideally, I’d have a phone that can handle the new North American frequency, 850MHz, in addition to the frequencies used outside NA. Good Java support is also very important to me.
Working with the XML specifications for Java has always been a pleasure for me.
Yes, some criticise them fiercely, however I feel they are mostly adequate for t
he task.
I recently encountered a problem with JAXB; the
specification requires two behaviours which I find to cause integration hassles:
- You must use ObjectFactory to get new beans,
- ObjectFactory creates beans with null references
Both issues crop up when using JAXB with a container such as PicoContainer, Spring or anything else that expects to be able to instantiate empty beans without special knowledge.
The second issue becomes a difficulty when using JAXB beans with “dot notation”.
For example, you cannot simply create an empty bean and then try and set a property like car.engine.timing since the reference to engine is null until
you create an Engine object and assign it. Would it be more appropriate to recursively populate the bean?
George Datuashvili mentioned on the JAXB mailing list:
“In future JAX-RPC 2.0 will be based on JAXB 2.0, and since
JAX-RPC already requires EJB bindings, your issue will have to be resolved by JAXB or JAX-RPC working groups.”
That thread also talks about using java.lang.Proxy, which I find very interesting.
While attempting to deploy an EJB jar on a fresh installation of JBoss 3.2.2 I received the following error: (Sorry about the long lines.)
java.lang.NoSuchMethodError: org.apache.bcel.generic.InstructionFactory.createNewArray(Lorg/apache/bcel/generic/Type;S)Lorg/apache/bcel/generic/Instruction;
Looked like a version mismatch to me, which would be wierd because JBoss should be using the version of Apache BCEL that shipped with it, no? But what if we have a traitor among us?
I quickly remembered all the cruft that the Java Web Services Developer Pack wanted me to install in the JRE’s endorsed directory, might something there be the culprit?
Indeed, it seems that xsltc.jar contains a version of BCEL. (A rant for another day: even if it makes people do more deployement work, please do not include dependancies in your jars.) I believe that some versions of the Xalan jar also include BCEL, so beware.
Solution: I hope this doesn’t have any side-effects, but you can solve the immediate problem by copying the version of BCEL that ships with JBoss 3.2.2 into your endorsed directory. The BCEL jar is probably located at $JAVA_HOME/server/default/lib/bcel.jar and you want to put it in $JAVA_HOME/jre/lib/endorsed.
How little things can become time-sinks.
Thanks to Rod Johnson’s book, I now have a good solid method for performing test-driven development. Previously, it was always cumbersome and required too much work to easily convince others. His method is simple:
- Write an interface for the class (You are coding to interfaces, right?)
- Use an IDE or script to create a dummy implementation of the interface with methods that either:
- write a failing test that checks for the desired behavior
The test will now compile and run. (Obviously it will fail!) Such a simple procedure makes test-driven development much more palatable. Thanks Mr. Johnson!
If you are not familiar with JUnit, now is the time to check it out.
I also suggest reading the book, it is very worthwhile. (“export one-on-one J2EE Design and Development”)
Keeping track of the tld files for a framework or API is an error-prone process, very much so when using a framework like Struts or JSTL that has multiple tag libraries .
A better solution is to package the TLD files along with the rest of the library’s classes and other resources. This is actually mandated by the JSP specification, but who reads specs anyway. IBM developerWorks has a great series on JSP best practices, or which one of the articles explains this technique:
http://www.ibm.com/developerworks/java/library/j-jsp09023/
The short explanation is to put the TLD files in the META-INF directory of the jar file and reference them in your deployement descriptor like so:
<taglib>
<taglib-uri>http://www.newInstance.com/taglibs/site-utils</taglib-uri>
<taglib-location>/WEB-INF/lib/newInstance-taglib_1-1.jar</taglib-location>
</taglib>
Some of the other articles in the series are worthwhile as well.
In addition to this simple use of advanced jar packaging, there is a multitude of other abilities that are completely ignored, I will post some more on this subject this week.
Since I do not believe that Struts is the be all and end all of application frameworks, I’ve been looking around at the competition. There are quite a few. Since I believe that this IoC (Inversion of Control) thing is a Good Thing, I’ve restricted my search to those frameworks that manage not only the “actions” of an application but also it’s components.
Currently, there is the following:
I’ve been hearing some Bad Things about WebWork lately, nothing substantiated though.
Another possibility is too do something homegrown on top of PicoContainer.
In then end, I realise that it is a very difficult topic. But I have a plan: I want to put together an evaluation sheet for frameworks. Please email me your thoughts and I will condense them into another posting.
One of my core compentencies is researching and implementing development tools. Think version control, Ant, Checkstyle, etc. Even more APIs and frameworks such as Struts, WebWork, Hibernate and Quartz fall into this category. In addition, development system setup with tools such as Tomcat and JBoss can be very time-consuming when your primary focus is the development of your product. Collaboration techniques such as shared whiteboarding, instant messaging and the use of development wikis and weblogs is also a much neglected but important part of running a successful team.
I am a big believer that proper use of development tools can be a very large, even sometimes the largest, factor influencing the outcome of a project. Simple tools can prove to be immense time-savers when implemented properly and used efficiently.
So, would anyone reading this find a service that analyzes your needs, recommends tools, implements them and trains the developers useful?