RFR(XS): 8133830: [solaris] Fix for potential memory leak in TimeZone_md.c, function findJavaTZ_md()

Hi all, as per the discussion in thread Fix for small leak in TimeZone_md.c in jdk9-dev, I would like to get the following tiny change reviewed: Bug: https://bugs.openjdk.java.net/browse/JDK-8133830 Webrev: http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ I also need a sponsor since I

Potential performance improvement for java.util.AbstractList?

Hi all, a Java application developer of our company has indicated that it might yield some performance benefit to modify the coding of java.util.AbstractList.equals() that it would first compare the size of the lists before iterating the elements. It would for sure be better in cases where

RE: RFR 8158023: SocketExceptions contain too little information sometimes

://mail.openjdk.java.net/pipermail/net-dev/2016-June/009880.html There is an updated webrev but it obviously still contains this mistake. Thanks Christoph > -Original Message- > From: Kenji Kazumura [mailto:k...@jp.fujitsu.com] > Sent: Mittwoch, 8. Juni 2016 02:51 > To: Lange

RFR 8158023: SocketExceptions contain too little information sometimes

Hi all, please review the following change: Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 During error analysis I stumbled over a place where I encountered a SocketException which was thrown along with some strerror

RFR 8150470: JCK: api/xsl/conf/copy/copy19 test failure

Hi, the changeset for 8149915 (enabling validate-annotations feature for xsd schema with annotation causes NPE) introduced a regression. Here is the fix. Bugid: https://bugs.openjdk.java.net/browse/JDK-8150470 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8150470.1/ Please review

RE: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE

Sorry, this one is the right webrev: http://cr.openjdk.java.net/~clanger/webrevs/8150470.1/ From: Langer, Christoph Sent: Dienstag, 23. Februar 2016 21:13 To: 'Aleksej Efimov' <aleksej.efi...@oracle.com>; huizhe wang <huizhe.w...@oracle.com> Subject: RE: JDK 9 RFR of JDK-81499

RE: RFR 8150470: JCK: api/xsl/conf/copy/copy19 test failure

Thanks Aleksej From: Aleksej Efimov [mailto:aleksej.efi...@oracle.com] Sent: Mittwoch, 24. Februar 2016 13:36 To: Langer, Christoph <christoph.lan...@sap.com> Cc: Joe Wang <huizhe.w...@oracle.com>; core-libs-dev@openjdk.java.net Subject: Re: RFR 8150470: JCK: api/xsl/conf/copy/copy19

RFR: JDK-8150704 XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees

Hi, I've created a fix proposal for the issue I have reported in this bug: https://bugs.openjdk.java.net/browse/JDK-8150704 The webrev can be found here: http://cr.openjdk.java.net/~clanger/webrevs/8150704.1/ The Xalan parser would eventually run out of DTM IDs if xsl transformations involve

Regarding the removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java

Hi, as I was using the xslt EnvironmentCheck class in my private testcase and recognizing it didn't exist anymore in JDK 9, I stumbled over this thread from last July below. I understand that you want to clean up and remove unnecessary code but I found the class quite useful as it would some

JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE

Hi, can you please review the following change for JDK-8149915: http://cr.openjdk.java.net/~clanger/webrevs/8149915.0/ I'm not sure if it is the right thing to set the default for XML_SECURITY_PROPERTY_MANAGER to a new XMLSecurityPropertyManager() object instead of the String "all". But it

RE: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE

a String from other places in the code that could make use of such a default...? Is that true? Best Christoph -Original Message- From: huizhe wang [mailto:huizhe.w...@oracle.com] Sent: Dienstag, 16. Februar 2016 21:03 To: Langer, Christoph <christoph.lan...@sap.com> Cc: core-li

RE: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE

- From: huizhe wang [mailto:huizhe.w...@oracle.com] Sent: Mittwoch, 17. Februar 2016 00:22 To: Langer, Christoph <christoph.lan...@sap.com> Cc: core-libs-dev@openjdk.java.net Subject: Re: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation caus

