Hi all, Note that replacing arrays with collections should not be done without understanding the performance implications...
Gary On Jun 5, 2012, at 1:14, "Bruno P. Kinoshita" <brunodepau...@yahoo.com.br> wrote: > Hi Thomas, > >> Thanks, I'm trying to pull things straight to make it usable it current >> environments. I use the old version a lot. The code has more than 400 >> unit tests and a few disabled ones. Some tests tend to fail every now >> and then (timing dependent). Those problems are hard to spot. I could >> need some help... > > I don't have a project using [jcs], but I can help debugging, running tests > in Linux with different JVM's, and other minor issues :-) As I have used > ehcache in some JEE projects, I'm specially interested in learning if it is a > good idea to replace ehcache by [jcs], as it looks like it has better > performance [1] and more features. > >> I'm afraid this is not enough information to understand what you mean. >> Could you be a bit more specific, please? > > Sure. I was only suggesting that maybe you could try adding generics to [jcs] > and when in doubt, consult the [functor] SVN history and look for what was > done. But I had a look on [jcs] code, and its codebase is much bigger than > [functor]'s. And I've also noticed that some of the warnings are due generics > in arrays. In some cases it is simply not possible to generify the types used > in arrays (you can use collections, or suppress the warning), not sure if it > is the case in [jcs] though. > > I will read more the [jcs] codebase to see if I can spot some places to > generify the code and remove some warnings :-) There is something about > generics in arrays, and 'generifying' legacy code in [2]. > > All the best, > > [1] http://commons.apache.org/jcs/JCSvsEHCache.html > [2] http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf > > Bruno P. Kinoshita > http://www.kinoshita.eti.br > http://www.tupilabs.com > > On 06/02/2012 04:28 PM, Thomas Vandahl wrote: >> On 01.06.12 06:31, Bruno P. Kinoshita wrote: >>> Hi, >>> >>> [jcs] seems very interesting :-) and maybe I could use it in some >>> applications too (or at least knowing about it may help). >> >> Thanks, I'm trying to pull things straight to make it usable it current >> environments. I use the old version a lot. The code has more than 400 >> unit tests and a few disabled ones. Some tests tend to fail every now >> and then (timing dependent). Those problems are hard to spot. I could >> need some help... >> >>> I'm not an expert in generics, but some time ago similar task was done in >>> [functor], maybe we could use that as base. I will read the changes in >>> [functor] and will try to review the warnings in [jcs], and then comment or >>> propose patches. >> >> Well, my impression with generics is that you can overdo it easily. >> Maybe it's not necessary in the deeper layers of the library and it only >> causes trouble. That's why I'm asking for reviews. >> >>> >>> In case you would like to take a look on what was done in [functor], check >>> r1188373 until r1188409 more or less. There may be more to be done in >>> [functor] as it hasn't been released yet, but the new version with generics >>> is working perfectly, no broken tests, no changes in the functionality, and >>> I think there are no warnings. >> >> I'm afraid this is not enough information to understand what you mean. >> Could you be a bit more specific, please? >> >> Bye, Thomas. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
