Hi Vlad,
This bug was fixed in 7u80. Please, see JDK-8059327 [1] for more
information. Also I have successfully executed the test from JDK-8140747
on 7u80 and on 7u75 with [1] applied: It gave me a lot of 'rugs' =).
Best Regards,
Aleksej
[1] https://bugs.openjdk.java.net/browse/JDK-8059327
Hi,
The push for JDK-8134111 missed one test file. Please, review and
approve the addition of missing ObjectFactory.java file.
Webrev with added file: http://cr.openjdk.java.net/~aefimov/8153262/00
Thanks,
Aleksej
Hi,
Please, help to review the fix for JDK-8134111 [1]. This bug was already
resolved in standalone JAXB project and was integrated to JDK9 as part
of JAXWS/B sync process [2].
The changes that fixed the incorrect unmarshalling behavior are located
in StructureLoader class [3].
JDK9 change
Thank you for review Lance!
Small question for clarification: Can I count your review for JDK8
changes too?
Best Regards,
Aleksej
On 03/25/2016 08:46 PM, Lance Andersen wrote:
Looks OK Alejsej
On Mar 24, 2016, at 7:38 PM, Aleksej Efimov <aleksej.efi...@oracle.com
<mailto:aleks
to see a review of the 8 change before approval.
-Rob
On 25/03/16 03:06, Aleksej Efimov wrote:
Hi,
Please, approve the backport of JDK-8150704 to JDK8. JAXP classes source fix
applies cleanly after reshuffling.
The only discrepancy is the test changes:
In JDK9 the issue was tested by extending
Hi,
Please, help to review the fix for JDK-8073872 [1]. In JDK9 this bug was
fixed as part of sync with upstream JAXWS project [2]. The changes that
fixed stack overflow issue are located in XmlSchemaGenerator class [3].
JDK9 change that needs review is the addition of regression test for
to jdk8u-dev pending successful code review
I understand that the code review may seem over-cautious, but as you are only
back porting a subset of the original change set, a (hopefully trivial) review
is still needed.
Cheers,
-Buck
On Mar 23, 2016, at 09:12, Aleksej Efimov <aleksej.efi...@oracle.
ported
ClassCastException
You are validating that the Exception is not thrown so your probably
want to adjust this comment before pushing
Best
Lance
On Mar 18, 2016, at 6:50 PM, Aleksej Efimov <aleksej.efi...@oracle.com
<mailto:aleksej.efi...@oracle.com>> wrote:
Hi,
Plea
Hi Eric,
Thank you for fixing that.
Just for the record, I want to mention that this bug was also fixed by
Eric in standalone JAXB project and it won't be erased during the next
JAXWS sync-up process.
With Best Regards,
Aleksej
On 03/16/2016 10:48 AM, Eric Guo wrote:
Hi Lance,
Does it need
Hi,
Please, help to review the addition of new test for JDK-8145039 [1]:
http://cr.openjdk.java.net/~aefimov/8145039/9
The test requires full JDK hence it was added to 'needs_jdk' test group.
The source fix for this bug was already delivered to JDK9 as part of
sync with upstream JAXWS project
Hi Lance,
Thanks for review!
Best
Aleksej
On 02/29/2016 02:43 PM, Lance Andersen wrote:
Hi Alejsej
This looks fine
Best
Lance
On Feb 24, 2016, at 5:50 PM, Aleksej Efimov <aleksej.efi...@oracle.com
<mailto:aleksej.efi...@oracle.com>> wrote:
Hi,
Please, review the bulk update
Hi,
Please, review the bulk update of JAX-WS/B from upstream projects:
http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8150174/9/00/
Details (list of fixed issues) can be found in bug report:
https://bugs.openjdk.java.net/browse/JDK-8150174
The following test sets were executed over
Hi Christoph,
The changes looks good to me too. I will push them shortly today.
With Best Regards,
Aleksej
On 02/24/2016 02:49 AM, Langer, Christoph wrote:
Hi,
the changeset for 8149915 (enabling validate-annotations feature for
xsd schema with annotation causes NPE) introduced a
Hi,
Please, help to review the fix for JDK-8144593 bug [1] in jaxp area:
http://cr.openjdk.java.net/~aefimov/8144593/9/00/
Problem:
JDK produces warnings when non-default parser implementation is used and
this parser doesn't support jaxp features/properties. The quantity of
such messages can
null" but indeed empty. To do that, you
may change the 1st nodeset to return meaningful result to show that
the leading function returns the 1st set, which proves that the 2nd is
empty.
Thanks,
Joe
On 12/3/2015 4:25 PM, Aleksej Efimov wrote:
Hi,
Please, help to review and approve JDK-813392
Hi,
Please, help to review and approve JDK-8133924 backport to JDK8. The
source fix is identical to JDK9 changes, but there was no test added for
this issue in JDK9.
The existing
jdk/test/javax/xml/jaxp/transform/8062518/XSLTFunctionsTest.java test
was modified to test the reported problem
Hello,
Please, review the fix for schemagen regression bug [1] in JDK9: The
JDK9 (and JDK8 too) version of schemagen doesn't report errors during
the compilation of the input java file.
The issue was introduced by standalone JAXB project changes and then it
was synced to JDK source. The
Hi,
Please, help to review the latest tzdata integration [1] fix to JDK9:
http://cr.openjdk.java.net/~aefimov/tzdata/2015g/9/00/index.html
Testing shows no failures in time zones related tests.
With Best Regards,
Aleksej
[1] JBS: https://bugs.openjdk.java.net/browse/JDK-8138716
Hi Frank,
Fix looks good to me (not a reviewer). Did you have a chance to run JCK
tests with proposed fix?
Also we'll need to backport this change. Do you have a plan to do it? If
not then I can handle it.
With Best Regards,
Aleksej
On 08/25/2015 12:43 PM, Frank Yuan wrote:
Hi, Joe and all
Hello,
Please review latest tzdata (2015f) integration into JDK9:
http://cr.openjdk.java.net/~aefimov/tzdata/2015f/9/00
Testing shows no TZ related failures on all platforms.
Thanks,
Aleksej
JBS: https://bugs.openjdk.java.net/browse/JDK-8133321
it be the same effect, if
you set pb.inheritIO()?
Otherwise looks good.
Sincerely yours,
Ivan
On 25.06.2015 20:52, Aleksej Efimov wrote:
Hi Ivan!
Thanks for suggestions. Also I took an opportunity and rewrote it to
testNG format + cleaned it up and modified schema content check
logic. Now test looks
at line 1 -
[testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET)
-95400 1969-12-20T23:00:00.000Z'
[testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST)
-95400 1969-12-20T23:00:00.000Z'
Attila.
On Jun 24, 2015, at 1:05 PM, Aleksej Efimov
aleksej.efi
Hi,
Any comments on this changes?
With Best Regards,
Aleksej
On 06/23/2015 07:02 PM, Aleksej Efimov wrote:
Hi,
Please, review, comment and approve GenerateEnumSchema.java test bug
fix [1]. It solves the following problem: test launches schemagen tool
from a 'test.src' folder and in cases
Gerasimov wrote:
Hi Aleksej!
Would it make sense to use jdk.testlibrary.JDKToolLauncher to run
schemagen?
This way the test would become somewhat shorter.
Sincerely yours,
Ivan
On 25.06.2015 17:31, Aleksej Efimov wrote:
Hi,
Any comments on this changes?
With Best Regards,
Aleksej
On 06/23/2015 07
Hello,
Please, review the latest tzdata (2015e) [1] integration to JDK9:
http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0
Testing shows no TZ related failures on all platforms.
With Best Regards,
Aleksej
[1] https://bugs.openjdk.java.net/browse/JDK-8098547
Hi,
Please, review, comment and approve GenerateEnumSchema.java test bug fix
[1]. It solves the following problem: test launches schemagen tool from
a 'test.src' folder and in cases when 'test.src' is not writeable
failure occurs. The proposed fix [2] solves this issue - it creates a
test
Hi,
Please, review JDK9 fix [1] for a bug [2] in 'getNodeValue' JAXP function:
According to w3c [3] getNodeValue should return 'null' value for
Element nodes. This behavior was changed by JDK-8032908 [4] fix - in
current implementation the node content is returned.
To address this issue the
using a node's dtm, not the
main one.
Testing: JCK, JTREG with new test and JAXP testset shows no failures
Thank you,
Aleksej
[1] JBS: https://bugs.openjdk.java.net/browse/JDK-8062518
[2] Webrev: http://cr.openjdk.java.net/~aefimov/8062518/9/webrev.01
On 01/19/2015 03:26 PM, Aleksej Efimov
Hi,
Please, review the fix for adding the latest tzdata2015d to JDK9.
The JTREG and JPRT tests were executed.
No failures were observed.
Thank you,
Aleksej
[1] JBS: https://bugs.openjdk.java.net/browse/JDK-8077685
[2] Webrev: http://cr.openjdk.java.net/~aefimov/tzdata/2015d/9/00
Hello,
Can I ask for approval of the JDK-8073357 [2] bug fix [1] to JDK8. The
original fix contains only test modifications, but the jaxws part was
introduced during JAXWS synchronization [3] in JDK9. The schemagen
changes [4] related to the reported failure were backported from JDK9.
This
the
output file multiple times.
Regards,
Joe
On 4/20/2015 1:22 PM, Lance Andersen wrote:
Hi Aleksej,
The updates to the test seem reasonable.
Best
Lance
On Apr 20, 2015, at 2:00 PM, Aleksej Efimov
aleksej.efi...@oracle.com wrote:
Hello,
The JDK9 schemagen tool hadn't preserved order of the enum
On 04/21/2015 07:36 PM, huizhe wang wrote:
On 4/21/2015 5:14 AM, Aleksej Efimov wrote:
Hi Joe,
Thank you for you comments - I have modified the test [1] to avoid
multiple file open operations - now the test reads the file content
one time after each call to schemagen tool.
Ok.
Golden
Hello,
The JDK9 schemagen tool hadn't preserved order of the enum values [1]
and it was fixed in standalone project and was synced to JDK as part of
JAXWS integration [2].
Can I have a review for the
'test/javax/xml/ws/8046817/GenerateEnumSchema.java' test update [3] to
include test case for
Hello,
The latest JAXWS [1] integration to JDK9 reverted back three bug fixes
in JAXWS repository:
https://bugs.openjdk.java.net/browse/JDK-8073374
https://bugs.openjdk.java.net/browse/JDK-8073696
https://bugs.openjdk.java.net/browse/JDK-8073361
It was caused by skipped integration to
Mandy, Alan,
Thanks for reviews.
With Best Regards,
Aleksej
On 04/17/2015 04:58 PM, Alan Bateman wrote:
On 17/04/2015 14:31, Aleksej Efimov wrote:
Hello,
The latest JAXWS [1] integration to JDK9 reverted back three bug
fixes in JAXWS repository:
https://bugs.openjdk.java.net/browse/JDK
Hello,
Please, review an exclusion of GenerateEnumSchema.java from
ProblemList.txt [1]. The problem was fixed in upstream JAXWS project and
was bringed over to JDK as part of sync-up process [2]. The test passes
on all platforms after exclusion on JDK9 JPRT builds.
With Best Regards,
.
The change looks OK.
Best
Lance
On Apr 17, 2015, at 12:29 PM, Aleksej Efimov
aleksej.efi...@oracle.com mailto:aleksej.efi...@oracle.com wrote:
Hello,
Please, review an exclusion of GenerateEnumSchema.java from
ProblemList.txt [1]. The problem was fixed in upstream JAXWS project
)) {
Properties props = new Properties();
try(InputStream stream = Files.newInputStream(path)) {
props.load(stream);
return props.getProperty(factoryId);
}
}
returnnull;
}
no try-with-resources in JDK6
On Fri, Apr 10, 2015 at 7:09 AM, Aleksej Efimov
aleksej.efi...@oracle.com
Hi,
Can I kindly ask for a review of this JAX-WS update?
With Best Regards,
Aleksej
On 04/03/2015 06:20 PM, Aleksej Efimov wrote:
Hello,
Can I have a review for a JDK9 bulk update of JAX-B/WS from upstream
projects.
Webrev: http://cr.openjdk.java.net/~aefimov/8076549/9/00/
More details
Hello,
Can I have a review for a JDK9 bulk update of JAX-B/WS from upstream
projects.
Webrev: http://cr.openjdk.java.net/~aefimov/8076549/9/00/
More details in issue description:
https://bugs.openjdk.java.net/browse/JDK-8076549
Thank you,
Aleksej
Hi,
Please review a fix for JCK test failure [2] that was caused by slightly
incorrect fix for JDK-8074297 [3].
The problem is that the length of required string is incorrectly
calculated when the start index is less or equal than zero: The pushed
fix for JDK-8074297 assumes that length are
-time code. We do need a fix for JDK-8014468.
Masayoshi
On 3/27/2015 12:47 AM, Aleksej Efimov wrote:
Hi,
Please review the fix for adding the latest tzdata2015b to JDK9.
The JTREG and JPRT tests were executed.
No failures were observed, except one:
test/sun/util/calendar/zi/TestZoneInfo310.java
repo instead of jdk? You'd find
the same package under jaxp/test/javax/xml/jaxp/unittest, and may use
any of the javax.xml.parsers tests as an example.
Thanks,
Joe
On 3/26/2015 9:04 AM, Aleksej Efimov wrote:
Hi,
Please review the fix for corrupted error messages in XML parser.
When the XML
Hi,
Please review the fix for corrupted error messages in XML parser. When
the XML parser encounters illegal
character the message with incorrect data is generated:
An invalid XML character (Unicode: 0x{2}) was found in the value of
attribute {1} and element is 0.
But it should be like:
An
Hi,
Please review the fix for adding the latest tzdata2015b to JDK9.
The JTREG and JPRT tests were executed.
No failures were observed, except one:
test/sun/util/calendar/zi/TestZoneInfo310.java
The failure was caused by the following tzdb rule addition to
make/data/tzdata/asia:
+Rule
Hello,
Please review the fix for XSLT 'substring' function that solves the
problem when string parameter contains supplementary characters.
The 'test/javax/xml/jaxp/transform/8062923/XslSubstringTest.java' test
was updated to include the test cases for fail behavior. Fixed function
utilizes
Than you, Alan!
Will integrate this fix now.
-Aleksej
On 02/11/2015 07:45 PM, Alan Bateman wrote:
On 11/02/2015 16:20, Aleksej Efimov wrote:
Hi Alan, Miran,
If I understood correctly we can fix gt; in the next bulk update
(in early March). If it's so, can I have an approval for this fix
Hi Alan, Miran,
If I understood correctly we can fix gt; in the next bulk update (in
early March). If it's so, can I have an approval for this fix?
Thank you,
Aleksej
On 02/02/2015 01:46 PM, Miroslav Kos wrote:
On 29/01/15 16:06, Alan Bateman wrote:
On 29/01/2015 14:51, Aleksej Efimov wrote
Hi,
Could I have a review the latest tzdata2015a integration fix to JDK9,
please. The regression tests run and JPRT testing (jdk_other,jdk_util,
jdk_text, jdk_time test sets) shows no TZ related JDK9 failures.
Thank you,
Aleksej
Bug link: https://bugs.openjdk.java.net/browse/JDK-8072042
Hi,
Can I have a review for a bulk update of JAX-B/WS from upstream projects -
webrev: http://cr.openjdk.java.net/~aefimov/8071585/webrev/
more details in JBS: https://bugs.openjdk.java.net/browse/JDK-8071585
There is a lot of changes (947 lines) but almost all of them are minor
(comments
at a functional test (javax/xml/jaxp/functional) since
Tristan has refactored them, and SQE plans to do the same with the
unit tests. For a testng test, the @run tag is not necessary.
The jaxp tests are defined in its own testset jaxp.
Thanks,
Joe
On 1/19/2015 3:25 AM, Aleksej Efimov wrote:
Hi
Please, review the fix for the failure observed while accessing external
document during xsl transformation:
https://bugs.openjdk.java.net/browse/JDK-8062518
The jaxp code limits the access to external documents, but there is a
possibility to access such documents from the xsl code - new
Hi,
Please, review the fix for the XSL substring function failures. Two
issues were reported during usage of this function:
1. Runtime internal error with negative length:
https://bugs.openjdk.java.net/browse/JDK-8062923
2. Wrong answer when -Inf length is used:
and running tests.
Thanks
Miran
On 14/10/14 09:29, Aleksej Efimov wrote:
Hi XML experts,
Can I humbly ask to review this simple fix.
Thank you,
Aleksej
On 08.10.2014 13:09, Aleksej Efimov wrote:
Hello,
Please, review the fix [1] for the 8046817 [2].
Problem: schemagen tool doesn't generate
Hello Sherman, Masayoshi and other experts,
Can I ask for a JDK9 review for the
sun/util/calendar/zi/TestZoneInfo310.java test failure [1] that was
caused by incorrect handling of last rules for Africa/Casablanca time
zone. This timzone has two last rules and three instant rules in a range
Sherman, thank you for looking into this problem and helping solve it. I
will change the formatting before the push.
-Aleksej
On 12/15/2014 07:17 PM, Xueming Shen wrote:
On 12/15/14 8:06 AM, Aleksej Efimov wrote:
Hello Sherman, Masayoshi and other experts,
Can I ask for a JDK9 review
Hello,
During the latest tzdata (2014j) integration the tzdb.dat build failure
was observed - details can be found in JBS [1].
The proposed [2] fix resolves time zones double link problem and JDK
compilation is succedded.
Can I ask a review for this fix, please?
Thank you,
Aleksej
[1] Bug
Hi,
Can I ask for review of new tzdata - 2014i integration fix to JDK9. One
change in this release is that new time zone was added -
Pacific/Bougainville. The localized names still needs to be translated
- the appropriate comment was added to JDK-8057004.
Testing results:
JPRT tests:
to Daylight. No daylight saving time is observed in
Bougainville, though.
Otherwise, all the changes look good to me.
Thanks,
Masayoshi
On 10/28/2014 8:57 PM, Aleksej Efimov wrote:
Hi,
Can I ask for review of new tzdata - 2014i integration fix to JDK9.
One change in this release is that new time
with
integration and running tests.
Thanks
Miran
On 14/10/14 09:29, Aleksej Efimov wrote:
Hi XML experts,
Can I humbly ask to review this simple fix.
Thank you,
Aleksej
On 08.10.2014 13:09, Aleksej Efimov wrote:
Hello,
Please, review the fix [1] for the 8046817 [2].
Problem: schemagen tool doesn't
Hi XML experts,
Can I humbly ask to review this simple fix.
Thank you,
Aleksej
On 08.10.2014 13:09, Aleksej Efimov wrote:
Hello,
Please, review the fix [1] for the 8046817 [2].
Problem: schemagen tool doesn't generate schema file for the enum
types [3].
SchemaGenerator class gets a list
Hello,
Please, review the fix [1] for the 8046817 [2].
Problem: schemagen tool doesn't generate schema file for the enum types [3].
SchemaGenerator class gets a list of annotated elements and filters out
only the class variables, but annotation parser (AnnotationParser.java)
filters out the
,
I don't see the America/Grand_Turk change in webrev.04. I wonder if
the webrev wasn't updated correctly.
Thanks,
Masayoshi
On 9/1/2014 11:10 PM, Aleksej Efimov wrote:
Masayoshi,
I have addressed all your comments with proposed resolution. Thank
you for such thorough analysis of this changes
10:53 PM, Aleksej Efimov wrote:
Masayoshi,
Thank you for a detailed review - I tried to address all your
comments. Please, see the updated review:
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03
About the workarounds - I will start discussion with Sherman when the
tzdata2014f (and I
Lance, thank you for the review. Correct - it was also reviewed by Miran.
Aleksej
On 08/28/2014 09:35 PM, Lance Andersen wrote:
This change looks fine and I believe Miran also reviewed this.
Best
Lance
On Aug 27, 2014, at 9:45 AM, Aleksej Efimov aleksej.efi...@oracle.com
mailto:aleksej.efi
Hi,
I'm adding a core-libs-dev mail list - I might be lucky to find a JDK8
reviewer for my fix there.
Thank you,
Aleksej
On 08/26/2014 06:12 PM, Aleksej Efimov wrote:
Hi Dalibor,
It's a partial backport (logged with a different bugID) of JDK9 fix, I
got an approval from Miran (Thank you
, MSK,
+ Volgograd Summer
Time, MSK,
+ Volgograd Time,
MSK}},
The long names should be changed accordingly.
Thanks,
Masayoshi
On 8/22/2014 9:17 PM, Aleksej Efimov wrote:
Masayoshi,
You're right
Thank you Lance!
-Aleksej
On 27.08.2014 19:56, Lance Andersen wrote:
I will review it by the end of the week
On Aug 27, 2014, at 9:45 AM, Aleksej Efimov aleksej.efi...@oracle.com
mailto:aleksej.efi...@oracle.com wrote:
Hi,
I'm adding a core-libs-dev mail list - I might be lucky to find
.
Thanks,
Masayoshi
On 8/21/2014 5:05 PM, Aleksej Efimov wrote:
Masayoshi,
I agree that we should change the long names to match the new short
names introduced by tzdata.
But I suggest to log a different CR for such activity to handle long
name changes and their translations (this activity
/2014 11:59 PM, Aleksej Efimov wrote:
Hi,
Please, review the tzdata2014f integration (with tzdata2014e related
changes included too) [1] fix to JDK9:
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
The tzdata2014f changes are extensive and relates mostly to timezone
short names
Hi,
Please, review the tzdata2014f integration (with tzdata2014e related
changes included too) [1] fix to JDK9:
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
The tzdata2014f changes are extensive and relates mostly to timezone
short names changes + Asia/Srednekolymsk time zone
Hello,
Can I ask one more time for a review of this tzdata fix, please?
-Aleksej
On 07/22/2014 11:21 PM, Aleksej Efimov wrote:
Hi,
Please review the tzdata2014e [1] integration fix to JDK9:
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.00/
Two issues with JSR310 implementation were
Hello,
I'm withdrawing this review request because the new tzdata2014f release
is available. I will update the 8049343 bug and will use it for later
tzdata2014f integration.
Thank you,
Aleksej
On 08/06/2014 05:30 PM, Aleksej Efimov wrote:
Hello,
Can I ask one more time for a review
Joe,
Thank you for the review!
Aleksej
On 07/30/2014 09:42 PM, huizhe wang wrote:
Hi Aleksej,
The change looks good, as we discussed previously.
Thanks,
Joe
On 7/30/2014 9:32 AM, Aleksej Efimov wrote:
Hi,
Please, review the fix [1] for the Node.getTextContent() bug:
https
Hello,
Please review the fix [1] for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8029837
The problem was discovered during usage of not compatible old JAXB/XJC
classes on the stack with latest JDK source (starting from 7u40
release). The problem is that the JAXP
Joe,
Thank you for the review.
-Aleksej
On 07/22/2014 09:52 PM, huizhe wang wrote:
Hi Aleksej,
The change looks good.
Thanks,
Joe
On 7/22/2014 6:10 AM, Aleksej Efimov wrote:
Hello,
Please review the fix [1] for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8029837
Hi,
Please review the tzdata2014e [1] integration fix to JDK9:
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.00/
Two issues with JSR310 implementation were discovered during integration
process:
First issue is related to the internal representation of the '24:00'
value. The JSR310
Thank you David.
Thank you Staffan.
On 06/04/2014 01:46 PM, David Holmes wrote:
Me too.
Thanks,
David
On 4/06/2014 5:23 PM, Staffan Larsen wrote:
Looks ok to me.
/Staffan
On 3 jun 2014, at 15:49, Aleksej Efimov aleksej.efi...@oracle.com
wrote:
Staffan, David,
Returning back to our
:
On 15 maj 2014, at 03:48, David Holmes david.hol...@oracle.com wrote:
On 14/05/2014 11:18 PM, Aleksej Efimov wrote:
David, Vitaly,
I totally agree with Vitaly's explanation (Vitaly - thank you for that)
and code in shmemBase.c (the usage of enterMutex() function for
sending/receiving bytes through
/2014 11:19 PM, Aleksej Efimov wrote:
David,
The Windows has a different terminology for mutex objects (much
differs
from the POSIX one). This one link gave me some understanding of
it [1].
Here is the MSDN [1] description of what abandoned mutex
Hello,
Can I have a review for the tzdata2014c integration to JDK9. This is a
standard release of tzdata (except the hurry with Egypt rules - the main
part in this release).
The following set of tests was executed with no failures:
test/sun/util/calendar test/java/util/Calendar
Hi,
Can I have a review for 8032901 bug [1] fix [2]. There is a possible
case when 'WaitForMultipleObjects' function can return the
WAIT_ABANDONED_0 [3] error value.
In such case it's better to release the mutex and return error value.
This will prevent other threads to be blocked on
, Aleksej Efimov wrote:
Hi,
Can I have a review for 8032901 bug [1] fix [2]. There is a possible
case when 'WaitForMultipleObjects' function can return the
WAIT_ABANDONED_0 [3] error value.
In such case it's better to release the mutex and return error value.
This will prevent other threads
outline of the conditions that cause this? I
think that would be useful to understand the issue further.
-Alan
On 13/05/2014 11:46, Aleksej Efimov wrote:
Hi,
Can I have a review for 8032901 bug [1] fix [2]. There is a possible
case when 'WaitForMultipleObjects' function can return
Masayoshi,
The new webrev with proposed generic names for Antarctica/Troll can be
found here: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.01
Thank you,
Aleksej
On 04/03/2014 06:29 PM, Aleksej Efimov wrote:
Masayoshi,
How about Troll Time and ATT for generic long and short names
:
Another option would be Troll Station Time and TST. But your
invention is fine with me.
Thanks,
Masayoshi
On 4/4/2014 9:19 PM, Aleksej Efimov wrote:
Masayoshi,
The new webrev with proposed generic names for Antarctica/Troll can
be found here: http://cr.openjdk.java.net/~aefimov/8038306/9
Hello,
Can I have a review for the latest (2014b) TZ data integration to JDK9.
The webrev can be located here [1].
The following set of tests were executed without failures:
test/sun/util/calendar test/java/util/Calendar
test/sun/util/resources/TimeZone test/sun/util/calendar
:+1.781.442.2037
Oracle Java Engineering
1 Network Drive x-apple-data-detectors://34/0
Burlington, MA 01803 x-apple-data-detectors://34/0
lance.ander...@oracle.com mailto:lance.ander...@oracle.com
Sent from my iPad
On Mar 26, 2014, at 1:44 PM, Aleksej Efimov aleksej.efi...@oracle.com
mailto:aleksej.efi
Hello,
Can I ask for a review for the update of DOMSerializerImpl class [1] to
the latest Apache Xerces implementation.
The following changes were made:
1. The DOMSerializerImpl update: The Xerces class was used as a base
[2]; the 476047 and 473125 revisions from Xerces was excluded (they
, 2014, at 12:54 PM, Lance Andersen
lance.ander...@oracle.com mailto:lance.ander...@oracle.com wrote:
Hi Aleksej,
Do you really need to use run.sh? If possible it would be better to
try and avoid providing a script and use the jtreg keywords.
Best
Lance
On Mar 26, 2014, at 12:39 PM, Aleksej
Hello,
Can I have a review for a tzdata2014a [1] integration to JDK9:
http://cr.openjdk.java.net/~aefimov/8037012/9/webrev.00
The following test sets were executed on the build with latest tzdata:
test/sun/util/calendar test/java/util/Calendar
test/sun/util/resources/TimeZone
Hello,
Can I have a review for a 'test/sun/util/calendar/zi/Zoneinfo.java' test
bug failure [1] related to the latest tzdata2014a integration [2].
The test failure message:
Asia/Istanbul : Asia/Istanbul
Hi,
There is a problem in XSLT string-length function:
When string passed to this function contains complementary chars the
current implementation of XPath treates this sequence as two characters
(the string-length returns 2). But according to the w3 spec it should be
treated as a single
*.properties files, which were temporarily
created for the translation work, be removed.
Thanks,
Masayoshi
On 1/21/2014 10:17 PM, Aleksej Efimov wrote:
Hi,
Can I have a review for 2013i timezone data integration [1] to JDK9.
There is one change in tzdb that affects naming for Asia/Amman
timezone
Hi,
Can I have a review for 2013i timezone data integration [1] to JDK9.
There is one change in tzdb that affects naming for Asia/Amman timezone:
The Jordan switches back to standard time at 00:00 on December 20,
2013.
All changes in TimeZoneNames*.java and TimeZoneNames*.properties files
and
Happy New Year to all OpenJDK community members (at least members who
read this letter :) ).
-Aleksej
On 12/24/2013 10:39 AM, Masayoshi Okutsu wrote:
Looks good to me.
Masayoshi
On 12/23/2013 3:14 AM, Aleksej Efimov wrote:
Hi,
The new version of patch for TimeZone display names update
webrev: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.02/
http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.02/
-Aleksej
On 12/20/2013 03:39 PM, Aleksej Efimov wrote:
Masayoshi,
Thank you for the detailed review and your comments. I tried to
address all of them. The responses
, Masayoshi Okutsu wrote:
On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
Hi,
Please help to review a fix [1] for 8025051 bug [2]. The following
fix includes:
Common to all modified files:
- All year ranges in the copyright header should be modified accordingly.
Fixed.
- The translation
Hi,
Please help to review a fix [1] for 8025051 bug [2]. The following fix
includes:
- The translation of time zone generic names were added to all locales.
- Time Zone names were updated according to the latest translations.
- Added tz names regression test
Hi,
Can I ask reviewers to look at this fix? As was mentioned, the testing
issues described in request were resolved.
Thanks in advance,
Aleksej
On 11/06/2013 11:11 PM, Aleksej Efimov wrote:
Hi,
We have a fix for JDK-8027848 and it was approved in parallel thread.
With '-XX
1 - 100 of 143 matches
Mail list logo
