Re: Why J2ME?

[Stefano Mazzocchi <st...@apache.org>]

Andrzej Jan Taramina wrote:
> Stefano objects:
> 
> 
>>Let me remind you that Avalon is a server side framework and it was 
>>designed to be that way and the ASF created a project to substain that.
> 
> 
> Embedded controllers ARE server side in many aspects and need a 
> lightweight container implementation.  Makes sense to build that on the Avalon 
> framework if possible.

Point taken and acknowledged.

Yet, I'm a little bit scared by the fact that this project is moving 
into a technological realm that is very restrictive.

Like I said, I fear the consequences of a 'one size fits all' framework 
or common-denominator-down-your-throwt.

It's true that Avalon is, more than anything, a collection of patterns, 
metapatterns and guidelines, enforced by programmatic constructs (java 
interfaces today, something else tomorrow) and container implementations.

But say that the JCP comes up with the concept of metadata built into 
Java 1.5 (Avalon will need that in the future) but they decide, for 
simplicity and cost of implementation, to leave this feature out of J2ME.

What do we do? ignore a nice feature that 90% of our users would love to 
have because it's not available on J2ME?

I would love to be proven wrong, but I don't want this project to follow 
into Sun's marketing WORA traps and influence its evolution because of that.

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Why J2ME?

[Stefano Mazzocchi <st...@apache.org>]

Berin Loritsch wrote:
>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>
>>Like I said, I fear the consequences of a 'one size fits all' 
>>framework 
>>or common-denominator-down-your-throwt.
> 
> 
> The major difference between the Avalon ME (for lack of a better
> name) and the regular container is that ME will be static--the
> classes needed for running the container will be pregenerated.
> 
> 
> 
>>But say that the JCP comes up with the concept of metadata built into 
>>Java 1.5 (Avalon will need that in the future) but they decide, for 
>>simplicity and cost of implementation, to leave this feature 
>>out of J2ME.
>>
>>What do we do? ignore a nice feature that 90% of our users 
>>would love to 
>>have because it's not available on J2ME?
> 
> 
> 
> No.  We interpret it at build time, and provide generated helper
> classes that the ME runtime uses.  I.e. we trade run-time discovery
> of components and component metadata for compile-time discovery
> of components and component metadata.
> 
> That is the distinction.  Nothing more.

Fair enough.

I'm not against build-time additions that will make Avalon more J2ME 
friendly, as long as J2SE remains the top priority for normal Avalon 
operations.

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Why J2ME?

[Berin Loritsch <bl...@citi-us.com>]

> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> 
> Like I said, I fear the consequences of a 'one size fits all' 
> framework 
> or common-denominator-down-your-throwt.

The major difference between the Avalon ME (for lack of a better
name) and the regular container is that ME will be static--the
classes needed for running the container will be pregenerated.


> 
> But say that the JCP comes up with the concept of metadata built into 
> Java 1.5 (Avalon will need that in the future) but they decide, for 
> simplicity and cost of implementation, to leave this feature 
> out of J2ME.
> 
> What do we do? ignore a nice feature that 90% of our users 
> would love to 
> have because it's not available on J2ME?


No.  We interpret it at build time, and provide generated helper
classes that the ME runtime uses.  I.e. we trade run-time discovery
of components and component metadata for compile-time discovery
of components and component metadata.

That is the distinction.  Nothing more.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>