www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <ge...@apache.org>
Subject Re: JSR 307
Date Mon, 25 Sep 2006 19:01:30 GMT

Steve Loughran wrote:
> Is anyone looking at JSR 307, the new mobility ApI stuff?
> http://jcp.org/en/jsr/detail?id=307
> "This JSR provides two APIs: one to establish packet data sessions with
> particular attributes such as bandwidth, latency, QoS or destination APN
> (for GPRS) and another for providing a framework for managing network
> mobility for mobile platforms and applications on those platforms. Data
> control and network mobility control are linked together because many
> use cases for the data capabilities in this JSR also include operations
> that need information about the available networks (to determine what
> services to offer to the user)."
> I dont really want to add any extra workload, but think it is utterly
> wrong to not think about J2SE needs in this area.
> "3 The Executive Committees would like to ensure JSR submitters think
> about how their proposed technology relates to all of the Java platform
> editions. Please provide details here for which platform editions are
> being targeted by this JSR, and how this JSR has considered the
> relationship with the other platform editions.
> The target platform is the MID Profile on Java ME"
> Every time your laptop has to have its proxy settings changed as you
> move from work to home, every time your Java app hangs because the DNS
> address of a machine changed or because the network went away without
> telling you, its because there's no consideration of network awareness
> in J2SE applications.

Plus, your operating system is probably really crappy too.

> 1. Java RMI needs to become aware of network state changes.
> 2. all server-side applications need to be offered the option of being
> notified of network adapters coming and going, so they can re-listen on
> new devices.
> 3. J2SE DNS support needs to stop assuming that an nslookup is eternal.
> I know it makes sense for applet security, but its time to move on and
> recognise that outside of applets, IP addresses change over the life of
> a long running client or server application.

Hm.  What would you want it to do?  Any stateful connections *should*
terminate, right?

What to do isn't entirely obvious to me - how do you distinguish a
termination of a connection due to mobility factors, vs plain old failure?

> In the PC business (and Geir probably has those numbers more accurately
> than me), we see the following trend
>  -the primary machine for business and home users is becoming a laptop,
> with the server being the place that applications get deployed.

Maybe. I don't have any numbers right now (I'm in yetanotherplane), but
I wonder.  First, I resent being chained to a laptop sometimes - limited
power, small screen (compared to the big beautiful things we can find on
desktops now).  But then I resent also the fact that my data isn't
easily movable.  (Web3.0!)

The other thing is that with decent bandwidth and virtualization, I'm
fairly convinced that we'll return to apps deployed on the client, but
in a dynamic manner.

> The main
> exceptions to this are embedded clients for specific workers, and living
> room/home entertainment systems. Even server-side, the push towards
> adaptive and self-healing applications creates pressure for adaptive
> networking infrastructure in which a network partition is a transient
> event, rather than something requiring a system reboot.

Yes, but given how startled and uncomfortable my windows box gets when
anything - anything- changes...  maybe the java platform is a good place
to start, but I worry what can be done if the underpinnings are soft.
Java needs to be able to promise that any JRE can offer the same

> The fact that J2SE/Java EE doesnt have any real network awareness API
> (there is an offline operation exposed only to JWS, and some slightly
> more flexible proxy support in Java 5) means that Java client
> applications dont work reliably on laptops, and server side apps are
> more brittle than neccessary. Presumably, the fact that Sun doesnt make
> laptops makes them unaware of these issues, and the mobile phone vendors
> arent going to care about laptops either. That leaves it to us.
> If nobody wants to get on the commitee, the least Apache can do is
> provide some feedback at this early stage about why desktop and server
> side Java must not be left out. I will do it, unless there are other
> volunteers.
> Comments?

Well, we can certainly comment on this, or even start out own SE JSR.  I
do think that we'll be boiling the ocean if we do try both ME and SE at
the same time.  There probably is a lot of learning we can do though
from the ME people.


> -steve

View raw message