thanks for your reply.
Pls. find my responses below inline.
PS: In order to improve readability of the thread I have removed
those issues we have already clarified.
Right, while the question is, what means a "full implementation".
You can do a dummy implementation that does nothing useful e.g. in
the DIsplay class if you do not have a display, and hence pass the
TCK if this implementation behaves as expected. The question is
whether you want to do this, or if you would rather like to spare
the memory. In this case we would have to extract the key handling
from the lui package.
4.) Overview: handling of input (e.g. keypad) should not depend on the presence of a display. Many applications have keys but no display.
How should the input from the keys be
handled then? (I mean based on which API? Does it mean we need
an API for processing key inputs independent on a graphical
Well, the KeyListener doesn’t look too
bad to me. The problem with it is that it is in the same
package as Display, right ? Or are there other dependencies
Yes, the key listener is part of the lui
package. The package is not bug, the largest part is of course
the Display class. If you find it acceptable to implement the
lui package (with a then even smaller dummy Display class) for
having an API to handle key events. we can keep it this way.
If not, we will have to find a way to extract the key
functionality from this package.
Alternatives would be to put it into the event package (but my
guess is that you would not like this - see below :-) ) or
have an extra package for it.
I do not
have a problem to implement a dummy Display class in order
to use keys only. I am only a bit unsure how this would
work for a TCK. As optionality is on package level only a
TCK would probably expect a full implementation of the lui
package or nothing at all, right ?
So would you mind providing a list of methods you miss?
6.) javax.microedition.cellular: I do have the feeling that this package somehow overlaps with the AccessPoint in CLDC8/GCF. Please clarify how these two function complexes interact and why they are separated in this way.
It does not overlap. The interactiopn
between those two is well-defined.
But we have Roger as one of the CLDC Specleads in our EG.
@Roger: Could you explain the interaction between AcceddPoint
and Cellular to the EG a bit, pls?
Roger> For the question about the relationship
between CLDC AccessPoint and
The AccessPoint abstration is focused onTCP/IP network
Its origin was based on the operating system or device
the underlying networking stack. The application can pick an
and may want/need to be aware of its characteristics but
cannot control it.
Recent suggestions/improvements have expanded that somewhat
is still primarily an abstraction for a networking stack.
The MEEP CellularNetwork and Subscriber encapsulate
wide area networking and the operator managed subscriber
found on SIM cards. These abstractions provide access to
properties and controls. As above, the application needs only
for the network and (mostly) leaves the management of the
cellular network to
Most applications can operate effectively with only the
and do not need control over cellular functions in most cases
separation makes the API easier to understand and use.
remark about the cellular package (in fact it’s a similar
remark as I had about the AccessPoint):
This is an
API which does only allow to query information which is in
the device. It does not allow the midlet to configure or
control anything. I think this is a big drawback!
In a typical
(M2M) device the Java application (midlet) is the master.
There is nothing outside which could do this job. So e.g.
who enters the sim pin code ? Who selects the network ? I
think that this API should be able to do so.
The only problem I have with this solution is that it blows up the
APIs as I would have to introduce a particular listener class to
each of those packages: one into lui for the backlicght stuff, one
into power api for the power events, one into cellular etc.
8.) javax.microedition.event: A general question about this package: why such a generic event package ? In the past several classes had some listener functionality and they received "their" events through this listener. To me it seems a bit confusing to have such a generic event mechanism which then again contains events of all sorts.
Actually the more generic solution was
inteded to ease the confusion. :-)
We have a lot of events to be handled, and it makes sense to
handle them in a unified way. The listener concept is still
there, it has just made more generic, also in order to keep
the way open for future extension.
I understand the idea now, still I don’t
like it. I think this (certainly growing) list of events of
all different sorts IS confusing.
I don't think so. The more generic concept
is necessary as we have to handle a much broader variety of
events than we used to have in IMP-NG times. We can check
whether there is a way to somehow group the event inorder to
make the concept more comprehensive.
The event package enables two kinds of event that are not
specific to an API, those from the system, like startup and
events and events between applications. Being able to send
applications was a key element of supporting robust
could be isolated and still communicate.
I totally agree to such a usage of
the Event API!! Unfortunately when looking at the spec
this seems to be not the way it is used because
PowerManager ended up as Event subpackage
b) There is
a couple of predefined events which seem to be totally
misplaced here, e.g.
that is network/3G related should probably go into the
cellular package or AccessPoint ?
feels very Display related
Its probably too easy to just throw
some events into the events package instead of putting
them into a specific API and into a proper listener. I
suggest to really reduce the number of predefined events
to a absolute minimum here, maybe really ONLY the
SYSTEM_STATE_xxxx events for now.
This is imho unnecessary because those listeners do nothing
different than the EventListener in the event package.
Besides, event classes would have to be defined for all those
packages what makes the API even thicker.
@Roger: Could you comment this pls. for the cellular package?
And - even more important - for AccessPoint that also been mentioned
by Thomas? As this would mean that we'd force CLDC to do extensions
See above (two new classes in the Power API)
For specific APIs, each API design should include listeners
types and parameters specific to the API. It improves
usability and robust
uses. The general event mechanism should only be used when a
API is not practical.
I would say the “Power-API” clearly
goes in this category and has nothing to do with the Event
API, if I follow the philosophy which Roger described
It is possible - about my conserns see above.
And a big drawback probably also is that
you do only have one type of callback functions ? What about
parameters some event might have ?
There are much better possibilities to
transport parameters and other information in this concept.
The callback function accepts a parameter of type Event. In
this event object an unlimited number of info can be
transported. By checking the API again in order to write this
answer, I got aware that I've mixed up the "message and
information object" each event has with it's source (this
happened as a side effect of making the Event class a subclass
of java.util.EventObject from CLDC-8. I'll correct this and
send out a new spec version soon.
9.) javax.microedition.event.power: the previous question leads directly to this question: wouldn't it be nicer to have PowerManager class with a Listener instead of PowerManager being a part of an event package ? For me this just seems to be the wrong way around ?
See above. The whole power management has
to parts: handling of (power management related) events - it
seems to be a logical consequence to insert this part into the
general event concept. And the power manager to actively
receive informations and perform settings for the power
This architecture still feels very
strange to me. Especially when I envision where this is
supposed to end up. We will have various functionalities as
javax.microedition.event.xxxx just because this
functionalities uses some events ?!
No. The reason why power management has an
extra package is that it includes some additional
functionality like the PowerManager, and an implementation
that uses events but is not interested in power management
should have the chance to implement the event mechanism
without the whole power mangement it won't need.
In general, all kinds of events can be handled just with the
comment above to what Roger wrote.
This has not changed. This is not about the semantics of the API but
what a particular state means for a certain device.
A javax.microedition.power with the
PowerManager and a PowerManagerListener would make far more
sense to me.
As a matter of fact, you have this. It is
just a subpackage of the event package because it uses the
event mechanism for power events.
See my comment above to what
10.) PowerManager: good idea to have such a class, but at least for the use cases I know there are some issues here. E.g. a device can never signal a sleep state to a midlet, because the moment it would do so the device can not be in sleep state.
This is a question of implementation. The
system could use the notification in order to ANNOUNCE it is
going to sleep and wait long enough to give the application
receiving the notification to still display a message "Going
to sleep" or something.
Yes and No ;-) Of course as long as the
events are not clearly defined any implementation can do
(implement) whatever it wants. But if we want to handle it
this way why having a standard API at all ? Everybody who
needs this can implement its own API as it fits. My
understanding of a standard API would be that we have a
clearly defined (subset) of power management which can then
be implemented on various devices in the exactly same way.
Well, the API will be unique for all
devices. What a single state means for a certain device is
very hardware-dependent, so it will be difficult to rule a
unique definition of the states for all platforms. A good
example is your own retention against
POWER_STATE_REGULATED_LOW_POWER below. For your devices it may
make no sense, for others it is very important. The little
miracle we have to create with this profile is it to create an
API everyone in this very heterogeneous field can live with.
The solution can only be a good balance of ruling (e.g. by
determining classes and methods with fixed signatures) and
some degrees of freedom (like the interpretation what such a
state in particular means).
As a consequence, one implementer can decide, that going to
"SLEEP" mode allows some delay in order to give an application
the chance to display a message to a user, while another one
(e.g. one without any display) does not need this display and
just goes to sleep.
And you can implement "POWER_STATE_REGULATED_LOW_POWER" the
same way as "POWER_STATE_FULL_POWER" as it makes no difference
in your implementation (and POWER_STATE_REGULATED_LOW_POWER
will probably never be checked for in your applications),
while another implementation may emphasize the difference
between sthose states.
Well, if this is the philosophy
then I don’t mind. Only in the past the philosophy seemed
a bit different. Java APIs where very generic (sometimes
even too generic) in order to enable all devices to
implement them in exactly the same way.
To be frank: I do not understand what you are after:
- that the SLEEP state makes no sense?
- that you do not want the regulated low/high power states?
Pls. make a proposal. :-)
As a matter of fact, the UAProf IS optional, it is only required if
you set MIDlet-Profile-Request to "true".
Now I am
just wondering what the TCK for such an API will look
like, if different implementation are allowed to use this
API in very different ways. ;-)
12.) Application Provisioning: Whats the UAProf good for ? Please make it optional if someone really needs this. For device identification its often sufficient to put something meaningful in the "User-Agent" field.
Ok, will have a look at this again.
You can still set it to "false". Is this enough? Or which form of
optionality do you expect besides this?
Do they? I have to clarify this with our TCK guys. If so, this would
be rather a bug in the IMP-NG TCK.
I remember a discussion with Oracle some time ago if and why
we need “suites”. I see the suites are still there. Isn’t
one application per .jar enough ? Do we really need them ? I
don’t think so.
Yes, there have been indeed plans to remove
suites. The main issue with this was backward compatibility
with IMP(-NG) and the consequences for the security framework.
Your implementors will love the MEEP EG for keeping suites as
this way they can use the implementation model they have once
done for IMP-NG without changes.
An implementation that will in general have only one
application per jar has no significant overhead with suites
(as a suite can of course also conisit of only one
application), others that want use advantages like the common
access to one RMS by several applications within a suite can
still use it.
OK, so far
implementations could also pass the TCK without supporting
suites. Just please don’t enforce this in the future.
The official application model is an application suite.
Could you pls. explain (with a practical example) what is from your
pov the difference between a single application
and a suite containing a single application?
Or do you mean that implementations supporting only SUITES with just
one application pass the TCK?
I have checked, IMP-NG and MIDP do not require the dependency
attributes, so MEEP will also not do it.
a question about optionality and compatibility: on the
“optionality and compatibility” page of the spec it says
several times: “Applications
requiring the implementation of the xxxx optional package
in order to be able to run, MUST declare this request
Now when I think about an IMP-NG application as it is, this
application would not have this attribute. Still it could be
able to run IF my MEEP implementation is IMP-NG compliant.
So is my assumption correct that these MUSTs in respect to
attributes is only true if my MicroEdition-Profile attribute
of the application descriptor says “MEEP-1.0”. If this
attribute says IMP-NG the MEEP implementation would behave
differently and either accept the midlet if it is IMP-NG
compliant or reject it, but not check any dependencies
attributes, right ?
We can think about replacing the MUST by a
If you look at MIDP, there is the MIDlet-Dependency-<n>
attribute used in order to declare dependency of certain
external JSRs such as JSR-120. An application should declare
this dependency as this makes sure that it is only installed
if the device implements JSR-120. As far as I know, the
applications also installs and runs fine without this
attribute AS LONG AS JSR-120 is defined. Otherwise, it will
crash with a ClassNotFoundException or something unapprpriate
(I'll doublecheck this).
The dependency names for the optional packages had to be
introduced because due to the optionality it is not a-priori
clear whether a certain packae is available for an
implementation or not. An implementation that claims to be
backwar compatible to IMP-NG has of course to implement at
least all packages being mandatory in IMP-NG (see the chapter
about Profile Sets), and then all IMP-NG MIDlets should work
completely understand the usefulness of this dependencies
declaration in MEEP because of the huge number of
optionality. I am just saying that IMP-NG (and probably
also MIDP) worked pretty well without using the
dependencies, so for backward compatibility please don’t
enforce them now.
Just be aware that due to the optionality, there may be
implementations of MEEP not being backward compatible with IMP-NG
because many of the packages that have been mandatory there are
So to get sure that an applicatiion being an old IMP-NG MIDlet runs
on a MEEP implementation, you would have to put
those dependency attributes there, otherwise you will get aware of
that only at runtime by a ClassNotFoundException.
If you are though (and I guess this is the background) in a
situation where the MEEP implementation and the application
is written by yourselves, so you KNOW that your implementation
contains all classes that have been mandatory in IMP-NG,
than you do not have to care about dependeny attributes.
Certainly not. It could be a proposal for future versions though.
wondering, how to actually create these dependencies in an
application descriptor in a consistent way ? Can e.g.
Netbeans do this automatically ?
Why?? The application developer knows best which packages he is
going to use in his application.
not that would be a problem for the application developer.
When writing a MIDlet for MIDP and using other JSRs like JSR-120, he
had also to know and set
a dependency attrobute to his JAD and manifest to be sure it will
get only installed on a target
platform if it can run there.