[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kvm-interest
Subject:    Re: GCF questions
From:       Gary Adams - SMI Software Development <Gary.Adams () SUN ! COM>
Date:       2002-02-26 15:59:33
[Download RAW message or body]

> Date: Tue, 26 Feb 2002 15:13:59 +0000
> From: Niall Smart <niall.smart@ROCOCOSOFT.COM>
> Subject: [KVM-INTEREST] GCF questions
> To: KVM-INTEREST@JAVA.SUN.COM
>
> Hi,
>
> I have a couple of questions about the semantics of the GCF which don't
> seem to be adequately addressed by the CLDC/MIDP specifications:
>
> 1) Can StreamConnection.openXXXStream() be called more than once?  If
> so, does it have to return the same object each time?
>
> For the "socket" protocol, the J2MEWTK only allows these methods to
> be called once (subsequent calls see IOException) however IBM's J9
> allows them to be called multiple times and returns a different object
> each time.

MIDP 1.0 only covers the HttpConnection. The socket connection you are using
is beyond the official specification. JSR 118 MIDP NG is where new
network protocols will be specified.

The CLDC GCF is intended for single session or transaction usages of
I/O connections. So for HttpConnection what you are gaining access
to is a single requset/response transaction with a web server.

The Connection object itself allows for setting up request parameters and
accessing response codes and geaders independently from the basic I/O
operations. The StreamConnection combines an InputConnection and an
OutputConnection, but the actual InputStream and OutputStream are independent
aspects of the connection which are opened and closed independently.

>
>
> 2) Does the following code close the connection?
>
>      conn = (StreamConnection)Connector.open("socket://...");
>      conn.openInputStream().close()

This code :
        opens the connection
        opens the input stream
        closes the input stream

You would also need a
       conn.close()

to close the connection.

Since security checks are likely to take place on the connection setup.
It is likely that an official socket connection would also be defined
to deal with single interactions with a server. e.g. you would not be allowed
to close and reopen streams associated with a socket connection.

One of the original goals of "generic" connections, was that applications
could be written in transport independent way allowing provisioning of
applications to require simple configuration of connection strings.

>
> In J2MEWTK it doesn't, on J9 it does.

Since there is no standard reference implementation for socket url connections,
I am not surprised that you have discovery two independent interpretations
of socket connection behavior.

>
> These ambiguities cause problems when trying to write a portable GCF
> protocol handler  (I am interfacing to each vendor's GCF implementation
> through simple wrapper classes)  The problem occurs for
> Connector.openInputStream().

Yes, this is the generic opening of a stream based on a simple url string
where all that is really desired in the application is streamed input from
a designated source, and no connection specific operations are required.
e.g. simple HTTP 1.1 GET behavior with default headers.

>
> On J2MEWTK the implementation calls close on the connection object
> before returning the InputStream:
>
>      public OutputStream openOutputStream(String url)
>          throws IOException
>      {
>          OutputConnection conn = Connector.open(url);
>
>          try {
>              return conn.openOutputStream();
>          } finally {
>              conn.close();
>          }
>      }

This is the CLDC GCF Spec/RI/TCK behavior. The higher level Connection
object is closed and is no longer accessible/available to the application, which
desires to only use the output or input stream for a one shot operation.

>
> While J9 doesn't:
>
>      public OutputStream openOutputStream(String url)
>          throws IOException
>      {
>          return open(url).openOutputStream();
>      }

This looks like a bug in the J9 implementation .

>
> This means that if I implement the Sun semantics I will have unclosed
> connections hanging around in the J9 VM, or if I implement the J9
> semantics openOutputStream() will fail in the Sun VM as it will be
> returning a closed OutputStream.

Applications really should close anything they open, but it is also acceptable
for a platform to close resources which were left open unintentionally.
In the MIDP/CLDC 1.0.3 RI where you got the WTK socket protocol handler,
you will see mention of a resource cleanup registration in the native code,
that allowed the KVM during garbage collection to callback the socket
cleanup code to shutdown the dangling handle to the open connection.

Feel free to ask questions about the reference implementation on the
midp-comments@sun.com alias. Or if you have questions about interpretation
of the MIDP 1.0 specification at midp-feedback@risc.sps.mot.com.

>
>
> Regards,
>
>
> Niall
>
> --
> Niall Smart
> Rococo Software
> 9-11 Upper Baggot St.
> Dublin 4, Ireland
>
> p: +353 - 1 - 6601315 x221
> f: +353 - 1 - 6601328
> e: niall.smart@rococosoft.com
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST".  For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

 ==========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST".  For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

[prev in list] [next in list] [prev in thread] [next in thread]