Skip to main content

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

  • From: Volker Bauche < >
  • To:
  • Subject: [jsr361-experts] Re: [jsr361-observers] Minutes of EG meeting on August 1, 2013
  • Date: Thu, 01 Aug 2013 19:13:01 +0200

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Werner, all<br>
      <br>
      see comments below.<br>
      <br>
      BR-<br>
      Volker<br>
      <br>
      Am 01.08.2013 17:15, schrieb Werner Keil:<br>
    </div>
    <blockquote
cite="mid:
      "
      type="cite">Hi,
      <div><br>
      </div>
      <div>Not sure, if PMO adjusted that, but the JSR detail page shows
        no "8". It says&nbsp;</div>
      <div><span
style="color:rgb(97,148,35);font-family:Arial,Helvetica,sans-serif;font-size:16px;font-weight:bold;line-height:16px">Java</span><font
style="color:rgb(97,148,35);font-family:Arial,Helvetica,sans-serif;font-weight:bold;line-height:16px"
          size="-2"><sup>TM</sup></font><span
style="color:rgb(97,148,35);font-family:Arial,Helvetica,sans-serif;font-size:16px;font-weight:bold;line-height:16px">&nbsp;ME
          Embedded Profile</span><br>
        <br>
        Only some slides or the proposed Spec License say differently</div>
      <div>&gt;"Specification: JSR-xxx JavaTM Platform, Micro Edition 8
        Java ME Embedded Profile ("Specification")"</div>
    </blockquote>
    This is true, but for some reason, when filing a JSR, nobody
    considers to add a version number for some reason<br>
    (while it would make a lot of sense, especially for configurations
    and profiles).<br>
    We are in good company here: also the first versions of CLDC, MIDP
    and IMP had no version numbers<br>
    on their JSR detail page, but the respective specifications have
    one, at least in the subtitle. :-)<br>
    <blockquote
cite="mid:
      "
      type="cite">
      <div><br>
      </div>
      <div>Since the JIRA for Kenai still doesn't seem in sync with that
        for <a moz-do-not-send="true" href="http://java.net";>java.net</a>
        and I can't log in there, here are 2 JavaDoc issues I found</div>
      <div><br>
      </div>
      <div>javax/microedition/event/EventManager.html</div>
      <div>wrongly quotes</div>
      <div>
        <h4 id="AddEventListener"
style="font-size:1.3em;color:rgb(53,56,51);font-family:Arial,Helvetica,sans-serif;background-color:rgb(255,255,255)">Adding
          an Event Listener</h4>
        <p
style="color:rgb(53,56,51);font-family:Arial,Helvetica,sans-serif;font-size:12px;background-color:rgb(255,255,255)">The
          application must first get an instance of&nbsp;<code
            style="font-size:1.2em">EventManager</code>. The&nbsp;<code
            style="font-size:1.2em">EventManager.addListener</code>&nbsp;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&nbsp;<code
            style="font-size:1.2em">SecurityException</code>&nbsp;will be
          thrown.</p>
        <pre style="font-size:1.3em;margin-top:0px;background-color:rgb(255,255,255)"><span style="color:rgb(53,56,51)">       Event battery;
       boolean authmode = false;
       </span><font color="#ff0000">EventManager ssm = EventManager.getInstance(this);</font></pre>
      </div>
      <div>but the getInstance() method has no arguments according to
        latest JavaDoc.</div>
    </blockquote>
    Yes, true. This is a bug, caused by a change of the getInstance
    signature that used to have a parameter<br>
    in an early version. Forgot to adjust the examples, did now - as
    will be viewable in the next version<br>
    (there have been three occurences in the EventManager class
    description).<br>
    <blockquote
cite="mid:
      "
      type="cite">
      <div><br>
      </div>
      <div>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<img
          src="cid:part2.04010808.05020306@oracle.com" goomoji="347"
          style="margin: 0px 0.2ex; vertical-align: middle;">) GCF 8 API
        element</div>
      <div>javax/microedition/io/AccessPoint.html</div>
      <div><br>
      </div>
      <div>It uses the of() notion, while all singleton type of classes
        in MEEP with no argument use getInstance().</div>
      <div><br>
      </div>
      <div>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.&nbsp;</div>
      <div><br>
      </div>
      <div>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.</div>
    </blockquote>
    All getInstance methods in MEEP are without parameters, so it makes
    sense to keep them as they are, as of() makes only sense with
    parameters. In an offline talk with Werner we agreed to this.<br>
    <blockquote