RE: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE

Hi Joe, here is the next version: http://cr.openjdk.java.net/~clanger/webrevs/8149915.2/ Hopefully the final one :-) > Yes, it's good to have some cleanups. For the generic initialization, > it's preferable to have no redundant type arguments, for example, > instead of: > > protected Stack

RE: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE

To: Langer, Christoph <christoph.lan...@sap.com> Cc: core-libs-dev@openjdk.java.net Subject: Re: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE On 2/18/2016 5:15 AM, Langer, Christoph wrote: > Hi Joe, > > here is the next

RE: [PING] RFR: JDK-8150704 XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees

backporting to 8? Thanks for reviewing and best regards Christoph > -Original Message- > From: huizhe wang [mailto:huizhe.w...@oracle.com] > Sent: Mittwoch, 9. März 2016 20:05 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: core-libs-dev@openjdk.java.net >

RE: [PING] RFR: JDK-8150704 XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees

Hi Joe, OK, thanks. I'll prepare the JDK 8 backport then. Best regards Christoph > -Original Message- > From: huizhe wang [mailto:huizhe.w...@oracle.com] > Sent: Donnerstag, 10. März 2016 19:07 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: core-libs

RE: [PING] RFR: JDK-8150704 XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees

Hi Joe, answers inline. > Thanks for reporting and providing patch for the issue! Looks like a > nice solution that may potentially reduce memory requirement for some > large templates. Could you also verify that the patch also fixes > JDK-8150699 [1] that was created the same day as yours?

RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place

Hi, I've run into a peculiar issue with Xerces. The problem is happening when a DTD shall be skipped, the DTD is larger than the buffer of the current entity and a CRLF sequence occurs just one char before the buffer end. The reason is that method skipDTD of class XMLDTDScannerImpl

PING: RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place

Hi, Ping: Any comments on my changes? Thanks Christoph From: Langer, Christoph Sent: Donnerstag, 7. April 2016 22:45 To: core-libs-dev@openjdk.java.net Subject: RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF

RE: RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place

le.com] > Sent: Dienstag, 12. April 2016 19:54 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: core-libs-dev@openjdk.java.net > Subject: Re: RFR: JDK-8153781 Issue in XMLScanner: > EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping > large DOCTYPE se

[PING] RFR: JDK-8150704 XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees

Hi, Ping - any comments or reviews for this bugfix? Thanks Christoph From: Langer, Christoph Sent: Freitag, 26. Februar 2016 16:02 To: core-libs-dev@openjdk.java.net Subject: RFR: JDK-8150704 XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees

RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c

Hi all, can I please get a review for a change to NetworkInterface.c bugreport: https://bugs.openjdk.java.net/browse/JDK-8156521 webrev: http://cr.openjdk.java.net/~clanger/webrevs/8156521.0/ Apart from quite a few whitespace changes to clean up the coding, I went through and replaced all

RE: RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place

acle.com] > Sent: Dienstag, 12. April 2016 23:28 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: core-libs-dev@openjdk.java.net > Subject: Re: RFR: JDK-8153781 Issue in XMLScanner: > EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping > large DOCTYPE sectio

RE: RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place

age- > From: Langer, Christoph > Sent: Montag, 18. April 2016 23:04 > To: 'huizhe wang' <huizhe.w...@oracle.com> > Cc: core-libs-dev@openjdk.java.net > Subject: RE: RFR: JDK-8153781 Issue in XMLScanner: > EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping > l

RE: RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place

Hi Joe, > > I've updated the testcase to increase the probability of it really hitting > > the > issue. The old version was prone to miss the issue in case something changed > in > the parser. > > > > http://cr.openjdk.java.net/~clanger/webrevs/8153781.2/ > > Looks good overall. OK, thanks. >

RE: RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place

Thanks Joe :-) > -Original Message- > From: huizhe wang [mailto:huizhe.w...@oracle.com] > Sent: Dienstag, 19. April 2016 23:44 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: core-libs-dev@openjdk.java.net > Subject: Re: RFR: JDK-815

