Samuel Andrew McIntyre wrote: > After thinking about this some more, I think the try/catch route may be > the best way to go after all. I think it is in our best interest, as > stated elsewhere, to remain as vendor-neutral as possible. I don't think > that we want to get into the business of endorsing any particular > vendor's JVMs.
I agree endorsing JVMs is a bad thing, but disagree on that try/catch idea. See below. > So, I don't think enabling or disabling a feature based > on a list of vendors to include/exclude is really the best way to fix > the problem, and doing so would set a bad precedent. slippery slope, and > all that. Include and exclude are very different concepts. Include list is a bad idea, and has the endorsing effect, in addition to the burden of having to add new JVM versions to the list. But exclude list is much better and does not have that effect. > While the try/catch route may not seem like the cleaning solution to the > problem, at least it could fix the issue where it is known to cause a > problem without introducing unnecessary prejudice. So, if in the future > the particular problem is fixed, the feature would be automatically > enabled again, and we're still covered on any system where the JVM/OS > combination still has the problem. I don't think you can catch all JVM bugs like that. And code becomes cluttered with extraneous tests for the bugs presence, in addition to the necessary workarounds. You can do much better with exclusion list, which has exact buggy JVM version. With buggy JVM version i mean exact build version of the JVM, as identified by combination of system properties "java.vm.vendor", "java.vm.name" and "java.vm.version". Unknown JVMs should be expected to not have a particular bug. Maybe we could add os.name/os.arch/os.verion, but it is not guaranteed to reflect fixes to OS bugs - so we cannot reliably detect if the OS has a particular bug when the JVM bug is in fact caused by OS bug. That would need an override mechanism, where user could specify that he does not want to have particular workaround enabled. I imagine a special class (VMVersion?) that would have a static boolean variable or accessor method for each known bug/workaround. In class initializer, it would read a resource with database of known bugs and their respective JVMs, and set corresponding variable to true when a bug is believed to be present on the currently running JVM. There would also be a user configuration file that would allow user override the status of any particular workaround. When a specific workaround for a bug would be implemented, you would add an entry for workaround in the VMVersion class, and add known buggy VM versions to the buggy vm database resource. Tehn in code you would check the value of the workarounds variable and select the normal/workaround code based on that. To eliminate any negative effects of workarounds on the performance, a mechanism for selecting different implementation class could be realized, similar to the way Derby handles different JDK versions. In fact, these mechanisms could be one mechanism as different JDK versions can be handled by the very same mechanism as JVM bugs - they both pick implementations based on what JVM they run on - only the properties differ (java.specification.version instead of java.vm.*). Jan
signature.asc
Description: OpenPGP digital signature
