Lost in J2ME

[chris]

J9 is absolutely, positively a certified J2ME VM. I've personally
witnessed it pass TCK certification on over 25 different OS/processor
combinations.

Oops, you're right. We're talking J2ME(TM) certified Java Powered(TM) here
folks ...

[Darryl]
Then answer one question: has J9 passed the TCK and is it a certified VM?
If your answer is "no" then whether it's the greatest thing for Java
since sliced bread is irrelevant; client companies make decisions based
on more than just peformance and stability (remember Windows?).

 

[Darryl L. Pierce]

J9 is absolutely, positively a certified J2ME VM. I've personally
witnessed it pass TCK certification on over 25 different OS/processor
combinations.

Umm, according to IBM, J9 is not certified since it's not designed to be
completely compliant with Sun's standards.

 

[Darryl L. Pierce]

The Java HotSpot Virtual Machine.

Sometimes the -client and -server versions are spoken of as two separate
VMs.

As someone else already pointed out to you, "JVM" is the name of the virtual
machine that ships with the Java 2 Runtime Environment.

It doesn't really have one.

Wrong. The virtual machine is called the CVM and it *is* different from that
virtual machine which ships with the J2RE. They are two *different* virtual
machines with different minimum requirements for their environments. You
cannot replace the CVM with the JVM.

The RI that ships with the CDC devkit is
called
[J2ME] CDC HotSpot Implementation, alias CVM, alias Monty.
<http://java.sun.com/products/cdc-hi/overview.html>.
This is, as is stated on that page, "a fully compliant Java virtual
machine"; that is, it complies fully with the JVM Spec.

Nobody said it couldn't comply with the JVM specification. I've said it's
not the *same VM* as that which comes with J2SE, which is what Huy claimed
and which I said was wrong. What exactly are you arguing?

No, they are at least 2 different VMs: Monty is said to share no code with
its bigger brothers.

Then you prove my point. Thank you.

(Why they're so proud of that I've no idea; but the
presentations from JavaOne made a big deal of it). Depending on how much
code is shared by the Client and Server HotSpot Virtual Machine(s), it may
or may not make sense to speak of 3 VMs.

But, you've apparently forgotten what *my* point was concerning this. Huy
claimed that CDC/PP was just "J2SE with some missing APIs". As you're now
showing, the CDC isn't J2SE: CDC and J2SE have completely different virtual
machines (which I said, but which you claimed was me being "too precise"
and creating a precision problem where there was none, but which you are
now showing was spot on when I said it).

They are all different, but they all implement the same spec

Uh uh. The CVM is implementing the CDC specification, which is not the same
specification as for the JVM in J2SE. They both meet the same requirements
for being *a* virtual machine but they are not both *the same* virtual
machine, which is what I have been saying.

(The Java
Virtual Machine Specification), and they could all answer to the name of
"the JVM" in some context.

"....in some context" should be the key to why you're having such a hard
time realizing your error.

Personally I prefer to talk of "the VM",
because (1) the Java part is usually understood, and (2) it's not a
trademark. Tradmarks make bad technical terms, because the owners are wont
to play Humpty Dumpty with them.

There is no difference between the VM spec for J2ME CDC and that for J2SE.

What is the minimum CPU requirement for both? What is the minimum memory
requirement for both? Shall I go on? They *do* meet different
specifications, even though both specifications comply with the same
minimum requirements for a *virtual machine* (i.e, in how they handle the
byte codes internall).

Call up the CDC specification. Then call up the JVM specification (i.e., the
virtual machine for the J2RE). Are they the same? What are their
differences? If there *are* differences, then you're *wrong*.

As far as the class libraries are concerned, if a given package is
implemented in a particular CDC profile then it is implemented with
exactly the same API as in J2SE.

So? That was done to leverage existing knowledge, and because it wouldn't
make any sense to create a whole new API for common domains. But, no
profile on the CDC is a subset of the core APIs; there are *intersections*
but there is no subset.

So if you proceed on the "completely and
utterly *WRONG*" assumption that CDC/PP is the J2SE minus some APIs your
applications will work;

Think so? Take a J2SE application and run it on the CVM. Were there any
problems? What were they?

your customers will be happy; revenue will flow,
shareholder value will be enhanced, and you will never know just how
"completely and utterly *WRONG*" your assumptions were.

