4

When programming in CDC I'm always reinventing the wheel, re-implementing stuff like Arrays.toString(Object[]). Why is it this way? Couldn't CDC (and FP, PBP, etc) be a subset of the current edition of SE, instead of being based on an old (may I say obsolete?) version of Java?

There might be a good reason for this, but I fail to see it.

JoaoHornburg
  • 917
  • 1
  • 11
  • 22
  • These newly re-created wheels get grouped in a "util" package at some point, of course, but the point here is not about code duplication project-wise, the point is why they couldn't already be available in CDC. – JoaoHornburg Feb 24 '12 at 12:43

2 Answers2

2

The answer is simply, Moore's Law.

In its usual formulation, it's expressed as "the number of transistors on an economic-to-produce chip roughly doubles every 18 months".

However, looked at another way, it could also say that if the "capability" (i.e. number of transistors) is held fixed, then the cost can be driven down over time.

This is the view that the Java ME executive committee took, so the reference devices are no more powerful than they were 4 or more years ago - but they are much cheaper. This matters to the space that CDC is trying to play in, but it does mean that devices are typically underpowered compared to what's needed for an SE subset.

A rebaseline of the CDC spec is underway, to bring it closer to SE. Java 8, with its modularity support will also make this easier.

Ultimately the goal is convergence of ME to a subset of SE, but this will take several more releases yet.

kittylyst
  • 5,640
  • 2
  • 23
  • 36
1

They are - CDC is a subset of what was the 'current' version of JavaSE when it was defined. (ie. CLDC1.0 > JSR30 > approved in aug. 1999 > based on JavaSE 1.3)

CDC, CLDC, FP, PBP... are all specifications - frozen in time - they cannot be updated. Updating an specification would mean launching a new one (eg. CDC2.0) - and then you would have some devices compliant to the old one and some to the new one.

Besides that, consider the premise "CDC is ... highly optimized for resource-constrained devices, such as consumer products and embedded devices" - and we're talking about resource-constrained devices in 1999.

gabriel_agm
  • 513
  • 1
  • 4
  • 14
  • CLDC is not a subset of SE. One of the more insidious things when trying to use MIDP is the fact that Integer was reparented to Object instead of Number. There are additional examples of nasty differences that cause strange behavior in code that works on SE. – James Branigan Feb 24 '12 at 13:20