Vikram Goyal's Blog

January 2006 Archives

The beef is with ...

*started this as a comment in response to Dependency hell*

-- the fact that I know I could do the same project two years back with Struts and a handful of Commons libraries.

-- the fact that a newbie to Java will recoil with horror at the number of concepts he has to learn to do anything meaningful. Where would you start a newbie on a project like this? (Don't tell me that you won't hire a newbie to join this project. All of us don't have the luxury or the money to hire seasoned professionals)

-- the fact that there are 21 major dependencies, but when I count the total number of actual jars that figure is actually 102. That's 102 libraries not including the JVM and definitely not including the actual project libraries. So before I start the project, I must know how 102 different things work, how they interface in my project, what parts of these 102 libraries are most useful to me. Surely, there is something wrong here? Surely, my project, before it starts, does not hog 26 MB of disk space?

-- the fact that I wasn't actually complaining about joining this project because of the dependencies, but surprised that dependencies in Java have taken over any meaningful project development because of lack of support in the actual Java language (See second last line in the previous entry)

Well on with the project. So where should I start first? I know Struts. So should I carry on to Spring and learn IOC? or should I understand Hibernate first and see how that will apply to my project? Umm.. maybe Velocity because presentation is important. No wait.. I am a bit scratchy on Axis..Darn, what about the actual business cases and the project? Hey who's coding that?

Dependency hell

I started work on an existing project at my day job today and the first thing that I had to do was to download all the dependencies for the project. Here is a snapshot of the dependencies folder after I had checked it out of CVS:

Wow! That's 21 dependencies in that folder. Twenty-One! Actually, it should be more because Jakarta-Commons contains many separate libraries, which in this case is 14 more. So that's a total of 35 dependencies I have to contend with before I start on the project.

It is a shock to me (maybe not to the rest of you) because I am coming back to working mostly full time on a Java project after a year or so, in which time, I was working on a .NET project.

I will say this now, looking at that folder: even though Java is my preferred platform, I never encountered this kind of dependency nightmare working with .NET.

What's the maximum number of dependencies that you have encountered? Is it a problem in the Java language that requires these many dependencies? Because to be fair, these dependencies wouldn't be there if they were not required.

And yet, I am almost nostalgic for the simplicity of .NET. *shudder*

Frustrated with J2ME implementation differences

I am getting increasingly frustrated with the level of differences in MIDP, CLDC and optional API's implementations. Device manufacturers are increasingly making independent rules for their implementations, so much so, that it is almost impossible to port applications from one device to another.

Take the case of Mobile Media API (MMAPI) that enables MIDI, tones, audio and video in your MIDlets. The specification for this API is ambiguously written, in parts. You are guaranteed to have major headaches providing workarounds for different devices. Part of the blame lies with the device manufacturers as well, who provide arbitrary implementations with their own understanding of the specifications.

A specific case relates to the supports.mixing property. If true, the MMAPI implementation must provide the ability to play two sampled audio files simultaneously. But can you? No. Several implementations decide to interpret it as a combination of a MIDI file AND an audio file, rather than two pure sampled audio files. Others, decide to make available the mixing of two MIDI files, ignoring sampled audio completely. Still others give even worse results, by only allowing mixing of tones. The API is specific in this regard and mandates the support for mixing of two sampled audio files, if this property is true.

So, who suffers due to this? Content developers and consumers.

The solution, in my opinion, is for Sun (or any other regulatory body), to certify the implementations of MIDP, CLDC and ALL optional API's as conforming to the specifications. Developers will then know, which implementations they can confidently work against.

It is not such a difficult task. There is already a Java Verified program for certifying applications. Why can't we request the same level of momentum and commitment from device manufacturers and Sun?

I am even open to a third party being set up to provide this compliance against the specifications. There is an increasing number of optional API's coming out, all of which will lead to even more frustration and incompatibilities. Surely there is a market here for somebody to grab. Only if the device manufacturers would be willing to play ball.

This work is licensed under a Creative Commons License.