Uh uh. You're now switching context. That a customer doesn't see the
difference doesn't mean there aren't differences. And, in this case, we
were talking about customers. It was one engineer asking other engineers
for information, and another engineer giving information dumbed down to
what you would give a non-technical user. Bad mojo.

Life is hard sometimes.

Yes, it is, especially when you're trying to justify being imprecise.

 

[Darryl L. Pierce]

Darryl L. Pierce wrote:

<snip>

Something that came to mind last night about this whole discussion:

Huy's statement claiming CDC/PP is just J2SE with some missing APIs (and
Chris claiming that that is more precise than saying the technical truth)
is like saying, "a grapefruit is just an orange without some of the orange
flavor" with Chris saying, "they're both citrus, so the statement's
correct".

The JVM Specification is like the definition of what makes a citrus fruit a
citrus fruit, without describing a specific piece of citrus.

The CDC is the grapefruit. It has all the features that makes it a citrus
fruit, while also have properties that make it unique.

The JVM is the orange. It also complies with the definition of citrus, but
is still its own unique fruit. It's not a grapefruit no matter how similar
the two may be when looking at specific parts.

 

[huy]

huy wrote:




I know. But Jeode is not God.

Thank God for that

 

[huy]

Darryl L. Pierce wrote:

<snip>

Something that came to mind last night about this whole discussion:

Huy's statement claiming CDC/PP is just J2SE with some missing APIs (and
Chris claiming that that is more precise than saying the technical truth)
is like saying, "a grapefruit is just an orange without some of the orange
flavor" with Chris saying, "they're both citrus, so the statement's
correct".

The JVM Specification is like the definition of what makes a citrus fruit a
citrus fruit, without describing a specific piece of citrus.

The CDC is the grapefruit. It has all the features that makes it a citrus
fruit, while also have properties that make it unique.

The JVM is the orange. It also complies with the definition of citrus, but
is still its own unique fruit. It's not a grapefruit no matter how similar
the two may be when looking at specific parts.

Analogies.....I just love 'em.

Here's my take:

There once was a cook who was trying to bake a lemon cake but had no
idea what a lemon was and had already mistaken a lime for a lemon. He
posted a question on alt.fruits.citrus.cook to ask if someone could
explain to him what a lemon is and how to go about using it to bake a
lemon cake. There came two responses to his post from two other cooks:

The first cook, who is a bit of a genius/mad scientist takes the
scientific approach and presents the following points and suggestions:
a. A lime is a *minimal* lemon.
b. A lemon is not an orange.
c. Try and find a lime which is used for lemon cake.
d. The lemon belongs to the family Rutaceae. It is classified as Citris
limon.....more scientific information here.......
e. Never refer to a lemon as a citrus fruit as this is incorrect and too
imprecise. (This was actually directed at the second cook ;-))
f. Just follow the lemon recipe cookbook, and ignore any cooks who tell
you to do it differently.

The second cook, who *thinks* he is a whiz in the kitchen ;-) decides to
leverage the OCs (original cook) knowledge of oranges and takes the
following approach:
a. Tell him a lemon is like an orange but is missing certain things
which GOD thought we wouldn't need in Lemon recipes. THis of course
implies that you can use either in many recipes as long as you know that
a lemon is sour and an orange is sweet. I.e you can bake both lemon and
orange cakes. If you use a sour orange, both cakes will end up similar.
b. Tell him to have at a look at the Eureka Lemon as an
example/recommendation.
c. Suggest a different way of baking a lemon cake to save them the
trouble of finding out for themselves that if they follow the cookbook,
the cake will turn out crap.

