RFR: JAXP 1.5 for JDK8/7u40: 8016648: FEATURE_SECURE_PROCESSING set to true or false causes SAXParseException to be thrown

[huizhe wang]

Hi,

I've updated webrev with improved property management, and quality 
backed by 320 test cases. Thanks Daniel for the help expanding the test 
suite!

Here's the webrev:
http://cr.openjdk.java.net/~joehw/jdk8/8016648/webrev/

-Joe

On 7/5/2013 6:48 PM, huizhe wang wrote:
>
> On 7/5/2013 1:32 AM, Alan Bateman wrote:
>> On 04/07/2013 21:25, huizhe wang wrote:
>>>
>>> Reverted back to the original code: 
>>> http://cr.openjdk.java.net/~joehw/jdk8/8016648/webrev/
>>> The code split the version number and look at the 1st or 2nd 
>>> element, it thus works for both the current format and the proposed 
>>> one, e.g. for 1.7.0, it compares with the 2nd element, and for the 
>>> proposed MAJOR.MINOR.FU.*, the 1st or MAJOR.
>> Thanks for dropping the dependency on javax.lang.model. What you now 
>> is probably okay although I'm a bit dubious about attempting to 
>> support an alternative format (I'm not aware of any proposal that 
>> changes the format of the java.version property as changing it would 
>> like cause a lot of breakage).
>
> There was a survey from Iris last year, and the JPG site has a 
> presentation from Aurelio. But you're right, I'll remove it. If 
> there's any change in the future, that is if it happens at all, we can 
> always add that back.
>>
>> A minor point but isJDKOrAbove looks a bit odd to me, I'd probably go 
>> for something like isJavaVersionGTE or isJavaVersionAtLeast but as 
>> it's not part of the API then it doesn't matter of course.
>
> isJavaVersionAtLeast is easy to understand. What does GTE stand for?
>
>>
>> I think I mentioned it a while back but have warnings emitted with 
>> System.err can be problematic (gets mixed up with application 
>> messages to stderr). I realize the Xerces code seems to do this in 
>> places but we really need to see about eliminating these messages or 
>> getting consistent logging into this code.
>
> I agree, this one is not particularly graceful. There were 88 matches 
> of System.err in Xalan and 75 in Xerces, although some I believe are 
> used for debugging. It could take quite some effort.
>
> I mentioned that with a standalone release, we were trying to stay 
> away from new JDK features. It's probably better to spend time/effort 
> on some upgrades.
>
>>
>>> :
>>>
>>> The last scenario to work on is if FSP is set on the Validator 
>>> instead of SchemaFactory. With that, I'm looking at refactoring the 
>>> way properties are represented so that they carry state. It would 
>>> then be cleaner to pass them from SchemaFactory over to Schema and 
>>> then Validator. It's a bit of work. Fortunately, we only have three 
>>> of them to deal with.
>> So are you planning to send another webrev or do it as a separate issue?
>
> Looking at affected code by this change, it doesn't seem to be too 
> bad. I'll send another webrev.
>
> Joe
>
>>
>> -Alan
>