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

[huizhe wang]

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