(There was actually a third cook, but I'll leave that for another story).

Which cook has totally missed the point of the OC's post ?

Cheers,

Huy

 

[Darryl L. Pierce]

Here's my take:

Your analogy has intermingled my statements with your own, making each
person offer advice similar to what both you and I have said.

There once was a cook who was trying to bake a lemon cake but had no
idea what a lemon was and had already mistaken a lime for a lemon. He
posted a question on alt.fruits.citrus.cook to ask if someone could
explain to him what a lemon is and how to go about using it to bake a
lemon cake. There came two responses to his post from two other cooks:

The first cook, who is a bit of a genius/mad scientist takes the
scientific approach and presents the following points and suggestions:
a. A lime is a *minimal* lemon.

It isn't. A lime is not a lemon, and it's only relationship is that they're
both part of a larger, more abstract group called "citrus". Dogs are
mammals. Cats are mammals. Dogs are not minimal cats, nor are cats minimal
dogs. This is similar to what you said.

b. A lemon is not an orange.

This is what I had said.

c. Try and find a lime which is used for lemon cake.

This is similar to what you said, but ignores the fact that there's no such
thing.

d. The lemon belongs to the family Rutaceae. It is classified as Citris
limon.....more scientific information here.......

This is what I had said.

e. Never refer to a lemon as a citrus fruit as this is incorrect and too
imprecise. (This was actually directed at the second cook ;-))

Nobody said anything of the sort. What *I* said was that you can't refer to
all VMs as being the *same* VM; the CVM is not the JVM is not the KVM,
though all fulfill the requirements for being call *a* JVM (per the JVM
specification, which itself says it's not the specification for any
*specific implementation*, just as the definition of Rutaceae isn't the
description of any *specific citrus fruit*).

f. Just follow the lemon recipe cookbook, and ignore any cooks who tell
you to do it differently.

Who said that?

The second cook, who *thinks* he is a whiz in the kitchen ;-) decides to
leverage the OCs (original cook) knowledge of oranges and takes the
following approach:
a. Tell him a lemon is like an orange but is missing certain things
which GOD thought we wouldn't need in Lemon recipes. THis of course
implies that you can use either in many recipes as long as you know that
a lemon is sour and an orange is sweet. I.e you can bake both lemon and
orange cakes. If you use a sour orange, both cakes will end up similar.

Nobody said that there weren't uses for the VMs discussed. The only thing
that *I* said was that you were incorrect to imply that CDC/PP was a subset
of the J2SE. It's not, and to say it is is to give bad, misleading
information.

b. Tell him to have at a look at the Eureka Lemon as an
example/recommendation.

Bearing in mind that there are going to be properties of that lemon that
might require the recipe to be changed in such a way that later
reintroduction of normal lemons will be impossible with more changes.

c. Suggest a different way of baking a lemon cake to save them the
trouble of finding out for themselves that if they follow the cookbook,
the cake will turn out crap.

With that "different way" being only possible if one uses Eureka Lemons and
not normal lemons, since that "different way" is only available with
Eurekas.

