«

On 04/03/2012 8:55 PM, Arne Vajhøj wrote:
> I think that a "relative" measurement fits better:
>
> weight = level of functionality or complexity provided / level of
> functionality or complexity necessary to support
>
> Let me clarify with an example:
>
> I consider a Java library with methods implementing
> 10000 mathematical function with no dependencies to
> be lighter than a Java component exposing only 3 methods that require:
> * an EJB container
> * a message queue
> * an Oracle database (due to some PL/SQL SP bing used)

An excellent suggestion, but if "marketing" ideas have captured
light/heavy already, we might need a different pair of terms (until they
capture those, too).

On 03/04/2012 04:20 PM, Jan Burse wrote:
> Jeff Higgins schrieb:
>>>
>>
>> Thanks, I think that makes a very fine general purpose definition.
>>
>> I'm tempted to include modularity in there somewhere.
>
> Eclipse calls its own plugin framework
> lightweight. At least the Wiki article
> says so:
>
> This plug-in mechanism is a
> lightweight software componentry
> framework.
>
> http://en.wikipedia.org/wiki/Eclipse...9#Architecture
<http://openjdk.java.net/projects/jigsaw/>

Jeff Higgins schrieb:
> On 03/05/2012 02:38 PM, Jan Burse wrote:
>
> >> Abstract Application Annotations
>
>> What if I want to decide whether my JFrame
>> is a deamon or not at runtime?
>>
>
> Shrugs, I'm sure the unknown development team hasn't worked out all the
> details yet.
>

Annotations, well, they should
give information to tool chains.

Of course we can try to turn every
framework into a tool. (Also a
kind of business model)

But this doesn't make the resulting
artefact more lightweight.

You will have as a result:
- the framework
+ the annotation definitions (for Java)
+ the annotation processor (at runtime
eventually, so that there is no real
tool step)

And then you loose flexibility, in
case the framework gets locked away
from the end-user (the programmer).

Bye

Bye

On 3/5/2012 4:35 PM, David Lamb wrote:
> On 04/03/2012 8:55 PM, Arne Vajhøj wrote:
>> I think that a "relative" measurement fits better:
>>
>> weight = level of functionality or complexity provided / level of
>> functionality or complexity necessary to support
>>
>> Let me clarify with an example:
>>
>> I consider a Java library with methods implementing
>> 10000 mathematical function with no dependencies to
>> be lighter than a Java component exposing only 3 methods that require:
>> * an EJB container
>> * a message queue
>> * an Oracle database (due to some PL/SQL SP bing used)
>
> An excellent suggestion, but if "marketing" ideas have captured
> light/heavy already, we might need a different pair of terms (until they
> capture those, too).

I don't think we really need new terms. When one use heavy/light
it is most likely to marketing and/or managers anyway.

Arne