db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scott hutinger <s-hutin...@wiu.edu>
Subject Re: JVM bug workarounds - Was: release status as of 9/12/2004
Date Thu, 14 Oct 2004 18:38:56 GMT
Just for information:  OOo (OpenOffice) and the OS X version using 
alternate UI's has had problems with java specific problems.

Alternate vendors on more non-mainstream architectures probably won't be 
very likely with the currently template based interpreter ( assembly 
language templates ) which requires a bit more people hours to bring up 
a vm without hotspot.  Although keep that as 'unlikely', not 
impossible.  This keeps a vendor list smaller...

I also don't really see show stopping VM bugs very common at all.  
Probably what I am trying to say is, possibly one vendor might have more 
problems than the norm; due to unknown reasons, due to closed source 
from that specific vendor.

scott




Jan Hlavaty wrote:

>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
>  
>


Mime
View raw message