(There was actually a third cook, but I'll leave that for another story).

Which cook has totally missed the point of the OC's post ?

In your analogy, each cook gave both incorrect and some correct information.
But, in your analogy, the two cooks don't match up with what you and I have
said in this thread.

The two cooks should offer the following advice in order to meet with the
content of the thread:

Cook A says that for a lemon recipe, you need lemons.
Cook B says that lemons are just "limes with some orange properties
missing", implying that the OP can just substitute limes into the recipe.

As one very much into cooking, I can tell you that even *that* claim
(limes/lemons/oranges can be substituted for each other in recipes) is so
wrong as to be laughable. Between acidity levels, flavors and oils, you
cannot just replace one with the other and expect a good result. You have
to have some understanding of how things interact to know what to do. _On
Food and Cooking_ by McGee would be a good reference for this information.

 

[huy]

As one very much into cooking, I can tell you that even *that* claim

(limes/lemons/oranges can be substituted for each other in recipes) is so
wrong as to be laughable. Between acidity levels, flavors and oils, you
cannot just replace one with the other and expect a good result. You have
to have some understanding of how things interact to know what to do. _On
Food and Cooking_ by McGee would be a good reference for this information.

Damn man, is there anything you don't know

huy

 

[Darryl L. Pierce]

Yes: you confuse a specification (J2ME, J2SE) with an implementation (CDC
Hotspot, J9).

I've made no such confusion. Mate, look at what you're saying before you
accuse others of being confused or making mistakes:

o J2ME is *not* a specification; it's an umbrella term referring to related
technologies, of which there is the CDC (the specification for a particular
configuration [a virtual machine and core APIs]) and the Personal Profile
(the specification for a particular profile [a runtime environment that
provides domain-specific APIs to the configuration on which it is built]).
J2ME is not a specification, so you are mistaken there.

o CDC is not an implementation, it's a *specification* for a particular
configuration (see above for a brief definition of what a configuration
is). There are implementations *of* the CDC, but the term CDC refers to a
configuration specification and not an implementation of that
specification.

o J2SE is also not a specification, but a reference to a collection of
specifications for desktop application development, including the JVM
(which has now been broken up into two implementations; one optimized for
server functionality and one for client functionality) and the collection
of APIs related to standard (non-server) application development.

Sure looks like a categorical error to me. Like confusing a
C standard with a C compiler, or the HTTP protocol with a web server. Or a
railway train, a railway timetable, and a railway accident.

I've not confused anything as you claim. You are making a major categorical
error in your confusing what is a specification, what is a reference and
what is an implementation.

 

[Darryl L. Pierce]

Damn man, is there anything you don't know

The only thing I don't know is the complete list of things I don't know.

 

[Darryl L. Pierce]

Hang on a sec. I'm not sure who to believe now. Chris has provided an
explanation from the Java GOD themselves, but Darryl seems very
confident in his knowledge (maybe there is more then one Java GOD).

Seeing I also use *virtual machines* like vmware, I'll get confused if I
use the terminology suggested by Darryl, because people might complain
about being too vague about which type of virtual machine I am talking
about. I've also been advised against using JVM in the generic sense.
What is a man to do

Virtual machine: an executable that simulates being a separate hardware
platform (VMware)
Java Virtual Machine: an executable that simulates a platform for executing
byte code produced (minimally) by the Java compiler.
JVM: the executable shipped with the Java 2 Runtime Environment (and also
the previous releases, prior to the J2SE/J2ME/J2EE partitioning, of
JDK/JRE), now split into two optimized implementations, one for client-side
and one for server-side execution.
CDC: the specification for a specific configuration under the J2ME umbrella,
which includes a virtual machine and core APIs
CVM: the virtual defined by the CDC
CLDC: the specification for a specific configuration under the J2ME
umbrella, which includes a virtual machine and core APIs
KVM: the virtual machine defined by the CLDC
MIDP: the specification a profile built on top of the CLDC specification
designed for handheld devices such as mobile phones and PDAs, which have
limited network connectivity, minimal user interface ability and limited
input ability
MIDP for SymbianOS: a specific implementation of the CLDC/MIDP
specifications written to execute on the Symbian OS platform.

Chris has majorly confused what is an implementation and what is a
specification. He is flat out wrong.

 

[Darryl L. Pierce]

Why not? It's just a library, after all.

SWT is more than "just a library". It's advantage is that it leverages
native code with the Java code to provide quick performance. With J2ME
configurations, such native code has to be built *into* the [C,K]VM since
JNI is *not* available. If you want to have SWT, you have to have it built
into your VM. It's *not* "just a library".

So far as I am aware, of IBM's three Java implementations only their
(J2SE) JRE is certified. The terms on which they obtained the J2SE TCK
probably do not allow them to test the others for compatibility (of course
I am guessing, because I have never seen these terms. But I am pretty sure
that the Jikes RVM team do not have access to the J2SE TCK,

Jikes is a compiler. TCK is for runtime environments.

and I see no
reason why any part of IBM should have access to the J2ME TCKs).

What does their having access to such have to do with the discussion? IBM
has not (and AFAIK will not) certify J9 against the J2ME specifications
since they are not trying to release an implementation of any single
specification.

I prefer not to remember Windows, but will agree to do so if you will
remember JBoss.

I only bring up Windows to point out how *customers* buy; they don't go
based on performance or anything technical, they decide based on legal
elements, such as certifications and other such assurances. If they bought
based on quality, Windows wouldn't be around, or would be a completely
different beast.

There are reasons why groups like JConsortium exist.
<http://www.j-consortium.org/faq.shtml>
I could say more, but I fear we've wandered too far into c.l.j.advocacy
territory already.

The website doesn't load; the domain's note resolving. So, I've gone to
google's cached version of the FAQ.

From what I've read in their FAQ, they're just a group outside of the Java
hierarchy that have their own requirements for the Java language. Is that
about right? Sun isn't a part of their organization, and they're
intentionally not participating in the Java Community Process. They *claim*
it's not open and vendor-neutral, but they provide nothing to really
support that statement (they claim that Sun could become heavy handed, but
hey Java is their property currently). So, they exist, but I don't see what
their purpose for existing is meant to achieve, except to create yet
*another* group of people who want something but don't want to participate
in the existing channels to get it...

 

[chris]

Why not? It's just a library, after all.

SWT is more than "just a library". It's advantage is that it leverages
native code with the Java code to provide quick performance. With J2ME
configurations, such native code has to be built *into* the [C,K]VM since
JNI is *not* available. If you want to have SWT, you have to have it built
into your VM. It's *not* "just a library".

Are you absolutely sure that JNI is not part of CDC? That's contrary to
anything I've ever read.

Jikes is a compiler. TCK is for runtime environments.

Jikes RVM is a virtual machine.

What does their having access to such have to do with the discussion? IBM
has not (and AFAIK will not) certify J9 against the J2ME specifications
since they are not trying to release an implementation of any single
specification.

Looks like we're both wrong (or at least not 100% correct):
<http://www-306.ibm.com/software/wireless/wme/features.html>


Standards compliance
WebSphere Micro Environment contains a production-ready Java Powered?
runtime environment -- and a whole lot more. The next generation of Java
applications is supported today by IBM. WebSphere Micro Environment has
been tested and certified to meet the following J2ME® specifications for
both cellular telephones and Personal Digital Assistants and other embedded
devices.
For small devices such as cellular telephones, smartphones and PDAs,
WebSphere Micro Environment ships a platform that meets Connected Limited
Device Configuration (CLDC) and Mobile Information Device Profile (MIDP 1.0
and 2.0) specifications.
For larger devices such as PDAs, PDA phones and handheld computers,
WebSphere Micro Environment ships the Connected Device Configuration (CDC),
Foundation Profile and Personal Profile.

And yes, WebSphere Micro Environment is J9 - it says so towards the bottom
of the page.

 

[chris]

Virtual machine: an executable that simulates being a separate hardware
platform (VMware)
Java Virtual Machine: an executable that simulates a platform for
executing byte code produced (minimally) by the Java compiler.

These will do well enough.

JVM: the executable shipped with the Java 2 Runtime Environment (and also
the previous releases, prior to the J2SE/J2ME/J2EE partitioning, of
JDK/JRE), now split into two optimized implementations, one for
client-side and one for server-side execution.

Here, as is by now well known, I beg to differ: I do not believe that JVM
has this precise connotation. Which normally wouldn't matter much, as I
never (well, hardly ever) use the term myself anyway.

CDC: the specification for a specific configuration under the J2ME
umbrella, which includes a virtual machine and core APIs

Sounds fine. Note that the specification for the CDC VM is identical to
that for the J2SE VM.

CVM: the virtual defined by the CDC

I would rather say: a VM built by Sun to serve as a reference
imnplementation for J2ME/CDC. (And subsequently renamed by them to
something else, which is normal in this industry). A VM which compies with
J2ME/CDC doesn't have to be called "CVM".

CLDC: the specification for a specific configuration under the J2ME
umbrella, which includes a virtual machine and core APIs

Note that unlike CDC, CLDC actually defines a set of features from the
generic VM spec which are *not* implemented in CLDC VMs - such as floating
point, weak references, object finalisation, JNI, handling of Errors (as
opposed to mere Exceptions).

KVM: the virtual machine defined by the CLDC

Same story as for CVM, except that Sun's KVM antedates the whole J2ME thing
and the CLDC spec was written to fit it (again, happens a lot in the
industry).

MIDP: the specification a profile built on top of the CLDC specification
designed for handheld devices such as mobile phones and PDAs, which have
limited network connectivity, minimal user interface ability and limited
input ability

Yes. Sometimes PDAs are also mentioned as possible CDC platforms (some of
today's PDAs are pretty powerful).

MIDP for SymbianOS: a specific implementation of the CLDC/MIDP
specifications written to execute on the Symbian OS platform.

That would be a misnomer. Try "Java MIDP development tools for Symbian OS"
or even e.g. "Series 60 MIDP SDK 1.2.1 for Symbian OS, Nokia Edition".

Chris has majorly confused what is an implementation and what is a
specification. He is flat out wrong.

Nah Darryl, you're wrong. Flat out.

 

[chris]

Yes: you confuse a specification (J2ME, J2SE) with an implementation (CDC
Hotspot, J9).

I've made no such confusion. Mate, look at what you're saying before you
accuse others of being confused or making mistakes:

o J2ME is *not* a specification; it's an umbrella term referring to
related technologies, of which there is the CDC (the specification for a
particular configuration [a virtual machine and core APIs]) and the
Personal Profile (the specification for a particular profile [a runtime
environment that provides domain-specific APIs to the configuration on
which it is built]). J2ME is not a specification, so you are mistaken
there.

Correct: J2ME is not a specification, it's a whole family of them. Divided
into two big clans.

o CDC is not an implementation, it's a *specification* for a particular
configuration (see above for a brief definition of what a configuration
is). There are implementations *of* the CDC, but the term CDC refers to a
configuration specification and not an implementation of that
specification.

Darn, I typed CDC instead of CVM. Am I out of the game?

o J2SE is also not a specification, but a reference to a collection of
specifications for desktop application development, including the JVM
(which has now been broken up into two implementations; one optimized for
server functionality and one for client functionality) and the collection
of APIs related to standard (non-server) application development.

OK, one specification can hide another.

J2ME, J2SE are names of (families of) specifications. CVM, Hotspot, J9 are
names of (families of) implementations. So we agree, right?

Good.

 

[Darryl L. Pierce]

Why not? It's just a library, after all.

SWT is more than "just a library". It's advantage is that it leverages
native code with the Java code to provide quick performance. With J2ME
configurations, such native code has to be built *into* the [C,K]VM since
JNI is *not* available. If you want to have SWT, you have to have it
built into your VM. It's *not* "just a library".

Are you absolutely sure that JNI is not part of CDC? That's contrary to
anything I've ever read.

Not absolutely. JNI was one of the elements eliminated from the CLDC (along
with reflection and object serialization). The CDC is a superset of CLDC
1.1. If it's not been barred outright, chances are it's going to be
unavailable in real world situations since it's going to be a part of the
embedded hardware and not easily modified.

Jikes RVM is a virtual machine.
<http://www-124.ibm.com/developerworks/oss/jikesrvm/>

I'm not familiar with Jikes RVM. However, IBM is a *big* company (I worked
for them for a number of years) and the group working on that is separate
from the group working on J9 and WME. That one group has access doesn't
mean another group will have access to the same resources. Hell, they may
not even be in the same facility or region (I worked on SecureWay Firewall
in NC and our companion team was in TX, prior to that my team was split
between Endicott, NY, Research Triangle Park and Watson). So to say that
one team can do what another can't (or hasn't) is somewhat meaningless.

