sounds like a good idea to me. --Orion
On May 20, 2008, at 5:55 AM, Geert Bevin wrote: > Hi everyone, > > I'm a bit concerned about how we're approaching the byte-code > instrumentation of JDK classes or framework classes. > > There are basically two ways: > * we either replace existing methods/classes by new implementations; > or > * we modify existing methods/classes by looking for patterns in the > byte code > > Both of these approaches are very much tied to the actual version of > the instrumented class. When incompatible versions of those classes > appear in later versions of the JDK or the frameworks, we basically > have to rely on tests to fail (which doesn't really happen, since we > don't test with all possible framework versions) or on users to report > that something doesn't work as expected. > > I'm wondering if we should be more strict about which classes we > actually support for each instrumentation. > > An initial idea I have is to make checksums of the byte code arrays > for each class that is supported and to map those to the adaptors. > This would also allow us to have clearly isolated adaptors for classes > that have the same name, but have different implementations. When new > versions of the JDK or frameworks appear and the implementation of an > instrumented class has changed, we can fail-fast since the checksum > will not be part of the ones we support. I personally think that this > is much better than just hoping that it will work and wait until > something bad happens at runtime. One downside is that creating the > checksums for each class with custom instrumentation could be quite > expensive at runtime. > > Any thoughts? > > Geert > > -- > Geert Bevin > Terracotta - http://www.terracotta.org > Uwyn "Use what you need" - http://uwyn.com > RIFE Java application framework - http://rifers.org > Music and words - http://gbevin.com > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
