JSR238 - why? Why???
The new JavaME internationalization API, JSR238, appears to be a lost opportunity - the originators rightly spotted that the basic MIDP/CLDC spec has no real support for internationalisation of apps, so they've chosen to add it with an optional JSR adding three classes. At first glance that might seem useful, but it isn't.
This JSR will presumably be supported by a small collection of handsets (including many of those which are remote updatable with whatever that JSR was). Developers will have three choices: continue handling things with custom code, develop nice international apps purely for this JSR and lose all other handsets, or handle both. All three choices have disadvantages, but the sensible developer has to go for the first unless they are an enterprise handling the rollout of all new devices to a controlled user group. This is certainly a valid scenario, but what about legacy handsets? How many enterprises can afford rollouts to their whole workforce like this? Why wouldn't they just spend a day writing their own solution, scheduling 15 minutes to moan about it not being in the standard APIs before forgetting the problem ever existed?
Looking at the details, it uses XML content descriptors and hierarchical directory structures to hold all resources, so clearly it is only aimed at the enterprise. This is jar eating stuff capable of adding to the download size dramatically, with added parsing memory and clock-cycle overhead, so it really won't be hitting the mainstream handsets with users who pay per Kb and the gaming or mainstream app world any time soon.
I fully understand that if we tried this argument with every new API, we'd never have any progress. That's a valid viewpoint in the general sense but I think this is an area where it is not valid. Optional JSRs make a lot of sense when they rely on underlying hardware (Bluetooth) or device capabilities (3D), and can't easily be mandated in the Profile. But for something so trivial, why not just add this to MIDP3? MIDP3 will definitely be rolled out faster and wider than a single niche JSR like this, and so over time it would become a tool the whole community might choose to make use of. Like this, I really don't see it adding value any year soon.
This JSR will presumably be supported by a small collection of handsets (including many of those which are remote updatable with whatever that JSR was). Developers will have three choices: continue handling things with custom code, develop nice international apps purely for this JSR and lose all other handsets, or handle both. All three choices have disadvantages, but the sensible developer has to go for the first unless they are an enterprise handling the rollout of all new devices to a controlled user group. This is certainly a valid scenario, but what about legacy handsets? How many enterprises can afford rollouts to their whole workforce like this? Why wouldn't they just spend a day writing their own solution, scheduling 15 minutes to moan about it not being in the standard APIs before forgetting the problem ever existed?
Looking at the details, it uses XML content descriptors and hierarchical directory structures to hold all resources, so clearly it is only aimed at the enterprise. This is jar eating stuff capable of adding to the download size dramatically, with added parsing memory and clock-cycle overhead, so it really won't be hitting the mainstream handsets with users who pay per Kb and the gaming or mainstream app world any time soon.
I fully understand that if we tried this argument with every new API, we'd never have any progress. That's a valid viewpoint in the general sense but I think this is an area where it is not valid. Optional JSRs make a lot of sense when they rely on underlying hardware (Bluetooth) or device capabilities (3D), and can't easily be mandated in the Profile. But for something so trivial, why not just add this to MIDP3? MIDP3 will definitely be rolled out faster and wider than a single niche JSR like this, and so over time it would become a tool the whole community might choose to make use of. Like this, I really don't see it adding value any year soon.
Inspiration
posted by raddedas at 2:12 pm
1 Comments:
Agree with you. that's exactly the same issue with JSR172 (Web Services Specification).
When something can be implemented in software only , or when speed improvement is not significant, it is useless to create such JSR, as vast majority of developer will have to support older handsets.
10:41 pm
Post a Comment
<< Home