RE: [JAXP] RFR: 8153082: Update XSTL compiler to generate classes that invoke addReads

Hi Daniel, looks good to me. Maybe you'll want to take the chance to update the apache headers in the xalan files? Best regards Christoph > -Original Message- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf > Of Daniel Fuchs > Sent: Freitag, 22. Juli

RE: [JAXP] RFR: 8153082: Update XSTL compiler to generate classes that invoke addReads

iel.fu...@oracle.com] > Sent: Montag, 25. Juli 2016 16:43 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: Joe Wang <huizhe.w...@oracle.com>; core-libs-dev d...@openjdk.java.net> > Subject: Re: [JAXP] RFR: 8153082: Update XSTL compiler to generate classes > th

RE: RFR (JAXP) 8158084: Catalog API: JAXP XML Processor Support

Hi Joe, looking good to me at a glance and contains some nice cleanups/warning fixes. But of course I'm not a reviewer. I think in src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java src/java.xml/share/classes/jdk/xml/internal/SecuritySupport.java you

RE: [JAXP] RFR: 8153082: Update XSTL compiler to generate classes that invoke addReads

Fuchs [mailto:daniel.fu...@oracle.com] > Sent: Montag, 25. Juli 2016 19:22 > To: Langer, Christoph <christoph.lan...@sap.com>; Joe Wang > <huizhe.w...@oracle.com>; Alan Bateman <alan.bate...@oracle.com> > Cc: core-libs-dev <core-libs-dev@openjdk.java.net> >

RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace

Hi, please review my change for the XSLT namespace issue. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8162598.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8162598 The issue has already been discussed in this thread:

RE: RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace

Hi Daniel, thanks for reviewing. Here my comments: > Looks good in general, even though the idiom >if (existing instanceof Stack) > caught my eye. I didn't like it either but found no better way to get rid of the warnings. If you have a better idea here, let me know :) > Thanks for the new

RE: RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace

ristoph From: huizhe wang [mailto:huizhe.w...@oracle.com] Sent: Freitag, 29. Juli 2016 08:04 To: Langer, Christoph <christoph.lan...@sap.com>; Daniel Fuchs <daniel.fu...@oracle.com> Cc: core-libs-dev@openjdk.java.net Subject: Re: RFR (JAXP): 8162598 XSLTC transformer swallows empty na

RE: JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace

Hi Joe, thanks for looking at this. Here is my comments: > I'm not sure why empty namespace was explicitly excluded. But for the > 2nd part, the developer was clear with a note on the intention. You may > want to try removing the condition statement that excluded the empty > namespace, but keep

RE: JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace

Hi Daniel, you mean with my webrev built in or with the current jdk9 dev? Best Christoph > -Original Message- > From: Daniel Fuchs [mailto:daniel.fu...@oracle.com] > Sent: Dienstag, 26. Juli 2016 15:47 > To: Langer, Christoph <christoph.lan...@sap.com>; huizh

RE: RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace

e add a note to the test on what's expected, or some javadoc to the method checkNodeNS8162598. Best, Joe On 7/29/16, 7:55 AM, Langer, Christoph wrote: Hi Joe, here is the webrev after merging: http://cr.openjdk.java.net/~clanger/webrevs/8162598.2/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8

RE: RFR 8158023: SocketExceptions contain too little information sometimes

eturn value of getLastErrorString: "if (n > 0)". Best regards Christoph > > On 27/06/2016 08:42, Langer, Christoph wrote: > > Hi, > > > > eventually here is the - hopefully final - version of this fix: > > http://cr.openjdk.java.net/~clanger/webrevs/

RE: RFR 8158023: SocketExceptions contain too little information sometimes

nal Message- > From: Kenji Kazumura [mailto:k...@jp.fujitsu.com] > Sent: Mittwoch, 8. Juni 2016 02:51 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: net-...@openjdk.java.net; nio-...@openjdk.java.net; core-libs- > d...@openjdk.java.net > Subject: Re: RFR 8158023:

