Skip to main content

[jsr361-experts] Re: [jsr361-observers] Minutes of EG meeting on August 1, 2013

  • From: Werner Keil < >
  • To:
  • Subject: [jsr361-experts] Re: [jsr361-observers] Minutes of EG meeting on August 1, 2013
  • Date: Thu, 1 Aug 2013 17:15:51 +0200

Hi,

Not sure, if PMO adjusted that, but the JSR detail page shows no "8". It
says
JavaTM ME Embedded Profile

Only some slides or the proposed Spec License say differently
>"Specification: JSR-xxx JavaTM Platform, Micro Edition 8 Java ME Embedded
Profile ("Specification")"

Since the JIRA for Kenai still doesn't seem in sync with that for
java.netand I can't log in there, here are 2 JavaDoc issues I found

javax/microedition/event/EventManager.html
wrongly quotes
Adding an Event Listener

The application must first get an instance of EventManager. The
EventManager.addListener method is called to add the listener using system
event or the application event name. The application must have the required
permission to query the requested event or a SecurityException will be
thrown.

       Event battery;
       boolean authmode = false;
       EventManager ssm = EventManager.getInstance(this);

but the getInstance() method has no arguments according to latest JavaDoc.

As it wasn't further mentioned in the minutes, let me just summarize, that
for cases where a "valueOf()" method was previously used to return an
instance based on some arguments, it is occasionally abbreviated to "of()"
now. The best example would be the (closer to Public Draft[?]) GCF 8 API
element
javax/microedition/io/AccessPoint.html

It uses the of() notion, while all singleton type of classes in MEEP with
no argument use getInstance().

In cases where you'd have both together (not sure, if I saw this in 360 or
361, but e.g. JSR 354 contains one or two) we so far called both of().
making it more consistent.

Hope, this isn't mixed anywhere in the new API? I might have a look, but if
this is the rationale behind the names in each case, that sounds fine.

The class
javax/microedition/lui/Display.html

Has the following JavaDoc problem:
Display Resources

A device MAY have one or more display resources for interacting with the
user. Each resource includes a line-oriented display device and may also
include keys or other appropriate means for user input. Those means MUST
create key events, that can be processed by a Dssplay via an associated
KeyListener<file:///D:/Temp/MEEP_1.0_SpecLead_Draft_v0.7_20130730/meep/api/javax/microedition/key/KeyListener.html>,
as defined in the kavax.microedition.key package.

It should be "Display"

Kind Regards,
Werner

On Thu, Aug 1, 2013 at 4:35 PM, 
< >
 wrote:

> Dear experts,
>
> here come the minutes of today's telco.
>
> - Latest uploaded version contains just editorial changes, no
> modifications of the API since last one. Mainly the description of
> provisioning has been improved in order to make clearer which
> requirements are common (independent on the chosen provisioning
> mechanism), and which are OTA provisioning specific.
>
> - Thomas has asked for some additional changes in the power management
> package: a possibility to go into airplane mode (while this might not
> be the right term as it is unlikely - but not impossible! :-) - for an
> embedded device to go aboard a plane, but this is rather for switcching
> off the radio in order to spare power) and a possibility to initiate a
> reboot (which is not exactly a feature of power management, but it
> seems to be the best place for it)
> AI: Volker to provide a proposal
>
> - Werner had some questions about optionality and the demarcation
> between packages, which could be clarified during the call.
>
> - Thomas and Werner claimed about the confusing version strings used in
> the spec. Currently we have:
> MEEP 8 a a platform-level name
> MEEP 8 as the name of the spec
> MEEP-1.0.0 as the profile version
> MEEP-1.0 as the value for microedition.profile
> The reason is that MEEP is part of the ME8 platform, but it is the
> first version of MEEP. The proposal is (as a compromise) to change at
> least the profile version into MEEP-1.8.0 and the value of
> microedition.profile into MEEP-1.8
> (as we have it for CLDC)
> AI Volker to clarify this with the ME8 architects
>
> - Public Review of the spec is planned for end of August; for this we
> have to provide documents to PMO until August 15. Issues that should be
> resolved before PR should be raised asap.
>
> - I will send out an email soon in order to ask you to formally confirm
> that you have no concerns against going into PR phase.
>
> Best regards -
> Volker
>

Attachment: 347.gif
Description: GIF image



[jsr361-experts] Minutes of EG meeting on August 1, 2013

volker.bauche 08/01/2013

[jsr361-experts] Re: [jsr361-observers] Minutes of EG meeting on August 1, 2013

Werner Keil 08/01/2013

[jsr361-experts] Re: [jsr361-observers] Minutes of EG meeting on August 1, 2013

Volker Bauche 08/01/2013

[jsr361-experts] Power management Updates

Volker Bauche 08/02/2013

[jsr361-experts] Re: Power management Updates

Lampart Thomas 08/02/2013

[jsr361-experts] Re: Power management Updates

roger riggs 08/02/2013

[jsr361-experts] Re: Power management Updates

Lampart Thomas 08/02/2013

[jsr361-experts] Re: Power management Updates

Volker Bauche 08/02/2013

[jsr361-experts] Re: [jsr361-observers] Re: Power management Updates

Werner Keil 08/02/2013

[jsr361-experts] Re: [jsr361-observers] Re: Re: Power management Updates

Volker Bauche 08/02/2013
 
 
Close
loading
Please Confirm
Close