Looks like we're both wrong (or at least not 100% correct):
<http://www-306.ibm.com/software/wireless/wme/features.html>

Standards compliance
WebSphere Micro Environment contains a production-ready Java Powered?
runtime environment -- and a whole lot more. The next generation of Java
applications is supported today by IBM. WebSphere Micro Environment has
been tested and certified to meet the following J2ME® specifications for
both cellular telephones and Personal Digital Assistants and other
embedded devices.
For small devices such as cellular telephones, smartphones and PDAs,
WebSphere Micro Environment ships a platform that meets Connected Limited
Device Configuration (CLDC) and Mobile Information Device Profile (MIDP
1.0 and 2.0) specifications.

"Meets the specification" and "is certified" are two very different things.

For larger devices such as PDAs, PDA phones and handheld computers,
WebSphere Micro Environment ships the Connected Device Configuration
(CDC), Foundation Profile and Personal Profile.

And yes, WebSphere Micro Environment is J9 - it says so towards the bottom
of the page.

Yes, I know. I have WSDD/WME here for my job. I'm in somewhat regular
communications with the WME team and a few of the engineers participate in
the KVM-INTEREST mailing list. Ken Walker has said that J9 is not certified
and is not going to be certified, which doesn't not mean they cannot say it
meets specifications. It just means they cannot claim it's a certified
platform. Just as certain unnamed java implementation vendors of the free
variety cannot claim to be a certified implementation because that costs
money they don't have to spend but *can* still claim the be compliant to
the specification...

 

