Skip to main content

[jsr360-observers] [jsr360-experts] Re: NetworkInterface class

  • From: roger riggs < >
  • To:
  • Subject: [jsr360-observers] [jsr360-experts] Re: NetworkInterface class
  • Date: Mon, 11 Nov 2013 16:14:25 -0500
  • List-id: <>
  • Organization: Oracle Corporation

Hi Thomas,

Yes, the example below would have the desired effect.


On 11/11/2013 10:36 AM, Lampart Thomas wrote:

Hi Roger, specleads, experts,

Thanks for additional explanation. I get idea, just not completely sure yet, how to use this class.

So for my understanding, this is the AccessPoint example from the spec:

// Create options for a WiFi connection with SSID = "mynet" and password "abc"

ConnectionOption<String> ssid = new ConnectionOption<>("ssid", "mynet");

ConnectionOption<char[]> password = new ConnectionOption<>("password", new char[]{'a', 'b', 'c'});

        AccessPoint ap = AccessPoint.of("WIFI", ssid, password);

        // Ensure the connection is active


        // Open a connection using the AccessPoint

        String url = "http://...";;

ConnectionOption<AccessPoint> accessPointOption = new ConnectionOption("AccessPoint", ap);

try (HttpConnection c = (HttpConnection), accessPointOption);

             DataOutputStream os = c.openDataOutputStream()) {

             os.writeUTF("Hello World\n");

        } // Try-with-resources closes output stream and the connection

So lets assume I have multiple physical Wifi interfaces and I want to select one particular, my understanding to change the code above would be as the following:

