• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

CLDC+MIDP implementations

 
Saurabh M Sirdeshmukh
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Folks,
I am preparing for SCMAD exam.
I was deep into the details of CLDC n MIDP implementations.

Across majority Java ME literature, I came across the definition of Configuration as:
The KVM + core library/classes implementation.
n Profile is defined as:
additional apis provided to leverage the features of particular category of devices on top of configuration chosen
.
Now, it only seems logical that the according to the physical properties of the deivce(like ROM/RAM/Display/Processor speed etc) the spec/JCP guys would be deciding the core classes to be included n eventually implemented by the it's RI/JVM.

Now if the JVM implements the configuration, who's gonna implement the additional profile APIs? Obviously, there needs to be an implementation of the profile. But even official Sun specs say that only configuration is the one who bothers about KVM implementation. There's some mismatch. I believe the Configuration n Profiles are pretty tightly coupled. The so called modularization/flexibility of Java ME world is, I believe exaggerated. The reason is:
1. The FAQ on Sun website about MIDP 2.0 implementation says:
The memory footprint for MIDP 2.0 along with CLDC implementation is: 0.8 to 1MB

2.I read paper- 'CLDC HotSpot implementation'(Sun Microsystems). It says that MIDP implementation is integrated with CLDC HotSptot by
Sun Java Wireless Agent
.

This gives me impression that EITHER:
the CLDC+MIDP are often implemented together in a form of KVM
OR:
We need to augment/integrate/attach to the KVM, the implementation of MIDP.
If this is the case, then why all the Java ME literature/spec world only mentions the KVM/JVM in context of configurations.After all, the profile specific APIs are also to be implemented. Typically, what I perceive JVM/RI as:
The piece of software having the mapping of instructions in the from of bytecodes to their corresponding instructions for underlying platfrom+ API implementor+ implementor of other stuff(GC,Thread Management etc.)
.

One of the paragraphs, in it's description of JVM on Wikipedia mentions (http://en.wikipedia.org/wiki/JVM#Bytecode_instructions) :

The aim is binary compatibility. Each particular host operating system needs its own implementation of the JVM and runtime. These JVMs interpret the byte code semantically the same way, but the actual implementation may be different. More complicated than just the emulation of bytecode is compatible and efficient implementation of the Java core API that has to be mapped to each host operating system
.

This is also evident from the expectations of CDC implementations: It asks nearly full-fledged JVM to be implemented. Plus there would be profile APIs atop, so overall RI would be JVM+Profile API/behavior implementations= full JVM for this combination.

Let me know guys. I am waiting for some rigorous discussion on this topic.

Also if devices are getting more n more memory/processor speed, wont it ultimately turn out to be Java SE with some alterations to take care of underlying wireless medium n architecture?


 
Sathya Srinivasan
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not sure I fully understand your concern, but let me try.

CLDC is the lowest common denominator for all mobile device with the J2ME platform. As such, it provides the base functions such as String manipulation, IO, etc.

MIDP is specific to a class of devices. As a result, you would have APIs specific to the characteristics of that device class. For example, 'phone' category will have capabilities to make some basic music, make a phone call, provide some limited UI, etc., while a set-top box API would have something for TV channel reception and so on.

Since you will most likely be working on a device, you will end up using a combination of CLDC + some profile, and in case of cell phones that will be CLDC + MIDP. Depending on the capability of the device, you might also end up using other packages such as Bluetooth, WMA, PIM, and MMAPI. Till this point, it falls under J2ME.

On top of this, the mfr. of the device might provide specific APIs that the programmer can use to leverage the specific features of that particular device (such as touch sensitivity in BlackBerry Storm). However, these APIs are not J2ME compliant, much like using Weblogic or WebSphere specific configurations in a J2EE environment.

In essence, you will end up using the following:

CLDC + MIDP + (optional packages - Bluetooth, WMA, MMAPI, PIM, ...) + Device-specific API

You might also want to post questions in the SCMAD forum if you have questions specific to the exam.
 
Saurabh M Sirdeshmukh
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Sathya,
It's privilege to here from you. Already, using your book for the exam.

What I wanted to say is: if CLDC+MIDP+Optional Packeges(if necessary) are all to be implemented, why only implementation of CLDC is termed as KVM.
Why this overall implementation is not termed as RI for this particular stack?

Another thing: are there any areas you know where we program on bare configuration without using any profile?

Thanks Pretty Much
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic