W3C classes conflict witk JDK W3C bug.
Opened this issue · 4 comments
I recommend to change package to com.dragom.w3c because javassist is targeting jdk rt.jar classpath and its making delegator skip w3c dragome class methods and have invalid methods from rt.jar.
Its possible to fix but there are like 3 projects that use w3c and you will have to mess with ClassLoader classpath order to get it to work correctly. Its not worth to do this if renaming package fix this problem.
I think It's important to keep w3c standard compatibility including packages names, so less concepts, classes and standards are introduced and any java application dom usage will be compatible with this.
There is an alternative approach to fix it, we could split those classes that are in conflict in two parts, one keeping compatibility with jdk standard, and the other with additional method not present in jdk. We can call the second one something like XXExtension or XXExtra.
Support jdk w3c methods will give more work though. You will have to be careful because any methods that is not correctly emulated will generate future bugs.
I'm talking about just w3c interfaces located on org.w3c.* not implementations. These interfaces are replicated on dragome-w3c-standards using webidl files that reflects w3c defined standards, the only thing we need to do to fix the problem is touch webidl files to separate definitions into what is jdk reflecting from standard and what is not present yet.
Right, I'll wait for this fix and patch my test branch because I had renamed to catch other bugs.