Showing messages 1 through 3 of 3.

• End or manage?
  2008-01-29 22:52:00 sean_sheedy [Reply | View]
  
  

  I find this questionnaire very interesting because I have a rather broad definition of fragmentation. To me, fragmentation not only includes API and implementation fragmentation, but issues such as signing, testing and certification requirements, distribution, etc. Because of this, I think that no one group can "solve fragmentation", but that it needs to be divided into pieces and that every one of the above groups has plenty of work to do.

  For years, we've taken a decentralized approach to addressing these different areas of fragmentation. Some groups have done better at it than others, but overall, progress has seemed glacial. If insanity is defined as "doing the same thing over and over and expecting different results", then maybe we should try something different, like a more centralized approach.

  Finally, for all the hype that Java ME fragmentation gets (and fragmentation is not a problem exclusive to Java), we have to admit that it is a by-product of the platform flexibility that has allowed ME to be deployed on more mobile devices in the world than any other application execution environment. While it is not possible, nor advisable, to eliminate every type of fragmentation, platform differentiation cannot be used as an excuse to avoid collaboration against fragmentation that leads to duplicative and wasteful effort.

• prevent JME fragmentation by using the JSE model
  2008-01-25 18:02:46 ga24 [Reply | View]
  
  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.

• prevent JME fragmentation by using the JSE model
  2008-01-26 07:23:18 jwenting [Reply | View]
  
  JME is already fragmented. Different devices even from the same manufacturer can't even use the same classfiles, often needing source level changes to make things work on them all.
  Only the handset makers, through pressure on mobile device OS and firmware manufacturers, can change that. It's up to them to require a standard to be adhered to. While developers can all refuse to write Java software unless it's for a specific "standard" (whichever we choose) that won't mean a thing to the handset makers, nor to their suppliers. Their devices sell anyway, and their customers aren't going to demand they comply with a specific Java version as they don't know or care that something is Java.
  They just see that they can't run software X so they choose a competing product that will work with their device.