Hi,
2014-08-15 15:28 GMT+02:00 Jan Willem Janssen <janwillem.jans...@luminis.eu> : > > On 15/08/14 14:58, Bob Paulin wrote: > > I noticed in https://issues.apache.org/jira/browse/FELIX-3511 Java > > Concurrency is being introduced to the code base. A couple of > > thoughts on this. > > > > 1) With this not being backwards compatible with earlier versions > > does it make sense to increment at least the minor version (ie 1.3 > > -> 1.4). Java 8 introduces a slew of incompatibility with prior > > releases with the changes to the collection libraries so I'm > > curious how other projects are handling this. > > As I understand the issue, it talks about going from Java 5 to Java 6 > as required version, but yes, strictly speaking this would mean a > minor bump at least. We should be more strict on this, I agree (made > the same mistake in the Felix HTTP project as well). > Actually, as far as I remember the idea was that the version number reflects the specification version it implements - but this might not really make sense, so bumping the minor version is a good thing. > > > 2) Event admin has no tests. I would be interested in working on > > creating some tests for this project. Any thoughts on where to > > begin with this effort? > > I think the current implementation is written (and maintained) by > people that have access to the OSGi TCK, so they can tests the > implementation against the specification, which might explain the lack > of unit and integration tests. > Yepp, the implementation passes the OSGi TCK which I believe tests a lot of aspects already. > But to get started: just start writing unit tests against the code in > trunk and provide them as patches. It is always good to have tests > written by somebody else, as they most often have new/fresh insights > in the use cases... > Absolutely, we also have some additional tests in the whiteboard area for event admin. It's basically a stress test. > > > 3) It appears there maybe other areas of the event admin code that > > might benefit from the Concurrency objects. Perhaps the use of one > > of the Queue constructs for holding some of the asynchronous > > events. Thoughts on this? > > As long as it has positive effect on the performance, I think nobody > will complaint about this, if you're willing to provide patches ;) > > Right :) This has all been written initially on Java 1.4 so there might be areas which can be improved. However, a nicer implementation is one thing, the other one is performance. The goal should be to have a minimum on synchronization between threads to get the best performance. I'm not saying the current implementation is perfect though :) Carsten > - -- > Met vriendelijke groeten | Kind regards > > Jan Willem Janssen | Software Architect > +31 631 765 814 > > /My world is revolving around INAETICS and Amdatu/ > > Luminis Technologies B.V. > Churchillplein 1 > 7314 BZ Apeldoorn > +31 88 586 46 00 > > http://www.luminis-technologies.com > http://www.luminis.eu > > KvK (CoC) 09 16 28 93 > BTW (VAT) NL8169.78.566.B.01 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBAgAGBQJT7gruAAoJEKF/mP2eHDc4vO8QANxPmNAzlgzUbhxD0VfLN2++ > SlFrTqAGxaIS3rI3fzacBn5Z/v12azwyKLE39WfUEak+i5539LrcQYu8b2mOg4ML > rtz2Yz6r/IcSDixO5y17HrdHyGle58u/gPzJecQqz5j3iqHi4P8eKtNx8FWrG91c > 3X56VsP0sb718YswDnu8WXwy8V8I6p1h5vJdYJRx2DcOml+TEcxHxGTH6h7pDePt > DcsPF7E3XaHGWpPvJ5GX8JYjzl80TM5xV4d47VAGdeVCY+JewsC6OlDtxhargGFG > O0wEM9RqI2/R9OTB1K6STIwQZvglyjvUp1odgGEvgl8B/kbSh7WHprtUWIrG+D8Z > cIEBjS9mYIkPEQQo0NMZIqt1XfEMiK5qElqa7v0z8IDGbhaPHy+vGpK84uhItz6M > ++tEZ66OGfNaVJG9ueY+093M/J70V57ylw3Mz1Vhf7yChNa1iuT+sCU0OLOPom4K > 4UL3H59m9SCXGzg5EoVEglpggdWZCaQ//73mWp7CLob6Kwk8xCvRtC5yVzbxIAgh > UUVcltvSvIDklu9l9k4Di15Q4VyDz9HSu2ZilJJcWln4ZnaanGqxdoRu4tORw7fg > jchVs8Bcw1TmSGTjAwzZkKlFoZfGPPkLpa9/SXYDPfsgeU43hqJyazQ7a7ll0SpP > 62oji7tQ0LgRHEnbuZcs > =PraV > -----END PGP SIGNATURE----- > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