RE: RFR 8158023: SocketExceptions contain too little information sometimes

is in place: http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ Now I finally need a review… Best regards Christoph From: Paul Benedict [mailto:pbened...@apache.org] Sent: Montag, 27. Juni 2016 18:15 To: Langer, Christoph <christoph.lan...@sap.com> Cc: Kenji Kazumura <k...@jp.fu

JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace

Hi, I have a customer reporting the following phenomena which I believe is an issue. Consider the following xsl: -XSL- http://www.w3.org/1999/XSL/Transform; version="1.0">

RE: RFR 8158023: SocketExceptions contain too little information sometimes

up calls to invoke java methods. > > jni_util.c: line 216: > >You should not need to create an extra string; the string s is > non-null and ready to use. > > jni_util.h: > >line 117-119, The original comment was just as informative as the > replacement. >

Updated Webrev: [JAXP] RFR: 8173602: TESTBUG: javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring

Hi, I made a small update to the webrev (in place). I externalized class TransformerTestTemplate now to be able to use it in other tests besides TransformerTest.java. Best regards Christoph From: Langer, Christoph Sent: Montag, 30. Januar 2017 15:28 To: core-libs-dev@openjdk.java.net Subject

RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

till used some place for attribute namespaces. For JDK9 I can imagine the change of this webrev going in - however, as we already discussed, you would have to do a ccc for me. Thanks & Best regards Christoph From: Langer, Christoph Sent: Dienstag, 25. Oktober 2016 15:39 To: core-libs-dev@

RE: Ping: [JAXP] RFR: 8173602: TESTBUG: javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring

Thanks, Daniel. I pushed it: http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/e930c373aaa4 > -Original Message- > From: Daniel Fuchs [mailto:daniel.fu...@oracle.com] > Sent: Freitag, 3. Februar 2017 14:56 > To: Langer, Christoph <christoph.lan...@sap.com> &

RE: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

Hi Joe, welcome back. :) This sounds reasonable. I'll prepare a change for JDK10. Thanks Christoph From: Joe Wang [mailto:huizhe.w...@oracle.com] Sent: Mittwoch, 8. Februar 2017 01:39 To: Langer, Christoph <christoph.lan...@sap.com> Cc: core-libs-dev@openjdk.java.net; Aleksej

RE: Ping: [JAXP] RFR: 8173602: TESTBUG: javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring

le.com] > Sent: Freitag, 3. Februar 2017 13:54 > To: Langer, Christoph <christoph.lan...@sap.com>; core-libs- > d...@openjdk.java.net > Subject: Re: Ping: [JAXP] RFR: 8173602: TESTBUG: > javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring > > Hi Chr

Ping: [JAXP] RFR: 8173602: TESTBUG: javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring

Hi, Ping - anyone out there who could have a look at my JAXP test update? Thanks Christoph From: Langer, Christoph Sent: Montag, 30. Januar 2017 15:28 To: core-libs-dev@openjdk.java.net Subject: [JAXP] RFR: 8173602: TESTBUG: javax/xml/jaxp/unittest/transform/TransformerTest.java needs

RFR (JAXP) 8169827: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed

Hi, while working on jaxp changes and running jtreg tests I found that test javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh does not work. I then saw that this was already reported with bug 8169827. But, as I had already spent some time to fix this test I'd like to contribute my fix:

RE: (JAXP) RFR: 8173111: Excessive recursion in EventFilterSupport when filtering over large number of XML events can cause StackOverflow

