Among the new features available (enhanced for loop, generics) in J2SE 5.0 (or 1.5, or Tiger) is the annotations functionality. I have always been hoping to come across simple introduction to such stuff and it came in this issue’s Tech Tips.
Annotations allow us to associate metadata with program elements: metadata is information that describe the program elements, and the elements may be methods or member variables in a class. Annotations are defined using a @xxx tag before the element.
The most common and obvious use is the @Deprecated tag. This tag declares the method as deprecated: it is outdated and kept for backward-compatibility. When the method is called from another class, a warning will be generated.
Other annotations defined in Tiger are @Override and @SuppressWarnings. @Override insists that you are overriding a method in case of a typo or wrong method signature, similar to C#’s Overrides modifier. @SuppressWarnings will tell the compiler not to tell you about certain warnings such as deprecation or unchecked casts in the method. It can be used with some options, such as @SuppressWarnings(“fallthrough”). This looks a lot like .Net’s annotations.
In addition, the tip mentioned that custom annotations may be defined, probably something like XDoclet. That could be something else I could learn in the future. The tip also contains a link to a book “Effective Java Programming Language Guide” by Joshua Bloch, which contains 57 Java tips. Well likely could be the next tip review here.
“If the cost of breaking into a system is significantly higher than the benefits gained by attacking the system, and the cost of protecting the system is lower than the value of what is being protected, then we call a system secure.”
– Jian Zhong, senior software architect, ActioNet Inc.
Although posted once on the Starbean forum before, I felt that this quote is very apt to justify for how much security is desired. Perfection cannot be achieved; there is no unbreakable system. Spending too little on security can compromise the system, overspending waste resources, time and money, with no further benefits.
 http://www.javaworld.com/javaworld/jw-0 … ee-p3.html
Javamail is the standard answer for mail access using Java. Currently supported protocols are SMTP, POP3 and IMAP. In short it means you can send outgoing mail using SMTP, receive email using POP3, and I’m not familiar with IMAP, though I remember having it in my Networking course. I think IMAP’s mails are stored and manipulated on the server, as opposed to POP3 mails which are downloaded (generally).
Using the classes was rather easy to me, partly because I am familiar with the SMTP/POP3 protocol (telnet and manually send/receive mails). Might be a good experience for you to try it (the telnet) too, to understand protocols on top of TCP. Online examples also help me to cut&paste code quickly.
Once peculiar thing is that Javamail depends on the JavaBeans Activation Framework (JAF). I’ve seen it around for some time, but never really knew what it was and what it does. I finally learnt that the activation framework handles MIME types (but how?) and so was useful in the JavaMail package. JavaMail was the only library that really used activation for a few years until web services came along. Web services which uses SOAP calls had MIME types as their encoding.
XML has grown to become important over the years, and it is natural that Java gradually adds support to it. Started from external packages in JDK1.3, core JDK1.5 now has JAXP 1.3 in it. JDK1.4 had JAXP version 1.2. Now java.net offers JAXP 1.3 as a standalone package so that JDK1.3 can make use of JAXP as well. However the bundle has no technical support (use at your own risk).
Transformers in the JAXP package allows you easily transform XML from one form to another, though I’ve only tried transforming it to a file. Handy output properties during transformation allow formatted output to make it more readable.
This post is purposely made very abstract — commenting very generally on JAXP. However it should contain enough keywords to allow searching for how to perform certain tasks. Dwelling into XML, DOM and SAX can potentially drag very long, with little benefits since there’s so much information out there already.
Other topics in the book did not have significant points (at this moment in time) for me to bring up. However certain bits and pieces keep recurring throughout the topics and are worth mentioning:
Consider Internationalization From the Start
If you’re doing an “Enterprise” application, always I18N your Strings. Especially on the JSPs. For database design, locale-specific fields should be normalized to another table with and additional locale column.
Design First, Optimize Later
Make sure you have a good design before you think about how to make your code run better. Don’t keep optimizing your code, let it go once it works (i.e. passes test case). Instead of worrying how well your code runs, think of the other business functions you have yet to fulfil.
In the end the code may not need to be optimized (maybe due to good design). Even if there is a need to, good design makes it easy to perform such optimizations. If optimization is considered first, the benefit may not be necessary, or further optimization is difficult later and hindered by poor design.