Category Archives: programming

New Software: dofCalc, the mobile, cross-platfrom Depth-of-Field Calculator

It’s been a while since I announced (along the way) that I was going to get a DSLR camera in this post. Well, I have got it by now. It’s an Olympus E-520 I bought with the two kit lenses. With a few initial hurdles cleared, I’m quite happy with it. Obviously, as soon as you start to extend your own limits, you painfully recognize where the new ones are. So it is when after buying an entry class DSLR with a pair of pretty decent kit lenses you start to take different kinds of pictures and more consciously, you start to find yourself in situations where you don’t even press the release because without trying you know there’s no way your equipment is going to get the picture at the right exposure, sharp, with sufficient depth-of-field. As always, it is the last few percent of excellence that take the greatest energy to achieve. It is not just energy, though. There is a considerable amount of money involved in wanting this lens, that body, this tripod, or that flash.

Now, as a hobbyist, there are limits to the amount of money I’m willing to spend per year. But there are other ways of putting energy to a good use. One thing that has been nagging me, was that I had all those depth-of-field calculators online, but none which I could carry around. Yes, there are cardboard dials you can carry around, but that’s one more (rather frail) thing to carry around in the already limited space of my camera bag. Yes, there is depth-of-field calculator software for the iPhone and one for PalmOS, but I have no such device. I do, however, own a Java-enabled mobile phone which I carry around most of the time, anyway. And as a big fan of the “write-once-run-anywhere” idea, I was mildly annoyed that nobody had implemented such a piece of software in a cross-platform way. Then I did it, myself.

So, this then is dofCalc, the portable depth-of-field calculator that requires no more than a Java-enabled mobile device that supports MIDP 2 and CLDC 1.1. It not only allows you to calculate the depth-of-field from the other related values, but also to calculate any of the other parameters, like aperture from a desired depth-of-field, focal length, and subject distance. Along the way, it can calculate the hyperfocal distance and has a configurable circle of confusion to be usable with virtually any camera. If you think this could be useful, visit the sourceforge site and download it for free. I’ll be looking forward to your feedback.

Tagged , , , , , , , , , ,

Java Generics demystified

After having just bashed one book, I need to do something for the Yin/Yang balance. So, here’s a book recommendation:

Book: Java Generics and Collections

Book: Java Generics and Collections

While one may sometimes think that books on programming languages are obsolete with everything out there on the Internet, there are situations when after researching for hours, reading tutorials, blogs reiterating the tutorials, etc., you wish you just had somebody with some real in-depth knowledge to explain things to you. If the matter in question is generics in Java, I can absolutely recommend this book by Maurice Naftalin (funny last name, though) and Philip Wadler. It goes way beyond what the vast majority of tutorials explain. You might find everything in the Java Language Specification, but this book is certainly easier to consume.

It has solved these questions for me:

  • Q: How do you subclass a class with fairly wide type bounds in such a way that you restrict the bounds but not just select a parent further down the chain? For example, you may want to allow just one specific type.
    A: You don’t put the type in the declaration of your child class, but in its extends/implements clause. So, you don’t do:

    // THIS DOES NOT COMPILE
    public MyMap<String, MyObject> extends AbstractMap {

    You could potentially do:

    public MyMap<K extends String, V extends MyObject> extends AbstractMap {

    Since String is final, that may be OK, but are you safe on V? Maybe, maybe not.
    To pin this down, you could do:

    public MyMap extends AbstractMap <String, MyObject> {
  • Q: How do you use a generic method when the type cannot be inferred from the method parameter (e. g. because there is none)?
    A: Let’s say you have a method like this:

    public class MyClass<T extends Blah> {
    ...
    public List<T> getList()

    And then you want to call this from another generic class. The following may work but -Xlint:unchecked complains.

    public class MyOtherClass<T extends Blah> {
    MyClass<T> foo;
    ...
    List<T> bar = foo.getList();

    The clean way to do it, is:

    List<T> bar = foo.<T>getList();

If you’re interested, you’ll find the book with this information:

Title: Java Generics and Collections
Authors: Maurice Naftalin, Philip Wadler
Published: October 2006
Pages: 284
ISBN 10: 0-596-52775-6 | ISBN 13: 9780596527754