Hi Daniel, your fix looks good, pretty straightforward, +1. A minor thing, src/java.xml/share/classes/com/sun/xml/internal/stream/EventFilterSupport.java: 67 while (super.hasNext()){ As you are touching this line, you could add a blank between ')' and '{'. Disclaimer: I'm no reviewer.

RE: RFR (JAXP) 8169827: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed

might appear again... Best regards Christoph > -Original Message- > From: Daniel Fuchs [mailto:daniel.fu...@oracle.com] > Sent: Montag, 23. Januar 2017 17:12 > To: Langer, Christoph <christoph.lan...@sap.com>; Frank Yuan > <frank.y...@oracle.com>; core-libs-dev

RE: RFR (JAXP) 8169827: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed

> -Original Message- > From: Frank Yuan [mailto:frank.y...@oracle.com] > Sent: Dienstag, 24. Januar 2017 08:59 > To: Langer, Christoph <christoph.lan...@sap.com>; 'Daniel Fuchs' > <daniel.fu...@oracle.com>; core-libs-dev@openjdk.java.net > Subject: RE: RFR (J

RE: RFR (JAXP) 8169827: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed

k Yuan [mailto:frank.y...@oracle.com] > Sent: Dienstag, 24. Januar 2017 09:45 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: 'Daniel Fuchs' <daniel.fu...@oracle.com>; core-libs-dev@openjdk.java.net > Subject: RE: RFR (JAXP) 8169827: > javax/xml/jaxp/isolatedjdk/cat

[JAXP] RFR: 8173602: TESTBUG: javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring

Hi, please review a test fix for javax/xml/jaxp/unittest/transform/TransformerTest.java: Bug: https://bugs.openjdk.java.net/browse/JDK-8173602 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8173602.0/ The main motivation for this refactoring is to remove the dependency to the JDK internal

RFR (XS): 8173634: libjli/cmdtoargs.c does not compile with VS2010

Hi, please review a tiny fix. The change for JDK-8170832 (Add a new launcher environment variable JAVA_OPTIONS) has introduced a build error when you build with Visual Studio 2010. Yes, we know it is not officially supported for JDK9 - however, it's easy and clean to keep compatibility. :)

RE: RFR (XS): 8173634: libjli/cmdtoargs.c does not compile with VS2010

Thanks, Roger, Chris. It's submitted: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/65a1441c9c80 Best Christoph > -Original Message- > From: Chris Hegarty [mailto:chris.hega...@oracle.com] > Sent: Montag, 30. Januar 2017 16:33 > To: Langer, Christoph <christoph.lan...@sap.

Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace unaware StAX Input

that you should decide about this one when you are back. The changes are merely cleanups apart from com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.startElement(), which to me seem natural after 8169631, though. Thanks, Christoph > -Original Message- > From: Langer, Chr

[10] RFR: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

this item completed soon as I want to get it out of my backlog. Thanks and best regards Christoph From: Langer, Christoph Sent: Montag, 13. Februar 2017 16:15 To: 'huizhe wang' <huizhe.w...@oracle.com> Cc: core-libs-dev@openjdk.java.net; Aleksej Efimov <aleksej.efi...@oracle.com> Sub

RE: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml declaration

Hi Joe, this looks right to me, quite straightforward. I just have some formatting nits for the test: 1. Line 107 (XMLInputFactory xif=): space missing before '=' 2. Method comments on test methods would look nicer if formatted like: /* * line 1 * line 2 * ... */ ... I want to say that the '*'

RE: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace unaware StAX Input

age- > From: Langer, Christoph > Sent: Samstag, 11. Februar 2017 15:50 > To: 'huizhe wang' <huizhe.w...@oracle.com> > Cc: core-libs-dev@openjdk.java.net > Subject: RE: Update: RFR 8172974 [JAXP] XALAN: Wrong result when > transforming namespace unaware StAX Inp

RE: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

/NamespacePrefixTest.java needs to go then as it would be obsolete and would fail. Other than that, I ran the jtreg tests and found no other issues. Thanks Christoph From: huizhe wang [mailto:huizhe.w...@oracle.com] Sent: Donnerstag, 9. Februar 2017 17:25 To: Langer, Christoph <christoph.lan...@sap.com> Cc: cor

RE: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

Hi > FWIW I think a null Supplier should simply be ignored. ...which is what Volker's change does. After reading through all the discussion, I'm pro adding the null check as proposed in Volker's webrev. Best regards Christoph > On 13/02/2017 6:04 PM, Volker Simonis wrote: > > Ping... > > > >

rmid on Unix fails with Exception - maybe aftermath of JDK-8173607 ??

Hi Daniel, when starting "rmid" from current builds on Linux (and probably other Unix platforms as well) we are currently getting the exception below. It looks as if on that path libnio was not loaded and hence we're getting an UnsatisfiedLinkError. In UnixNativeDispatcher.java one can find a

RE: rmid on Unix fails with Exception - maybe aftermath of JDK-8173607 ??

Fuchs [mailto:daniel.fu...@oracle.com] > Sent: Donnerstag, 16. Februar 2017 15:53 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: Zeller, Arno <arno.zel...@sap.com>; Baesken, Matthias > <matthias.baes...@sap.com>; core-libs-dev@openjdk.java.net > Subject

RE: rmid on Unix fails with Exception - maybe aftermath of JDK-8173607 ??

The colleagues tell me that it was about two weeks ago. But I guess it's rather a felt experience than a concrete date ;-) > -Original Message- > From: Daniel Fuchs [mailto:daniel.fu...@oracle.com] > Sent: Donnerstag, 16. Februar 2017 17:02 > To: Langer, Christoph &l

RE: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace unaware StAX Input

017 23:15 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: core-libs-dev@openjdk.java.net > Subject: Re: Update: RFR 8172974 [JAXP] XALAN: Wrong result when > transforming namespace unaware StAX Input > > Hi Christoph, > > The performance results showed two regressi

RE: rmid on Unix fails with Exception - maybe aftermath of JDK-8173607 ??

n <alan.bate...@oracle.com>; Daniel Fuchs > <daniel.fu...@oracle.com>; Langer, Christoph <christoph.lan...@sap.com> > Cc: core-libs-dev@openjdk.java.net; Zeller, Arno <arno.zel...@sap.com>; > Baesken, Matthias <matthias.baes...@sap.com> > Subject: Re: rmid

RE: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input

Hi Joe, I finally got back to this one and pushed the change with some minor whitespace diffs. Thanks Christoph > -Original Message- > From: Joe Wang [mailto:huizhe.w...@oracle.com] > Sent: Montag, 28. November 2016 20:06 > To: Langer, Christoph <christoph.lan...@sap.

RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace unaware StAX Input

Hi, please review a change for JAXP. Bug: https://bugs.openjdk.java.net/browse/JDK-8172974 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/ When enhancing the test for https://bugs.openjdk.java.net/browse/JDK-8023653, I saw that there's still an issue with StAXInputSource which

RFR: 8023653: xalan inconsistently parses DOMSource and StreamSource

.openjdk.java.net/browse/JDK-8172974 [2] http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/ > -Original Message- > From: Joe Wang [mailto:huizhe.w...@oracle.com] > Sent: Samstag, 19. November 2016 01:50 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: core

RE: RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace unaware StAX Input

q.html#faq-N10207 [2] https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource.html > -Original Message- > From: huizhe wang [mailto:huizhe.w...@oracle.com] > Sent: Mittwoch, 18. Januar 2017 22:12 > To: Langer, Christoph <christoph.lan...@sap.com>; core-l

RE: RFR JDK-8165617: Cleanup whitespace in jaxp/test

Hi Frank, just out of interest: Is it a rule not to have any LFs at the end of java files? Best regards Christoph > -Original Message- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf > Of Frank Yuan > Sent: Donnerstag, 8. September 2016 06:35 > To: 'Joe

RE: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message

Hi Aleks, looks nice to me. You could maybe use the method reference syntax in 2 places: --- a/test/javax/xml/jaxp/unittest/common/WarningsTestBase.java Wed Aug 31 09:17:55 2016 +0200 +++ b/test/javax/xml/jaxp/unittest/common/WarningsTestBase.java Wed Aug 31 10:32:05 2016 +0200 @@ -68,11

RE: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files

Hi Thomas, your change looks good. I'm also forwarding this to i18n-dev as issues in TimeZone implementation are mostly handled there. One remark: Can you take the opportunity to also remove the blank between the cast and malloc in line 150: "(struct dirent64 *) malloc..."? Unfortunately I'm

RFR: 8166189: Fix for Bug 8165524 breaks AIX build

Hi, the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually

RE: Proposal for adding O_DIRECT support into JDK 9

Hi Lucy, FWIW: I ran a build on AIX and this looks ok. I also assume in your final version you'll update all copyright years where it's not 2016 yet? Other than that the changes look ok to me - but I'm neither a reviewer nor a deep expert in the area of your changes. Best regards Christoph >

RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

Hi all, hearing no objections and having the final ok from Goetz, I pushed the fix: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c709e74ffcf6 Best regards Christoph > -Original Message- > From: Lindenmaier, Goetz > Sent: Montag, 19. September 2016 11:10 > To: Lange

RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

essage- > From: Volker Simonis [mailto:volker.simo...@gmail.com] > Sent: Freitag, 16. September 2016 19:34 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: Kumar Srinivasan <kumar.x.sriniva...@oracle.com>; Mandy Chung > <mandy.ch...@oracle.com>; Chris Ben

RE: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions

+1, nice fix. > -Original Message- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf > Of Joe Wang > Sent: Mittwoch, 17. August 2016 18:30 > To: Aleks Efimov > Cc: core-libs-dev > Subject: Re: RFR

RE: RFR: 8167002: JAXP schema validator: Use HashSet instead of ArrayList for tracking XML IDs

Hi Martin, this also looks like a good catch to me, +1. When you push, could you insert the copyright block from, e.g. src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11DocumentScannerImpl.java at the place where you currently find the " reserved comment block ", first 4

RE: XALAN: Text node of value 'null' - Is this illegal or does XSLTC have an issue here?

that it's possible via the DOM API to construct such null nodes. So I take you support this endeavor? Thanks Christoph From: huizhe wang [mailto:huizhe.w...@oracle.com] Sent: Dienstag, 8. November 2016 06:01 To: Langer, Christoph <christoph.lan...@sap.com>; Aleks Efimov <aleksej.efi...@o

XALAN: Text node of value 'null' - Is this illegal or does XSLTC have an issue here?

Hi Xalan experts, I've recently handled a customer issue about Text Nodes of value 'null' inside a DOM, causing an exception during XALAN XSLT transformation. The repro case is quite simple. Consider the following small Java sample [1] which creates a DOM from a very basic XML, inserts a text

RFR (JAXP): 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

Hi JAXP experts, please review a fix for a new issue regarding namespace handling in Xalan with xsl:element. Bug: https://bugs.openjdk.java.net/browse/JDK-8168664 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8168664.0/ I'm not 100% sure if this is the right way to go or if it would

RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input

Hi, please review this fix for bug 8169631. Bug: https://bugs.openjdk.java.net/browse/JDK-8169631 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169631.0/ When XALAN is handling namespace unaware input, it behaves differently while using SAX input compared to DOM input. With both input

RE: NPE on "return" bytecode of java.net.NetworkInterface

Hi David, can this be reproduced? What platform is it about? There have been fixes for some Windows native coding lately: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/ef9b2921bfa5 It really looks like some issues in the native code with a misleading callstack. Best regards Christoph

RE: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input

it. But if you insist, I could have another look. Best regards Christoph > -Original Message- > From: Joe Wang [mailto:huizhe.w...@oracle.com] > Sent: Dienstag, 15. November 2016 03:23 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: core-libs-dev@openjdk.j

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

Frank Yuan [mailto:frank.y...@oracle.com] > Sent: Mittwoch, 23. November 2016 06:26 > To: Langer, Christoph <christoph.lan...@sap.com>; 'Volker Simonis' > <volker.simo...@gmail.com>; 'Daniel Fuchs' <daniel.fu...@oracle.com> > Cc: code-tools-...@openjdk.java.net; core-l

RE: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars

...@oracle.com] Sent: Mittwoch, 23. November 2016 05:41 To: core-libs-dev@openjdk.java.net; 'Daniel Fuchs' <daniel.fu...@oracle.com>; Langer, Christoph <christoph.lan...@sap.com>; 'Volker Simonis' <volker.simo...@gmail.com>; 'Joe Wang' <huizhe.w...@oracle.com> Cc: code-tools-...

RE: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE

Hi Joe, tests went well and I pushed: http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/31ac7aab52da Thanks Christoph From: Joe Wang [mailto:huizhe.w...@oracle.com] Sent: Dienstag, 22. November 2016 23:02 To: Langer, Christoph <christoph.lan...@sap.com> Cc: core-libs-dev@openjdk.java.net S

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

To: Volker Simonis <volker.simo...@gmail.com>; Langer, Christoph > <christoph.lan...@sap.com>; Langer, Christoph <christoph.lan...@sap.com> > Cc: Chris Hegarty <chris.hega...@oracle.com>; code-tools- > d...@openjdk.java.net; core-libs-dev@openjdk.java.net; jtreg- >

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

sources were used, don't help. Am I missing something? Best regards Christoph > -Original Message- > From: Chris Hegarty [mailto:chris.hega...@oracle.com] > Sent: Dienstag, 22. November 2016 10:08 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: core-libs-dev@o

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

file missing? Thanks Christoph > -Original Message- > From: Daniel Fuchs [mailto:daniel.fu...@oracle.com] > Sent: Dienstag, 22. November 2016 12:25 > To: Langer, Christoph <christoph.lan...@sap.com>; Chris Hegarty > <chris.hega...@oracle.com> > Cc: code-to

Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

Hi, I'm currently struggling while running jtreg tests for the jaxp depot. There are several tests that fail with the same symptom. I always get exceptions like: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers") at

RE: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE

ber 2016 00:23 To: Langer, Christoph <christoph.lan...@sap.com> Cc: core-libs-dev@openjdk.java.net Subject: Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE On 11/18/16, 12:17 PM, Langer, Christoph wrote: Hi Joe, Yep, I'll conduct the te

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

internal version of jtreg be updated to use the latest testng :-) Best regards Christoph > -Original Message- > From: Volker Simonis [mailto:volker.simo...@gmail.com] > Sent: Dienstag, 22. November 2016 20:25 > To: Daniel Fuchs <daniel.fu...@oracle.com> >

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

