dev@jsr311.java.net

Re: j2me / java 1.4.2 support

From: Dhanji R. Prasanna <dhanji_at_gmail.com>
Date: Mon, 20 Aug 2007 15:17:43 +1000

Hello Patrick

I wouldn't mind an optional-only part of the specification specifying xml or
programmatic configuration. I suggested something like that for registration
of resources. It could be extended to full configuration. This is roughly
what we're doing with JSR-303 (actually we are also specifying
overridability that way) and I imagine we will do in the Servlet 3.0 API
too.

It's probably a lot of work for this EG and it's stated timeframes though =(

Dhanji.

On 8/20/07, Patrick Mueller <pmuellr_at_yahoo.com> wrote:
>
> I did a search on the mailing list, and this topic didn't seem to
> come up at all. The current spec lists supporting anything less than
> J2SE 5.0 as a non-goal, with the reason that annotations are
> extensively used.
>
> That's a bummer. I'm wondering if the spec could be refactored to
> support a lower-level API, and annotations for language levels that
> support it. The lower-level API would basically be programmatic
> versions of the annotations. You'd never actually use this, in lieu
> of annotations, unless you had to, but that would be the point: at
> least you could.
>
> As a simple example, from the WidgetList class in the spec:
>
> @UriTemplate("widgets")
> public class WidgetList {
> @HttpMethod
> @UriTemplate("offers")
> WidgetList getDiscounted() {...}
>
> @UriTemplate("{id}")
> Widget findWidget(@UriParam("id") String id) {
> return lookupWidget(id);
> }
> }
>
> Now, imagine this without the annotations:
>
> public class WidgetList {
> WidgetList getDiscounted() {...}
> Widget findWidget(String id) {
> return lookupWidget(id);
> }
> }
>
> And using code like this to register the class:
>
> registeredClass = registry.addServiceClass(WidgetList.class);
> registeredMethod = registeredClass.addResourceMethod
> ("getDiscounted");
> registeredMethod.setUriTemplate("offers");
>
> registeredMethod = registeredClass.addSubResourceLocator
> ("findWidget")
> registeredMethod.setUriTemplate("{id}");
> registeredMethod.setUriParam("id", 1);
>
> Some additional benes:
>
> * opens the door to allow folks to define their services in some way
> other than the annotations.
>
> * the code above showed 'setters' for the service information. If
> 'getters' were also available, this could serve as a means for
> someone to provide a 'description' of the services currently
> supported, without having to parse annotations, etc, themselves.
>
> Note, this is just a thought; at least, to show that you can have
> your cake and eat it too. I wouldn't expect this kind of support to
> be added if there wasn't someone with skin in the game to actually do
> the work; presumably from the J2ME side of the house (because it
> seems unlikely someone would add this JUST for 1.4 support). What do
> the J2ME guys think about this JSR in general?
>
> Before you say J2ME is just for phones, and no one is going to want
> to run a server on their phone, please see:
>
> http://java.sun.com/javame/overview/products.jsp
>
> and scroll down to
>
> Sun Java Toolkit for CDC
>
> J2ME is not just about phones. And you also need to see this:
>
> http://www.flickr.com/photos/jacobian/1160698795/
>
> Phones can run web servers :-)
>
> Patrick Mueller
> http://muellerware.org/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>