|         // Create options for a WiFi connection with SSID = "mynet" and password 
|         ConnectionOption<String> ssid = new ConnectionOption<>("ssid", 
|         ConnectionOption<char[]> password = new 
ConnectionOption<>("password", new char[]{'a', 'b', 'c'});|
|         AccessPoint ap = AccessPoint.of("WIFI", ssid, password);|
|  |
|*         // Ensure the connection is active*|
|*         ap.connect();*|
|*         *|
|*         // Enumerate over all network interfaces of type*|
|*         NetworkInterface[] interfaces = 
|*         for (NetworkInterface ni : interfaces) {*|
|*           if (ni.getName().equals("desiredinterfacename")) {*|
|*               // Found the desired network*|
|*               ni.connect(ap);*|
|*               ...*|
|*           }*|
|*         }*|**
|  |
|         // Open a connection using the AccessPoint|
|         String url = "http://...";;|
|         ConnectionOption<AccessPoint> accessPointOption = new 
ConnectionOption("AccessPoint", ap);|
|  |
|         try (HttpConnection c = (HttpConnection), 
|              DataOutputStream os = c.openDataOutputStream()) {|
|              os.writeUTF("Hello World\n");|
|         } // Try-with-resources closes output stream and the connection|

Is this assumption correct ?

Kind regards


*From:*Roger Riggs 
[mailto: ]
*Sent:* Freitag, 8. November 2013 02:49

*Subject:* [jsr360-observers] [jsr360-experts] Re: NetworkInterface class

Hi Thomas,

The NetworkInterface is only necessary in cases where there are multiple
radios and the exact configuration of each radio is to be controlled by
the application.

Supposing a device with multiple SIM cards and multiple 3G radios.
The application would use the MEEP CellularNetwork and
Subscriber information to select the SIM card to register to each network.
Following that 3G configuration, the AccessPoint for each network
would need to be selected and connected to the NetworkInterface
corresponding to each CellularNetwork.
[There is a pending addition to CellularNetwork to return the
NetworkInterface corresponding to the CellularNetwork.]

In the case of a single radio, even with multiple SIM cards, the first step
is the same, registering to the network with one of the SIM cards.
Since there is only one radio there is only 1 NetworkInterface per type,
and no need to match the Access to a specific NetworkInterface.

Multiple radios of the same type is expected to be an uncommon
configuration and the AccessPoint API keeps the normal case simple
by handling the case where the AccessPoint and NetworkInterface
can be selected by the implementation.  I expect in most cases
the implementation automatically handles the details unless the
application specification needs to control the registration and
setup of the network parameters.


On 11/7/13 4:52 AM, Lampart Thomas wrote:

    Dear specleads, experts,

    I did look a little bit closer at the new class "NetworkInterface"
    and would like to ask for some clarification how this class is
    supposed to work and how it is supposed to be used by a midlet.

    As the documentation states: "In most cases, applications will
    need to use only the AccessPoint API to select to connect and
    disconnect AccessPoints connections. The NetworkInterface APIs are
    needed in cases where more detailed management of connections is

    What could this "detailed management" be ? The class does not
    offer any new ("exciting") methods which give additional
    functionality to AccessPoint ? Or am I missing something ?

    Also the example seems a bit confusing to me, as it looks for
    "unused" NetworkInterfaces to connect an AccessPoint. Why does it
    need to be used ?

    Can you please give a real live example where it makes sense to
    have the NetworkInterface class.

    Best regards


    *From:*Michael Lagally 
[mailto: ]
    *Sent:* Montag, 4. November 2013 11:09

<mailto: >
    *Subject:* [jsr360-observers] [jsr360-experts] JSR360 EG call
    notes - Wednesday, Oct 30th

    Dear JSR 360 experts,

    Dear JSR360 EG members,

    Here are the notes from the last JSR 360 call on October 30th,
    14:00-14:40 CET.


    Thomas Lampart, Gemalto

    Michael Lagally, Oracle

    Roger Riggs, Oracle
    Yiming Zhao, Nokia

    Call Notes:

    SpecLead Draft 4

    The SpecLead Draft 4 which was provided to the expert group last
    week contains

    bug fixes and clarifications that were added to the spec after the
    PR version.

    Roger and Michael walked through the changes one by one and explained

    the reasons for these updates.

    The list of changes was sent to the EG reflector last week and is
    included here

    again for reference.

    The draft is very close to the PFD version, which will be provided
    in the next two weeks.

    EG members are encouraged to review the draft and the changes and
    provide feedback

    about all issues to the spec leads before *Nov 12th *to allow for
    consideration in the PFD.

    Proposed Final Draft schedule

    We plan to submit the Proposed Final Draft on or before *November

    A follow-up EG call is scheduled for *Tuesday, Nov 12th, 2pm
    CET* to discuss any potential issues

    as reported by the EG.

    The PFD version of the spec will be provided for final EG review
    shortly after that and we will

    seek *EG approval for the PFD by* *November 27th.*

    New EG member

    Yiming Zhao took over the EG representation for Nokia from Irvine Ye.

    Best regards,

    Michael + Roger


    This message and any attachments are intended solely for the
    addressees and may contain confidential information. Any
    unauthorized use or disclosure, either whole or partial, is
    E-mails are susceptible to alteration. Our company shall not be
    liable for the message if altered, changed or falsified. If you
    are not the intended recipient of this message, please delete it
    and notify the sender.
    Although all reasonable efforts have been made to keep this
    transmission free from viruses, the sender will not be liable for
    damages caused by a transmitted virus

This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus

[jsr360-observers] [jsr360-experts] JSR360 EG call notes - Wednesday, Oct 30th

Michael Lagally 11/04/2013

[jsr360-observers] [jsr360-experts] Re: JSR360 EG call notes - Wednesday, Oct 30th

Werner Keil 11/04/2013

[jsr360-observers] [jsr360-experts] NetworkInterface class

Lampart Thomas 11/07/2013

[jsr360-observers] [jsr360-experts] Re: NetworkInterface class

Werner Keil 11/07/2013

[jsr360-observers] [jsr360-experts] Re: NetworkInterface class

Michael Lagally 11/08/2013

[jsr360-observers] [jsr360-experts] Re: NetworkInterface class

Roger Riggs 11/08/2013

[jsr360-observers] [jsr360-experts] Re: Re: NetworkInterface class

Lampart Thomas 11/11/2013

[jsr360-observers] [jsr360-experts] Re: NetworkInterface class

roger riggs 11/11/2013
Please Confirm