xbean-reflect changes and potential xbean 5?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

xbean-reflect changes and potential xbean 5?

David Blevins-2
All,

I updated the converter code in xbean-reflect to add support for JAX-RS style string constructors and static factory methods.  We weren't so clever to think of this in 2006, but it definitely fits.

Moreover, I don't think we need half of the built-in Converter/PropertyEditor implementations now.  Most of them can be deleted with likely a positive speed impact as part of the process of converting is looping over all the built-in Converter/PropertyEditor instances.  There's a second startup improvement as well as they are created eagerly via static initializer.

I'd love to do a 4.x release of this code.  It could be nice to save the deleting of the property editors for a potential XBean 5.x.  I'm ok with one or the other or both.  I see Łukasz's work which might make for a good 5.x release, so maybe we just do that.

Thoughts or preferences?


-David

Reply | Threaded
Open this post in threaded view
|

Re: xbean-reflect changes and potential xbean 5?

Romain Manni-Bucau
If we go 5 we should probably drop the static PropertiesEditors class which leads to trivial leakages in all servers and do a registry apps instantiate at need with closeable support for editors. I can push that today if there is no objection.

It would also ensure we can cache the reflection needed for the jaxrs style you added a enable the blueprint version upgrade directlt.

+1 from me to go that path at once

Le jeu. 9 août 2018 03:54, David Blevins <[hidden email]> a écrit :
All,

I updated the converter code in xbean-reflect to add support for JAX-RS style string constructors and static factory methods.  We weren't so clever to think of this in 2006, but it definitely fits.

Moreover, I don't think we need half of the built-in Converter/PropertyEditor implementations now.  Most of them can be deleted with likely a positive speed impact as part of the process of converting is looping over all the built-in Converter/PropertyEditor instances.  There's a second startup improvement as well as they are created eagerly via static initializer.

I'd love to do a 4.x release of this code.  It could be nice to save the deleting of the property editors for a potential XBean 5.x.  I'm ok with one or the other or both.  I see Łukasz's work which might make for a good 5.x release, so maybe we just do that.

Thoughts or preferences?


-David

Reply | Threaded
Open this post in threaded view
|

Re: xbean-reflect changes and potential xbean 5?

Romain Manni-Bucau
pushed

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 9 août 2018 à 07:42, Romain Manni-Bucau <[hidden email]> a écrit :
If we go 5 we should probably drop the static PropertiesEditors class which leads to trivial leakages in all servers and do a registry apps instantiate at need with closeable support for editors. I can push that today if there is no objection.

It would also ensure we can cache the reflection needed for the jaxrs style you added a enable the blueprint version upgrade directlt.

+1 from me to go that path at once

Le jeu. 9 août 2018 03:54, David Blevins <[hidden email]> a écrit :
All,

I updated the converter code in xbean-reflect to add support for JAX-RS style string constructors and static factory methods.  We weren't so clever to think of this in 2006, but it definitely fits.

Moreover, I don't think we need half of the built-in Converter/PropertyEditor implementations now.  Most of them can be deleted with likely a positive speed impact as part of the process of converting is looping over all the built-in Converter/PropertyEditor instances.  There's a second startup improvement as well as they are created eagerly via static initializer.

I'd love to do a 4.x release of this code.  It could be nice to save the deleting of the property editors for a potential XBean 5.x.  I'm ok with one or the other or both.  I see Łukasz's work which might make for a good 5.x release, so maybe we just do that.

Thoughts or preferences?


-David

Reply | Threaded
Open this post in threaded view
|

Re: xbean-reflect changes and potential xbean 5?

jlmonteiro
That sounds like good improvements. Thanks for the visibility. 

And also 5.x sounds better considering the changes and the removal of some converters. 

Le jeu. 9 août 2018 à 09:37, Romain Manni-Bucau <[hidden email]> a écrit :
pushed


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 9 août 2018 à 07:42, Romain Manni-Bucau <[hidden email]> a écrit :
If we go 5 we should probably drop the static PropertiesEditors class which leads to trivial leakages in all servers and do a registry apps instantiate at need with closeable support for editors. I can push that today if there is no objection.

It would also ensure we can cache the reflection needed for the jaxrs style you added a enable the blueprint version upgrade directlt.

+1 from me to go that path at once

Le jeu. 9 août 2018 03:54, David Blevins <[hidden email]> a écrit :
All,

I updated the converter code in xbean-reflect to add support for JAX-RS style string constructors and static factory methods.  We weren't so clever to think of this in 2006, but it definitely fits.

Moreover, I don't think we need half of the built-in Converter/PropertyEditor implementations now.  Most of them can be deleted with likely a positive speed impact as part of the process of converting is looping over all the built-in Converter/PropertyEditor instances.  There's a second startup improvement as well as they are created eagerly via static initializer.

I'd love to do a 4.x release of this code.  It could be nice to save the deleting of the property editors for a potential XBean 5.x.  I'm ok with one or the other or both.  I see Łukasz's work which might make for a good 5.x release, so maybe we just do that.

Thoughts or preferences?


-David