Daily Archives: 17/05/2012

Beyond DirectJNgine 2.1 (I)

With DJN 2.1 out, it is time to start thinking about features for the future versions of DJN.

I’ve been very happy with DJN reliability. Users report very, very, very little bugs. I’m really fond of the way Test Driven Development has been put into practice in DirectJNgine.

Of course, everyone has a desired feature that he misses and will consider that a bug, but a missing feature is a bug only if it was part of the specifications -if it was not there, how come we “miss” it? 😉

I consider the underlying structure absolutely stable and rock solid: therefore, no need to plan for architecture improvements, refactorings and such for the near future.

Must have features

I don’t miss any must have feature.

Yes, some guys will justly consider some features must-have: there are requests such as “I have to download 100 Mb files and need to support end user feedback, and DJN does not allow me!”, or “I love Spring, please provide support asap”, which are completely reasonble. But I don’t have an avalanche of requests with regards to any missing feature.

Important features

  • Generic type support for method parameters

    Runtime handling of Java generics is problematic because they are an afterthough. All JSON deserializers for Java use one trick or another to work around this (I envy .net guys in this respect, really).

    The gson guys (it is the underlying json handling library) explain this very well here.

    I have found that using arrays, which provide all necessary information at runtime, is the way to go. In reality this missing feature looks worse than it really is. Once they get into the real business of using DJN, most users just don’t care -and even wonder why it looked so important back then when I question about it.

    But, yet, this looks so bad. Especially for those that do not get into understanding why this, and so assume it is a stupid mistake. I would love to have this for DJN 2.2 (no promises, though!).

  • Make methods that can receive arrays capable of receiving a single item gracefully

    Now, why is this relevant? Sometimes ExtJs generates calls to my Java method with a single object, and sometimes it generates calls with many items and sends an array. Why not send an array in both cases?

    Java is a type-safe language, so you can’t have a method that receives both kinds of parameters. Depending on how you use ExtJs this can get really annoying.

    DJN to the rescue! What if you write a method that receives an array, and DJN creates a single item array when ExtJs insists on sending a single item? Would be nice!

    This might be something to have in DJN 2.2 or maybe 2.3.

  • Provide reasonable default Java Date support

    Dates are not a JSON type, so everybody sends them their way, and you have to define that way in every project.

    Of course, I have my own, but I found that I always encode them the same way, and everybody seems to like that way. I might add that code to DJN by default, and whoever does not like it can keep defining his own way (I bet everybody out there has already defined serializers/deserializers for java Date).

    Might be part of DJN 2.3.

  • Support for donwnloading unlimited size files

    I implemented file downloading in the simplest possible way, especially from the user point of view.

    But that way is not the more efficient way. When file size grows big, it can get ugly because you have no way to provide feedback. What’s worse, if you have little memory available, you can get out of memory errors.

    Would be nice for DJN 2.4, right?

More considerations to come

That’s all for today. I will continue ruminating about future directions for DJN in the following days…

Your feedback will be greatly appreciated: feel free to post your ideas as comments in this blog or in the main ExtJs thread for ExtJs here.