You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by "Oliver B. Fischer" <o....@swe-blog.net> on 2014/11/29 00:38:28 UTC
Thoughts on type conversion support
Hi,
before touching the design document I would like to share some thoughts
on our type conversion support.
I summary I would like add the following rules to the design document:
1. If the target data type is java.lang.String no conversion is needed.
2. If the target data type is not java.lang.String and if the target
data type provides a static T valueOf(String) method than this method
will be used as factory method for the target value.
3. If the target data type is not java.lang.String and if the target
data type provides a ctor with a single String parameter this ctor will
be used to create a instance of the target data type.
4. In case there is a registered PropertyAdapter implementation for the
required target datatype this implementation will have precedence.
wdyt?
Oliver
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Thoughts on type conversion support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Can makes sense, in particular a cdi event to collect adapters or for a
full standalone app for instance ;)
Le 29 nov. 2014 12:25, "Anatole Tresch" <at...@gmail.com> a écrit :
> Exactly thats the case. We can even discuss removing the register method,
> we can do this as well in other ways...
> Romain Manni-Bucau <rm...@gmail.com> schrieb am Sa., 29. Nov. 2014
> um
> 12:12:
>
> > Ok then. While register call can be optional and this facade support
> > pluggability and is bound to an app/context all is fine.
> > Le 29 nov. 2014 12:08, "Anatole Tresch" <at...@gmail.com> a écrit :
> >
> > > No. PropertyAdapters is the manager and access point who is aware of
> the
> > > propertyAdapter instances (no s at thr end). Internally the singleton
> > > delegates to an spi that can is loaded from the Bootstrap. The loading
> > > policy of the Bootstrap can be configured, so dynamic lookup eg using
> CDI
> > > can be supported similarly as ServiceLoader in SE/ME. This mechanism is
> > > similar to JSR354 and has been proven to work with all kind of
> containers
> > > araound. It even can support multiple mechsnisms in paralell, eg
> > > ServiceLoader, CDI/atinject and something custom build...
> > >
> > > Cheers
> > > Anatole
> > > Romain Manni-Bucau <rm...@gmail.com> schrieb am Sa., 29. Nov.
> 2014
> > > um
> > > 11:51:
> > >
> > > > Shouldnt propertyadapters be an interface? Default would use a
> standzrd
> > > SPI
> > > > but you can change it (closed set, osgi etc...).
> > > > Le 29 nov. 2014 01:24, "Oliver B. Fischer" <
> o.b.fischer@swe-blog.net>
> > a
> > > > écrit :
> > > >
> > > > > @John I think it is quite convenient to reuse these mechanisms.
> > > Actually
> > > > I
> > > > > think nowadays we should support the automatic detection of
> resources
> > > > (how
> > > > > ever we call them). This means more work and even more tests for us
> > but
> > > > our
> > > > > users will love it. I like the way of the FasterXML/jackson [1]:
> Add
> > it
> > > > to
> > > > > the classpath and we will use it.
> > > > >
> > > > >
> > > > > [1] https://github.com/FasterXML/jackson
> > > > >
> > > > > Am 29.11.14 00:51, schrieb John D. Ament:
> > > > >
> > > > >> Instead of having a PropertyAdapter, can we just ask them to
> > implement
> > > > >> java.util.function.Function<?,String> or point to a lambda
> > expression
> > > > >> that
> > > > >> supports it?
> > > > >>
> > > > >> I would prefer that over 2 & 3 since in most cases a string
> > > ctor/factory
> > > > >> won't work without lots of lookup logic.
> > > > >>
> > > > >
> > > > > --
> > > > > N Oliver B. Fischer
> > > > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > > > P +49 30 44793251
> > > > > M +49 178 7903538
> > > > > E o.b.fischer@swe-blog.net
> > > > > S oliver.b.fischer
> > > > > J oliver.b.fischer@jabber.org
> > > > > X http://xing.to/obf
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Thoughts on type conversion support
Posted by Anatole Tresch <at...@gmail.com>.
Exactly thats the case. We can even discuss removing the register method,
we can do this as well in other ways...
Romain Manni-Bucau <rm...@gmail.com> schrieb am Sa., 29. Nov. 2014 um
12:12:
> Ok then. While register call can be optional and this facade support
> pluggability and is bound to an app/context all is fine.
> Le 29 nov. 2014 12:08, "Anatole Tresch" <at...@gmail.com> a écrit :
>
> > No. PropertyAdapters is the manager and access point who is aware of the
> > propertyAdapter instances (no s at thr end). Internally the singleton
> > delegates to an spi that can is loaded from the Bootstrap. The loading
> > policy of the Bootstrap can be configured, so dynamic lookup eg using CDI
> > can be supported similarly as ServiceLoader in SE/ME. This mechanism is
> > similar to JSR354 and has been proven to work with all kind of containers
> > araound. It even can support multiple mechsnisms in paralell, eg
> > ServiceLoader, CDI/atinject and something custom build...
> >
> > Cheers
> > Anatole
> > Romain Manni-Bucau <rm...@gmail.com> schrieb am Sa., 29. Nov. 2014
> > um
> > 11:51:
> >
> > > Shouldnt propertyadapters be an interface? Default would use a standzrd
> > SPI
> > > but you can change it (closed set, osgi etc...).
> > > Le 29 nov. 2014 01:24, "Oliver B. Fischer" <o....@swe-blog.net>
> a
> > > écrit :
> > >
> > > > @John I think it is quite convenient to reuse these mechanisms.
> > Actually
> > > I
> > > > think nowadays we should support the automatic detection of resources
> > > (how
> > > > ever we call them). This means more work and even more tests for us
> but
> > > our
> > > > users will love it. I like the way of the FasterXML/jackson [1]: Add
> it
> > > to
> > > > the classpath and we will use it.
> > > >
> > > >
> > > > [1] https://github.com/FasterXML/jackson
> > > >
> > > > Am 29.11.14 00:51, schrieb John D. Ament:
> > > >
> > > >> Instead of having a PropertyAdapter, can we just ask them to
> implement
> > > >> java.util.function.Function<?,String> or point to a lambda
> expression
> > > >> that
> > > >> supports it?
> > > >>
> > > >> I would prefer that over 2 & 3 since in most cases a string
> > ctor/factory
> > > >> won't work without lots of lookup logic.
> > > >>
> > > >
> > > > --
> > > > N Oliver B. Fischer
> > > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > > P +49 30 44793251
> > > > M +49 178 7903538
> > > > E o.b.fischer@swe-blog.net
> > > > S oliver.b.fischer
> > > > J oliver.b.fischer@jabber.org
> > > > X http://xing.to/obf
> > > >
> > > >
> > >
> >
>
Re: Thoughts on type conversion support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ok then. While register call can be optional and this facade support
pluggability and is bound to an app/context all is fine.
Le 29 nov. 2014 12:08, "Anatole Tresch" <at...@gmail.com> a écrit :
> No. PropertyAdapters is the manager and access point who is aware of the
> propertyAdapter instances (no s at thr end). Internally the singleton
> delegates to an spi that can is loaded from the Bootstrap. The loading
> policy of the Bootstrap can be configured, so dynamic lookup eg using CDI
> can be supported similarly as ServiceLoader in SE/ME. This mechanism is
> similar to JSR354 and has been proven to work with all kind of containers
> araound. It even can support multiple mechsnisms in paralell, eg
> ServiceLoader, CDI/atinject and something custom build...
>
> Cheers
> Anatole
> Romain Manni-Bucau <rm...@gmail.com> schrieb am Sa., 29. Nov. 2014
> um
> 11:51:
>
> > Shouldnt propertyadapters be an interface? Default would use a standzrd
> SPI
> > but you can change it (closed set, osgi etc...).
> > Le 29 nov. 2014 01:24, "Oliver B. Fischer" <o....@swe-blog.net> a
> > écrit :
> >
> > > @John I think it is quite convenient to reuse these mechanisms.
> Actually
> > I
> > > think nowadays we should support the automatic detection of resources
> > (how
> > > ever we call them). This means more work and even more tests for us but
> > our
> > > users will love it. I like the way of the FasterXML/jackson [1]: Add it
> > to
> > > the classpath and we will use it.
> > >
> > >
> > > [1] https://github.com/FasterXML/jackson
> > >
> > > Am 29.11.14 00:51, schrieb John D. Ament:
> > >
> > >> Instead of having a PropertyAdapter, can we just ask them to implement
> > >> java.util.function.Function<?,String> or point to a lambda expression
> > >> that
> > >> supports it?
> > >>
> > >> I would prefer that over 2 & 3 since in most cases a string
> ctor/factory
> > >> won't work without lots of lookup logic.
> > >>
> > >
> > > --
> > > N Oliver B. Fischer
> > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > P +49 30 44793251
> > > M +49 178 7903538
> > > E o.b.fischer@swe-blog.net
> > > S oliver.b.fischer
> > > J oliver.b.fischer@jabber.org
> > > X http://xing.to/obf
> > >
> > >
> >
>
Re: Thoughts on type conversion support
Posted by Anatole Tresch <at...@gmail.com>.
No. PropertyAdapters is the manager and access point who is aware of the
propertyAdapter instances (no s at thr end). Internally the singleton
delegates to an spi that can is loaded from the Bootstrap. The loading
policy of the Bootstrap can be configured, so dynamic lookup eg using CDI
can be supported similarly as ServiceLoader in SE/ME. This mechanism is
similar to JSR354 and has been proven to work with all kind of containers
araound. It even can support multiple mechsnisms in paralell, eg
ServiceLoader, CDI/atinject and something custom build...
Cheers
Anatole
Romain Manni-Bucau <rm...@gmail.com> schrieb am Sa., 29. Nov. 2014 um
11:51:
> Shouldnt propertyadapters be an interface? Default would use a standzrd SPI
> but you can change it (closed set, osgi etc...).
> Le 29 nov. 2014 01:24, "Oliver B. Fischer" <o....@swe-blog.net> a
> écrit :
>
> > @John I think it is quite convenient to reuse these mechanisms. Actually
> I
> > think nowadays we should support the automatic detection of resources
> (how
> > ever we call them). This means more work and even more tests for us but
> our
> > users will love it. I like the way of the FasterXML/jackson [1]: Add it
> to
> > the classpath and we will use it.
> >
> >
> > [1] https://github.com/FasterXML/jackson
> >
> > Am 29.11.14 00:51, schrieb John D. Ament:
> >
> >> Instead of having a PropertyAdapter, can we just ask them to implement
> >> java.util.function.Function<?,String> or point to a lambda expression
> >> that
> >> supports it?
> >>
> >> I would prefer that over 2 & 3 since in most cases a string ctor/factory
> >> won't work without lots of lookup logic.
> >>
> >
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fischer@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fischer@jabber.org
> > X http://xing.to/obf
> >
> >
>
Re: Thoughts on type conversion support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Shouldnt propertyadapters be an interface? Default would use a standzrd SPI
but you can change it (closed set, osgi etc...).
Le 29 nov. 2014 01:24, "Oliver B. Fischer" <o....@swe-blog.net> a
écrit :
> @John I think it is quite convenient to reuse these mechanisms. Actually I
> think nowadays we should support the automatic detection of resources (how
> ever we call them). This means more work and even more tests for us but our
> users will love it. I like the way of the FasterXML/jackson [1]: Add it to
> the classpath and we will use it.
>
>
> [1] https://github.com/FasterXML/jackson
>
> Am 29.11.14 00:51, schrieb John D. Ament:
>
>> Instead of having a PropertyAdapter, can we just ask them to implement
>> java.util.function.Function<?,String> or point to a lambda expression
>> that
>> supports it?
>>
>> I would prefer that over 2 & 3 since in most cases a string ctor/factory
>> won't work without lots of lookup logic.
>>
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Thoughts on type conversion support
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
@John I think it is quite convenient to reuse these mechanisms. Actually
I think nowadays we should support the automatic detection of resources
(how ever we call them). This means more work and even more tests for us
but our users will love it. I like the way of the FasterXML/jackson [1]:
Add it to the classpath and we will use it.
[1] https://github.com/FasterXML/jackson
Am 29.11.14 00:51, schrieb John D. Ament:
> Instead of having a PropertyAdapter, can we just ask them to implement
> java.util.function.Function<?,String> or point to a lambda expression that
> supports it?
>
> I would prefer that over 2 & 3 since in most cases a string ctor/factory
> won't work without lots of lookup logic.
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Thoughts on type conversion support
Posted by Anatole Tresch <at...@gmail.com>.
Hi John
I am not sure if I get your point:
1. PropertyAdapter actually is a functional interface, so you can do things
like *PropertyAdapters.register(MyClass.class, (s) -> (MyClass.create(s););*
2. The problem is that the names of the interfaces in java.util.Function
often do not match really or even conflict (e.g. when you implement
multiple Suppliers). So in some cases you still define your own functional
interfaces as this is the case here.
WDYT?
2014-11-29 0:51 GMT+01:00 John D. Ament <jo...@apache.org>:
> Instead of having a PropertyAdapter, can we just ask them to implement
> java.util.function.Function<?,String> or point to a lambda expression that
> supports it?
>
> I would prefer that over 2 & 3 since in most cases a string ctor/factory
> won't work without lots of lookup logic.
>
> On Fri, Nov 28, 2014 at 6:38 PM, Oliver B. Fischer <
> o.b.fischer@swe-blog.net
> > wrote:
>
> > Hi,
> >
> > before touching the design document I would like to share some thoughts
> on
> > our type conversion support.
> >
> > I summary I would like add the following rules to the design document:
> >
> > 1. If the target data type is java.lang.String no conversion is needed.
> > 2. If the target data type is not java.lang.String and if the target data
> > type provides a static T valueOf(String) method than this method will be
> > used as factory method for the target value.
> > 3. If the target data type is not java.lang.String and if the target data
> > type provides a ctor with a single String parameter this ctor will be
> used
> > to create a instance of the target data type.
> > 4. In case there is a registered PropertyAdapter implementation for the
> > required target datatype this implementation will have precedence.
> >
> > wdyt?
> >
> > Oliver
> >
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fischer@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fischer@jabber.org
> > X http://xing.to/obf
> >
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Thoughts on type conversion support
Posted by "John D. Ament" <jo...@apache.org>.
Instead of having a PropertyAdapter, can we just ask them to implement
java.util.function.Function<?,String> or point to a lambda expression that
supports it?
I would prefer that over 2 & 3 since in most cases a string ctor/factory
won't work without lots of lookup logic.
On Fri, Nov 28, 2014 at 6:38 PM, Oliver B. Fischer <o.b.fischer@swe-blog.net
> wrote:
> Hi,
>
> before touching the design document I would like to share some thoughts on
> our type conversion support.
>
> I summary I would like add the following rules to the design document:
>
> 1. If the target data type is java.lang.String no conversion is needed.
> 2. If the target data type is not java.lang.String and if the target data
> type provides a static T valueOf(String) method than this method will be
> used as factory method for the target value.
> 3. If the target data type is not java.lang.String and if the target data
> type provides a ctor with a single String parameter this ctor will be used
> to create a instance of the target data type.
> 4. In case there is a registered PropertyAdapter implementation for the
> required target datatype this implementation will have precedence.
>
> wdyt?
>
> Oliver
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Thoughts on type conversion support
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
ok!
Am 29.11.14 00:55, schrieb Andres Almiray:
> Would it make sense to broaden the literal type to java.lang.CharSequence?
> I mention this because Groovy provides a dynamic string called GStringImpl
> that extends from such type.
>
> Cheers,
> Andres
>
> -------------------------------------------
> Java Champion; Groovy Enthusiast
> http://jroller.com/aalmiray
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
> On Sat, Nov 29, 2014 at 12:38 AM, Oliver B. Fischer <
> o.b.fischer@swe-blog.net> wrote:
>
>> Hi,
>>
>> before touching the design document I would like to share some thoughts on
>> our type conversion support.
>>
>> I summary I would like add the following rules to the design document:
>>
>> 1. If the target data type is java.lang.String no conversion is needed.
>> 2. If the target data type is not java.lang.String and if the target data
>> type provides a static T valueOf(String) method than this method will be
>> used as factory method for the target value.
>> 3. If the target data type is not java.lang.String and if the target data
>> type provides a ctor with a single String parameter this ctor will be used
>> to create a instance of the target data type.
>> 4. In case there is a registered PropertyAdapter implementation for the
>> required target datatype this implementation will have precedence.
>>
>> wdyt?
>>
>> Oliver
>>
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> X http://xing.to/obf
>>
>>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Thoughts on type conversion support
Posted by Otávio Gonçalves de Santana <ot...@gmail.com>.
CharSequence +1
On Fri, Nov 28, 2014 at 9:55 PM, Andres Almiray <aa...@gmail.com> wrote:
> Would it make sense to broaden the literal type to java.lang.CharSequence?
> I mention this because Groovy provides a dynamic string called GStringImpl
> that extends from such type.
>
> Cheers,
> Andres
>
> -------------------------------------------
> Java Champion; Groovy Enthusiast
> http://jroller.com/aalmiray
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
> On Sat, Nov 29, 2014 at 12:38 AM, Oliver B. Fischer <
> o.b.fischer@swe-blog.net> wrote:
>
> > Hi,
> >
> > before touching the design document I would like to share some thoughts
> on
> > our type conversion support.
> >
> > I summary I would like add the following rules to the design document:
> >
> > 1. If the target data type is java.lang.String no conversion is needed.
> > 2. If the target data type is not java.lang.String and if the target data
> > type provides a static T valueOf(String) method than this method will be
> > used as factory method for the target value.
> > 3. If the target data type is not java.lang.String and if the target data
> > type provides a ctor with a single String parameter this ctor will be
> used
> > to create a instance of the target data type.
> > 4. In case there is a registered PropertyAdapter implementation for the
> > required target datatype this implementation will have precedence.
> >
> > wdyt?
> >
> > Oliver
> >
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fischer@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fischer@jabber.org
> > X http://xing.to/obf
> >
> >
>
--
Otávio Gonçalves de Santana
blog: http://otaviosantana.blogspot.com.br/
twitter: http://twitter.com/otaviojava
site: *http://about.me/otaviojava <http://about.me/otaviojava>*
55 (11) 98255-3513
Re: Thoughts on type conversion support
Posted by Andres Almiray <aa...@gmail.com>.
Would it make sense to broaden the literal type to java.lang.CharSequence?
I mention this because Groovy provides a dynamic string called GStringImpl
that extends from such type.
Cheers,
Andres
-------------------------------------------
Java Champion; Groovy Enthusiast
http://jroller.com/aalmiray
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Sat, Nov 29, 2014 at 12:38 AM, Oliver B. Fischer <
o.b.fischer@swe-blog.net> wrote:
> Hi,
>
> before touching the design document I would like to share some thoughts on
> our type conversion support.
>
> I summary I would like add the following rules to the design document:
>
> 1. If the target data type is java.lang.String no conversion is needed.
> 2. If the target data type is not java.lang.String and if the target data
> type provides a static T valueOf(String) method than this method will be
> used as factory method for the target value.
> 3. If the target data type is not java.lang.String and if the target data
> type provides a ctor with a single String parameter this ctor will be used
> to create a instance of the target data type.
> 4. In case there is a registered PropertyAdapter implementation for the
> required target datatype this implementation will have precedence.
>
> wdyt?
>
> Oliver
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Thoughts on type conversion support
Posted by Anatole Tresch <at...@gmail.com>.
Perfect. I already discussed that with @dblevins . This makes complete
sense - add it!
2014-11-29 0:38 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> Hi,
>
> before touching the design document I would like to share some thoughts on
> our type conversion support.
>
> I summary I would like add the following rules to the design document:
>
> 1. If the target data type is java.lang.String no conversion is needed.
> 2. If the target data type is not java.lang.String and if the target data
> type provides a static T valueOf(String) method than this method will be
> used as factory method for the target value.
> 3. If the target data type is not java.lang.String and if the target data
> type provides a ctor with a single String parameter this ctor will be used
> to create a instance of the target data type.
> 4. In case there is a registered PropertyAdapter implementation for the
> required target datatype this implementation will have precedence.
>
> wdyt?
>
> Oliver
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*