Archive for August, 2006

Effective Java (Review)

4. Avoid creating duplicate objects
5. Eliminate obsolete object references

12. Minimize accesibility of classes and members

21. Replace enum constructs with classes

23. Check parameters for validity
27. Return zero-length arrays, not nulls

29. Minimize the scope of local variables
30. Know and use the libraries
31. Avoid float and double if exact answers are required
32. Avoid strings where other types are more appropriate
33. Beware the performance of string concatenation
36. Use native methods judiciously
37. Optimize judiciously

39. Use exceptions only for exceptional conditions
47. Don’t ignore exceptions


So you know how to code…

Most entry programmers learn how to program procedurally first, understanding that program instructions run one after another. Subsequently they learn control flow (if/else/for/while) and functions to modularize their code.

With these, one can almost write amazing programs. So where should we go from here?

For OO langauges like Java/.Net, I think there are two directions from here. One is to go lower level, to understand the foundation of the language, syntax, types, basic classes, including OO concepts like encapsulation, inheritance and polymorphism. This can be translated towards the Java Programmer certification. The other is to go higher level, to understand software architecture, data structures and design patterns. This will allow for better software that may be more efficient, maintainable and/or scalable.

The two directions are not XOR (one but not the other). Instead they are both as important. Looking at how other people write may also help in grasping style and technique, even identifying anti-patterns (style/design that should be AVOIDED).



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