cite="mid:
      "
      type="cite">
      <div><br>
      </div>
      <div>The class</div>
      <div>javax/microedition/lui/Display.html</div>
      <div><br>
      </div>
      <div>Has the following JavaDoc problem:</div>
      <div>
        <h3
style="font-size:1.4em;color:rgb(53,56,51);font-family:Arial,Helvetica,sans-serif;background-color:rgb(255,255,255)">Display
          Resources</h3>
        <p
style="font-family:Arial,Helvetica,sans-serif;font-size:12px;background-color:rgb(255,255,255)"><span
            style="color:rgb(53,56,51)">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 </span><font color="#ff0000">Dssplay </font><font
            color="#353833">via an associated&nbsp;</font><a
            moz-do-not-send="true"
href="file:///D:/Temp/MEEP_1.0_SpecLead_Draft_v0.7_20130730/meep/api/javax/microedition/key/KeyListener.html"
            title="interface in javax.microedition.key"
            style="color:rgb(76,107,135);text-decoration:none"><code
              style="font-size:1.2em">KeyListener</code></a><font
            color="#353833">, as defined in the&nbsp;</font><code
            style="color:rgb(53,56,51);font-size:1.2em">kavax.microedition.key</code><font
            color="#353833">&nbsp;package.</font></p>
      </div>
      <div><br>
      </div>
      <div>It should be "Display"</div>
    </blockquote>
    Yes, thanks. Have fixed this, and also the "kavax" to "javax" a few
    words forward in the same sentence. :-)<br>
    <br>
    Best regards -<br>
    Volker<br>
    <blockquote
cite="mid:
      "
      type="cite">
      <div><br>
      </div>
      <div>Kind Regards,</div>
      <div>Werner</div>
      <div><br>
        <div class="gmail_quote">On Thu, Aug 1, 2013 at 4:35 PM, <span
            dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:
      " target="_blank">
      </a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear
            experts,<br>
            <br>
            here come the minutes of today's telco.<br>
            <br>
            - Latest uploaded version contains just editorial changes,
            no<br>
            modifications of the API since last one. Mainly the
            description of<br>
            provisioning has been improved in order to make clearer
            which<br>
            requirements are common (independent on the chosen
            provisioning<br>
            mechanism), and which are OTA provisioning specific.<br>
            <br>
            - Thomas has asked for some additional changes in the power
            management<br>
            package: a possibility to go into airplane mode (while this
            might not<br>
            be the right term as it is unlikely - but not impossible!
            :-) - for an<br>
            embedded device to go aboard a plane, but this is rather for
            switcching<br>
            off the radio in order to spare power) and a possibility to
            initiate a<br>
            reboot (which is not exactly a feature of power management,
            but it<br>
            seems to be the best place for it)<br>
            AI: Volker to provide a proposal<br>
            <br>
            - Werner had some questions about optionality and the
            demarcation<br>
            between packages, which could be clarified during the call.<br>
            <br>
            - Thomas and Werner claimed about the confusing version
            strings used in<br>
            the spec. Currently we have:<br>
            MEEP 8 a a platform-level name<br>
            MEEP 8 as the name of the spec<br>
            MEEP-1.0.0 as the profile version<br>
            MEEP-1.0 as the value for microedition.profile<br>
            The reason is that MEEP is part of the ME8 platform, but it
            is the<br>
            first version of MEEP. The proposal is (as a compromise) to
            change at<br>
            least the profile version into MEEP-1.8.0 and the value of<br>
            microedition.profile into MEEP-1.8<br>
            (as we have it for CLDC)<br>
            AI Volker to clarify this with the ME8 architects<br>
            <br>
            - Public Review of the spec is planned for end of August;
            for this we<br>
            have to provide documents to PMO until August 15. Issues
            that should be<br>
            resolved before PR should be raised asap.<br>
            <br>
            - I will send out an email soon in order to ask you to
            formally confirm<br>
            that you have no concerns against going into PR phase.<br>
            <br>
            Best regards -<br>
            Volker<br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>

Attachment: giffjspLSZ6BR.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