[Darryl L. Pierce]

These will do well enough.


Here, as is by now well known, I beg to differ: I do not believe that JVM
has this precise connotation. Which normally wouldn't matter much, as I
never (well, hardly ever) use the term myself anyway.

You may beg to differ, but you would be wrong. You go back over the
historical technical documents from Sun and you will see the virtual
machine that has shipped with the JRE from day one referred to as *The*
JVM. When they began to partition to the technology, it remained The JVM.
Now it has been subdivided into the client and server optimized JVM but it
is still _The JVM_.

Sounds fine. Note that the specification for the CDC VM is identical to
that for the J2SE VM.

And, again, no it's not. The minimum system requirements are completely
different. CVM requires far less resources and has differences *beyond* how
it will handle the specific bytecodes (which is what the JVM Specification
you cited earlier describes and which is what all of the VMs (C/J/KVM) have
in common).

I would rather say: a VM built by Sun to serve as a reference
imnplementation for J2ME/CDC.

And you would be _wrong_. It is called _The CVM_. Whether you prefer to call
it something else or not is irrelevant; I've not been talking about what
_you_ want to call it, I've been talking about what it _is_ called.

(And subsequently renamed by them to
something else, which is normal in this industry). A VM which compies with
J2ME/CDC doesn't have to be called "CVM".

