In theory, that's possible. Tapestry doesn't reference ASM classes, it's only dependency is plastic. So in theory you could have a layer in plastic to choose ASM or javassist as the "provider" (or another byte code library).
I'd doubt that this is high priority for the tapestry team. I seem to recall Howard mentioning that javassist was buggy and updates were very slow to be implemented compared to ASM. Perhaps if plastic was broken into it's own separate project outside of the core tapestry source tree, the open source community could tweak it to be a "provider agnostic" byte code manipulation language in a similar vein to slf4j.
