RFR: JAXP 1.5 for JDK8/7u40: 8016648: FEATURE_SECURE_PROCESSING set to true or false causes SAXParseException to be thrown
huizhe.wang at oracle.com
Tue Jul 9 01:07:32 UTC 2013
I've updated webrev with improved property management, and quality
backed by 320 test cases. Thanks Daniel for the help expanding the test
Here's the webrev:
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:
>>> 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.
More information about the core-libs-dev