The VM that is defined by the specification *is* the CVM. What each
implementor calls their product in order to differentiate is another story
entirely. The VM defined _by the specification_ is _The CVM_.

Note that unlike CDC, CLDC actually defines a set of features from the
generic VM spec which are *not* implemented in CLDC VMs - such as floating
point, weak references, object finalisation, JNI, handling of Errors (as
opposed to mere Exceptions).

CLDC does *not* support those things (not in the original specification) and
only some of it has been added to the 1.1 specification (floating point
math, weak references). JNI is not supported, nor is finalization.

Same story as for CVM, except that Sun's KVM antedates the whole J2ME
thing and the CLDC spec was written to fit it (again, happens a lot in the
industry).

Bullshit. The CLDC was the *first* specification to be released under the
J2ME umbrella. It came out with the reference implementation containing
Spotlets, which was the only way to use it until the MID Profile was
finished.

Yes. Sometimes PDAs are also mentioned as possible CDC platforms (some of
today's PDAs are pretty powerful).

So? The newer, more powerful PDAs meet the minimum requirements for the CDC
(2MB RAM, 32-bit CPU). When the MIDP was initially released, the most
powerful PDA was the Palm and it only gave less than 256k to an
application.

That would be a misnomer. Try "Java MIDP development tools for Symbian OS"
or even e.g. "Series 60 MIDP SDK 1.2.1 for Symbian OS, Nokia Edition".

You're now getting to an SDK bundle, which is one step *above* my statement
above. What runs on the Series 60 Nokia phone? The MIDP for SymbianOS. What
you're talking about is the SDK used to write applications *for* the MIDP
for SymbianOS. Mate, you need to take a step back and read a bit. You're
making some wildly inaccurate statements.

Nah Darryl, you're wrong. Flat out.

I beg to differ. You have made above some completely unsupported assertions,
such as referring to an SDK as an implementation of the MIDP, claiming the
CLDC includes JNI and finalization, among others. I know precisely what I'm
talking about because this is what I have done for the past 5 years. As I
told Huy before, there is the 85% and the 15% and *I* am in the 15%.

 

[David Zimmerman]

huy wrote:




The only thing I don't know is the complete list of things I don't know.

The size of that list buggers the imagination!

 

[Randy Faust]

I don't know where you're getting your information from but you're
absolutely, unqualifiably incorrect.
http://www-306.ibm.com/software/wireless/wsdd/

For example, J9 is the VM running on the recently released Zire 72 from
PalmSource, and it is most 100% "Java Powered" or TCK compliant.


Randy

 

[Randy Faust]

Yes, I know. I have WSDD/WME here for my job. I'm in somewhat regular
communications with the WME team and a few of the engineers participate in
the KVM-INTEREST mailing list. Ken Walker has said that J9 is not certified
and is not going to be certified

I doubt Ken ever said such a thing as he's well aware of the compliance
of WME/J9 on any number of platfornms. Why do you insist on spreading
FUD that J9 is not a "Java Powered" platform?


Randy