JMF allows you to work with media – audio and video. Working with here means input (reading in from file/device), processing (encoding/decoding/multiplexing) and output (to file/network/screen).

Nitty-gritty details are mostly shielded from the programmer, yielding a clean interface for use. In fact once we completed our audio streaming, converting it to video streaming was almost a one-liner change for the Format class. However since we need to separate the components clearly (content vs transport), we had to try tear JMF apart. In fact JMF handled so much of RTP that we just need to give it a ip/port and off it goes.

The flexibility of the framework theoratically allows all forms of media to be processed, however it is currently limited to certain codecs and formats, maybe due to the need to interact with native hardware/OS, or licensing issues. We had some problems interacting with webcams, likely issue to be the webcam drivers are application specific, only their own apps know how to access the webcam. Hopefully more webcam providers make their cams OS-generic, such that it can be recognized by Windows. This way it is more likely JMF will be able to detect it.

Another issue we bumped into is that JMF binds to AWT. For displayable components like Video visual and Video controls, it is returned as an AWT component. Since we use SWT it could be a chore to code bridges.

Because of performance, JMF comes in certain performance packs, which probably have certain algorithms in native code so it runs faster/better by making use of the OS/hardware. (accelerator? processor opcodes?)

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.

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).

JAXP contains API to CRUD XML, both DOM and SAX. Thats alot of acronyms in one sentence… For DOM you create or obtain a Document, then manipulate elements and attributes within the document. DOM manipulation works generally the same for both Java and Javascript, since they adhere to the DOM specifications. For SAX you hook up handlers to perform tasks when start/end tags are encountered.

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.