016 15:47 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: code-tools-...@openjdk.java.net; core-libs-dev@openjdk.java.net; jtreg- > u...@openjdk.java.net; Volker Simonis <volker.simo...@gmail.com> > Subject: Re: Issues running JAXP jtreg tests ("java.lang.Runti

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

Christoph > -Original Message- > From: Daniel Fuchs [mailto:daniel.fu...@oracle.com] > Sent: Dienstag, 22. November 2016 15:31 > To: Langer, Christoph <christoph.lan...@sap.com>; Volker Simonis > <volker.simo...@gmail.com> > Cc: code-tools-...@openjdk.java.net; core-li

RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

Yes, please find it here: http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr > -Original Message- > From: Chris Hegarty [mailto:chris.hega...@oracle.com] > Sent: Dienstag, 22. November 2016 11:03 > To: Langer, Christoph <christoph.lan...@sap.com> &

RE: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input

. Thanks & best regards Christoph > -Original Message- > From: Joe Wang [mailto:huizhe.w...@oracle.com] > Sent: Dienstag, 22. November 2016 20:11 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: core-libs-dev@openjdk.java.net > Subject: Re

RE: RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME

Hi Joe, this looks good and contains nice cleanups (some of them I have as well in my changes for 8169631 :) ). Some formatting nits: src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java: line 975 map.put(className+".class", attr); spaces left and

RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE

Hi, please review another XALAN fix. The Serializer should be able to handle text nodes with null input. There has already been some discussion here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044567.html Bug: https://bugs.openjdk.java.net/browse/JDK-8169772 Webrev:

  1   2   3   4   5   >