|
That is, have a deep and broad specification that doesn't leave things out, complement that with a deep and broad compatibility test suite and independent verification.
Failure to be independently verified would result in the product not being able to call itself JME. It seems that, so far, the push has been to get a large number of JME devices, and compatibility hasn't been enforced... It seems that it is overdue for this to change...
In the event of gaps, the rule would be to behave like the reference implementation (and file a bug report).
JME will always be more challenging due to the larger number of independent implementations out there, relative to JSE, thus the specification and the test suite will be need to be more exhaustive.
And, of course, the wide variations in the capabilities of the devices makes it challenging in a second dimension; again, unlike JSE.
Finally, the larger number of players relative to JSE (Sun, the JME implementors, hardware manufacturers) makes coordination more challenging.
But with some potential tightening up and verification, possibly supplemented with some delicate enforcement, the fragmentation problem is eminently solvable. |
java.net RSS Feeds
