Re: TLS 1.2

On 18/05/2020 07:50, Neil Meyer wrote: Hi David, Unfortunately that didnt work it will only work on Java 7 update 95 and not on Update 80 of the Oracle JDK, I would like to know which version of OpenJDK will work and what update? Is this the issue you are looking for: https://bugs.openjdk

Re: Backporting the TCP loopback fast path (Windows) improvement to OpenJDK v7

On 30/01/2015 12:18, Seán Coffey wrote: Alan, hadn't spotted the race issue. I guess we could delay setting ver_initialized until OSVERSIONINFO is populated. Alternatively - like you say, I think we can revert back to the simpler edit : http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v

Re: Backporting the TCP loopback fast path (Windows) improvement to OpenJDK v7

On 26/01/2015 13:48, Seán Coffey wrote: Valeriy, those changes look fine to me and I've verified that they run through testing fine also. webrev here for reference : http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v3/webrev/ Can I have a jdk7u reviewer for this change ? There is a race

Re: [7u-dev ONLY] RFR: [8057530] (process) Runtime.exec throws garbled message in jp locale

On 24/10/2014 10:46, Ivan Gerasimov wrote: Yes. I thought it's better to keep it the way it has been formatted in 8. Do you want me to change this to make lines shorter? No need for that, the inconsistencies were in the original changes, not your doing. -Alan.

Re: [7u-dev ONLY] RFR: [8057530] (process) Runtime.exec throws garbled message in jp locale

On 24/10/2014 03:52, Ivan Gerasimov wrote: Thanks Dalibor! Could someone with the Reviewer status review this please Skimming through the changes then I don't see any issues, except overly long lines in win32Error which makes it hard to look at the changes side-by-side. It would be nice not to

Re: RFR: 8041980 + 6461635

On 29/08/2014 04:20, Andreas Eriksson wrote: Thanks Staffan! Could I get a Reviewer too look at this as well please? I got a question why the changesets didn't apply cleanly to jdk7, here is a summary: For the HotSpot part: There were no aix or bsd-darwin mapfiles in jdk7. For JDK: The te

Re: [7u-dev] Request for approval 8025644: java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java fails with TestData$OfRef): failure java.lang.AssertionError: expected [true] but

On 05/09/2014 09:20, Sergey Gabdurakhmanov wrote: Hello, Could you please approve the back-port of the fix for 8025644 to jdk7u-dev? I wonder why the bug synopsis wasn't changed to something that reflects the actual issue. java.util.stream is new in Java SE 8 so a bit strange to have a fix wi

Re: 7u60 Request for phase 2 approval for CR 8020191 - System.getProperty( " os.name " ) returns " Windows NT (unknown) " on Windows 8.1

On 22/01/2014 21:25, Miroslaw Niemiec wrote: Jira bug: https://bugs.openjdk.java.net/browse/JDK-8020191 This is a direct backport from 8 to 7. No changes needed to the original webrev: Is there a corresponding change for the hotspot repo so that it reports the OS version in the error logs?

Re: [7u-communication] Future Plans for JDK 7 Updates 7u60 & 7u80

On 14/01/2014 07:02, Francis ANDRE wrote: Why new contributions should go to jdk9 and jdk8 first?? I am interested in building the hotspot of the jdk7u, not in jdk8 or jdk9 -- building hotspot of jdk8 on WXP does not work -- ... So, it is a triple work that OpenJDK is asking for having a fix pr

Re: [7u-communication] 7u60 Early Access Builds

On 05/12/2013 17:24, Dalibor Topic wrote: : For developers who wish to test binaries based the 7u60-b01 tagged code in the OpenJDK jdk7u/jdk7u forest, the Oracle JDK 7 Update 60 Early Access Release based on it is available for download at : https://jdk7.java.net/download.html . The changes list

Re: [PATCH] Display human readable progress instead of many dots in jhat

On 10/12/2013 03:30, Xiaoguang Sun wrote: Display hunan readable progress instead of many dots in jhat There wasn't any patch attached to your mail but if you are proposing a patch to the jhat tool then the serviceability-dev is the mailing list to use. See also the "How to contribute" page [1]

Re: JDK-8014394

On 05/12/2013 12:36, Jérôme Marant wrote: Hi, Has JDK-8014394 made its way into 7u60 yet? I can't see it but maybe I'm looking at the wrong place. Regards, Here's the bug: https://bugs.openjdk.java.net/browse/JDK-8014394 and if you look under "Backports" then you can see that there is a ba

Re: [7u-communication] OpenJDK 7u60: Scope & Milestones

On 27/11/2013 12:32, Dalibor Topic wrote: On 11/19/13 10:42 PM, Dalibor Topic wrote: I provided some initial information on the planned 7u60 timeline a little while ago. [1] I'd like to pick up that thread, and provide some more details on the planned scope and milestones. Since the discussio

Re: What preprocessor is used for java source templates?

On 26/11/2013 12:40, Alex Yursha wrote: Hi everyone, Could you, please, tell me what preprocessor is used to preprocess java source templates? For example file X-Buffer.java.template in folder src/share/java/nio. Look at builds.tools.spp.Spp, it mostly just uses regex. -Alan.

Re: [7u-communication] OpenJDK 7u60: Scope & Milestones

On 19/11/2013 21:42, Dalibor Topic wrote: : So instead, I'd like to propose that OpenJDK 7u adopts a similarly high bar for acceptable changes for 7u60 from now on, to reduce the potential for undesirable divergences between this 7u release and JDK 8. In practice, that means marking issues yo

Re: [7u] problem with jdk test java/nio/channels/DatagramChannel/SendToUnresolved.java

On 28/10/2013 04:10, Francis ANDRE wrote: Hi On my WXP/Cygwin/VS2010 platform, this jdk test java/nio/channels/DatagramChannel/SendToUnresolved.java fails because the TestUtil.UNRESOLVABLE_HOST which is the string "blah-blah.blah-blah.blah" gets resolved to blah-blah.blah-blah.blah/66.152.109

Re: [7u]: patches for the jdk jtreg tests for non US locale

On 26/10/2013 17:22, Francis ANDRE wrote: Hi Here patches for making the jdk jtreg tests succeed Just an FYI that one of the ground rules for the jdk7u project [1] is that fixes go into jdk8 first. This means that you probably should bring these patches to appropriate mailing list for discuss

Re: Request for approval for 8025255: (tz) Support tzdata2013g

On 16/10/2013 22:12, Aleksej Efimov wrote: Hi, This is a backport of the following JDK 8 bug [1] to 7u-dev. Would it be possible to wait a day or two to see if any issues come from the change pushed to jdk8/tl? There is at least one new test failure in jdk8/tl (see JDK-8026772) that may be caus

Re: JDK-8014394

On 15/10/2013 12:19, Jérôme Marant wrote: Hi, Would it be possible to backport JDK-8014394 to JDK 7, please? This bug has been fixed in JDK 8 but it is not going to be adopted anytime soon and it is very annoying for those using SAMBA mounts. I was reviewer for this one and don't have any objec

Re: CFV: New JDK7u Committer: Mikhail Cherkasov

On 14/10/2013 23:19, alexander potochkin wrote: I kindly ask you to revise you veto and support Mikhail I'm sorry, but I cannot support this nomination at this time. I completely agree that it can take a huge effort to arrive at a one-line fix, we've all been there. It's just that the totalit

Re: CFV: New JDK7u Committer: Mikhail Cherkasov

Vote: Veto The guidelines suggest at least 8 significant contributions but some of the changes cited in the nomination don't appear (at least on the surface) to be significant. For example, one of the changes is a one-line fix, another is a two-line update to a properties file, another is the

Re: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)"

On 10/10/2013 20:56, Yuri Gaevsky wrote: Hello, I'm trying to follow [1] in order to propose a patch for JDK-7052549 [2] into the JDK 7 Updates and hopefully this is the correct mailing list for it. The code in clearPendingIoMap() doesn't use 'synchronized' access to internal data as all other

Re: [jdk7u-dev] Request for approval: 7180557

On 09/10/2013 00:20, Rob McKenna wrote: Hi folks, 7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX webbugs http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1e31376f419 https://bugs.openjdk.java.net/browse/JDK-7180557 8 review thread: http://mail.openjdk.java.net/pipe

Re: [7u communication] JDK 7u40 released today!

On 11/09/2013 21:23, Seán Coffey wrote: On 11/09/13 20:35, Andrew Hughes wrote: Thanks. I wasn't aware of these. Are these "EA binaries" OpenJDK? AFAIK, the Java SE 8 EA binary that's released weekly is used for testing. That binary shares a codebase with OpenJDK and results from it would b

Re: [7u-dev] Request for approval for 8023964 : java/io/IOException/LastErrorString.java should be @ignore-d

On 29/08/2013 16:19, Seán Coffey wrote: Simple testcase ignore request. This test causes issue for systems if run as root. It's already been excluded in JDK 8 via a problemlist update (7081813). Would like to port to 7u-dev. Need a reviewer also. That test has had @ignore in jdk8 for some time,

Re: [7u40] Review request for CR 8014925: Disable sun.reflect.Reflection.getCallerClass(int) with a temporary switch to re-enable it

On 09/08/2013 08:40, Andrew Hughes wrote: : I don't think the code should be referring to things that don't exist. How does someone using OpenJDK know what this reference means? Just an FYI that the exception message was changed as part of 8021946 and no longer has a reference to release note

Re: there is a bug in openjdk7.

On 05/08/2013 15:16, Andrew Hughes wrote: : The problem is this change: changeset: 6767:6bf5fa233df0 user:mchung date:Tue Jul 02 13:23:35 2013 -0700 summary: 8014925: Disable sun.reflect.Reflection.getCallerClass(int) with a temporary switch to re-enable it as mentioned

Re: Concern about Java 7u40 timeline

On 02/08/2013 10:09, Sam Reid wrote: One more thing, JDK-8017174 is still not listed in the j7u40 features & changes [2] even for build 35 so I am still a bit confused about that. Can you send a test case to demonstrate the NPE that you are seeing in logging? (to help understand if this is the s

hg: jdk7u/jdk7u40-dev/jdk: 8021946: Disabling sun.reflect.Reflection.getCallerCaller(int) by default breaks several frameworks and libraries

Changeset: 244dbaeab45e Author:alanb Date: 2013-08-01 17:25 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u40-dev/jdk/rev/244dbaeab45e 8021946: Disabling sun.reflect.Reflection.getCallerCaller(int) by default breaks several frameworks and libraries Reviewed-by: chegar, dholmes, d

Re: [7u40] Request for phase 2 approval for 8021946: Disabling sun.reflect.Reflection.getCallerCaller(int) by default breaks several frameworks and libraries

On 01/08/2013 01:56, Daniel Fuchs wrote: Hi Alan, If it's not too late you might want to add a testcase in the test for: @run main/othervm -Djdk.logging.allowStackWalkSearch=true GetCallerClass since that is supposed to switch allowGetCallerClass on. best regards, -- daniel The logging tests

[7u40] Request for phase 2 approval for 8021946: Disabling sun.reflect.Reflection.getCallerCaller(int) by default breaks several frameworks and libraries

A few weeks ago we pushed a change that "disables" the JDK private method sun.reflect.Reflection.getCallerClass(int). Those that have been following the effort to check the usages of caller sensitive methods in the JDK will be familiar with the background to this. At the time it was known th

Re: java.util.logging bug 8017174 should be fixed for Java 7

On 03/07/2013 22:33, Sam Reid wrote: Hi there, My name is Sam Reid, I am a software engineer at PhET Interactive Simulations (http://phet.colorado.edu/) at the University of Colorado Boulder. We publish free, open source educational simulations, most of which are developed for the Java runti

Re: [7u40] Review request for CR 8014925: Disable sun.reflect.Reflection.getCallerClass(int) with a temporary switch to re-enable it

On 19/06/2013 16:31, Mandy Chung wrote: Thanks. I have revised the exception message and the test: http://cr.openjdk.java.net/~mchung/jdk7u/8014925/webrev.01/ Mandy This looks okay to me, lengthy, but okay. -Alan.

Re: [7u] Request for approval for bulk changes from Jun CPU fixes into 7u

On 19/06/2013 13:48, Andrew Hughes wrote: : This includes a mass of fixes that aren't security fixes but may be related to them: I was wondering the same thing as it includes fixes that are already in jdk7u. From what I can tell, the actual push is right, it's just the webrev that is wrong.

Re: [7u40] Review request for CR 8014925: Disable sun.reflect.Reflection.getCallerClass(int) with a temporary switch to re-enable it

On 19/06/2013 06:58, Mandy Chung wrote: Alan, Chris, Can you review the fix for [1] 8014925: Disable sun.reflect.Reflection.getCallerClass(int) with a temporary switch to re-enable it [2] 8016814: sun.reflect.Reflection.getCallerClass returns the wrong stack frame Webrev at: http://cr.ope

Re: >=2 reviewers imply at least two have "reviewer" role?

On 19/06/2013 10:52, Dalibor Topic wrote: : They should both have the Reviewer role. Would changing "At least two reviewers are required for phase 2." in http://openjdk.java.net/projects/jdk7u/phase2/phase2-approval-template.html to "At least two reviewers, from the set of Reviewers listed on t

>=2 reviewers imply at least two have "reviewer" role?

On 19/06/2013 09:03, Seán Coffey wrote: Leonid, Phase 2 requires two reviewers. Can you specify who has reviewed ? Nothing to do with this Leonid's request but does "two reviewers" imply that both have "reviewer" role (or is one with "reviewer" role okay)? It would be good to make this clear o

Re: [7u] Request for approve for CR 8015976 OpenJDK part of bug JDK-8015812 [TEST_BUG] Tests have conflicting test descriptions

On 06/06/2013 16:02, Konstantin Shefov wrote: There are a lot of test pairs (.java + .html) in JDK repo where both files contain jtreg tags, although only one file contains @test tag. I think it is not necessary to remove other tags, because they show that the given file is a part of the given t

Re: [7u] Request for approve for CR 8015976 OpenJDK part of bug JDK-8015812 [TEST_BUG] Tests have conflicting test descriptions

On 06/06/2013 14:13, Konstantin Shefov wrote: Hello, Please approve a direct backport from jdk 8 fix for the issue: 8015976 OpenJDK part of bug JDK-8015812 [TEST_BUG] Tests have conflicting test descriptions Test bug fix http://bugs.sun.com/view_bug.do?bug_id=8015976 The webrev is:http://c

Re: [7u] Request for approve for CR 8015976 OpenJDK part of bug JDK-8015812 [TEST_BUG] Tests have conflicting test descriptions

On 06/06/2013 14:26, Konstantin Shefov wrote: No, it is not necessary Maybe I'm missing something but when you remove the @test then aren't the rest of the tags orphaned? -Alan.

Re: [7u40] Resolve ambiguity in OCSPChecker & CrlRevocationChecker

On 23/05/2013 18:12, Andrew Hughes wrote: : They aren't. It's a 7 source file conflicting with the class from 6 which is on the bootclasspath. So any issue with the bootclasspath specified to javac? (I'm not objecting to the proposed change, rather I think I probably need to see the javac comm

Re: [7u40] Resolve ambiguity in OCSPChecker & CrlRevocationChecker

On 22/05/2013 19:25, Andrew Hughes wrote: Webrev: http://cr.openjdk.java.net/~andrew/7u/webrev/ There's an ambiguity that applies when building OpenJDK 7 with OpenJDK 6 (and hence I haven't posted this for 8 as it can't be built with 6). OpenJDK 6 has a class sun.security.provider.certpath.Cer

Re: 7u40 Request for approval for CR 8011653 Upgrade to JAXP 1.5

On 10/05/2013 08:10, huizhe wang wrote: Yes. The code detects the JDK version and set the default differently. Joe Yes, I just wanted to get that highlighted as the highly incompatible change in behavior in 8 would not be appropriate for jdk7u. -Alan

Re: 7u40 Request for approval for CR 8011653 Upgrade to JAXP 1.5

Joe - aren't the defaults for jdk7u different? On 09/05/2013 23:32, huizhe wang wrote: Hello, I'd like to backport the following changes from JDK8 to 7u40: 8011653 - Upgrade JDK8 to JAXP 1.5 http://bugs.sun.com/view_bug.do?bug_id=8011653 The JDK8 changeset is at http://hg.openjdk.j

Re: [7u] Request for approval for 8005527: [TEST_BUG] console.sh failed Automatically with exit code 1

On 22/04/2013 12:04, Weijun Wang wrote: > Note that adding @ignore will only cause it to be ignored if you > run with -ignore:quiet. Oh, I didn't know that. There are some other tests with the @ignore tag, guess I should remove all of them. The default is that @ignore tests are flagged as erro

Re: [7u] Request for approval for 8005527: [TEST_BUG] console.sh failed Automatically with exit code 1

On 22/04/2013 10:30, Weijun Wang wrote: : Yes, there are people (Everygreen here in Beijing) running it without -a and see a failure. I don't want to remove the test. On one hand, I will still directly run it myself if there are related code changes. On the other hand, it will be nice to wr

Re: [7u] Request for approval for 8005527: [TEST_BUG] console.sh failed Automatically with exit code 1

On 22/04/2013 04:45, Weijun Wang wrote: : The fix is already included in jdk8 as: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22a27dfd0510 Reviewed-by: xuelei This was pushed to jdk8 a few hours ago and it's not clear why it is needed. Is the issue that people are running the tests withou

Re: [7u-dev] Request for approval and review request for 8012572: Exclude sun/tools/jmap/Basic.sh for short term

It make sense to exclude it until the issue is resolved, especially Windows where the communication to the target VM is a pipe and the tool can hang waiting even when the target VM has crashed. -Alan. On 18/04/2013 10:51, Seán Coffey wrote: The sun/tools/jmap/Basic.sh test is failing since

Re: [7u14] Request for approval for bulk integration of hs24-b40

On 15/04/2013 09:49, Volker Simonis wrote: So where is 7u14 beast and why doesn't it become publicly visible? After all it's a 'feature-release' so there should be no reason to hide it behind the fences, right? Regards, Volker I think this is just a numbering thing. The changes accumulating in

Re: CFV: New JDK 7 Updates Project Committer: Edvard Wendelin

Vote: yes

Re: [7u-dev] Request for multiple fix approval

On 22/02/2013 01:51, Rob McKenna wrote: Figure I'd send one mail for 3 test issues. (and as far as "bulk" goes, 3 doesn't seem to cut it) : 8005566: (fs) test/java/nio/file/Files/Misc.java failing (sol) http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ca2e39a110d This one isn't a test issue, it's a

Re: [7u] review and approval request for 8007515: update RMI tests on ProblemList.txt

On 11/02/2013 23:02, Stuart Marks wrote: I thought about dealing with TEST.ROOT in a separate bug but that just seems like busy-work. Updating the problem list is at least as much about making sure that the testing configurations between jdk8 and jdk7u are brought closer together as much as i

Re: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap

On 09/02/2013 23:31, Martin Buchholz wrote: On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz wrote: It looks to me like Collections.reverseOrder no longer deserializes to the same object. It also looks like the definition for that in Collections.java hasn't changed recently. So I suspect that

Re: [7u] review and approval request for 8007515: update RMI tests on ProblemList.txt

On 09/02/2013 00:51, Stuart Marks wrote: Hi all, A simple request for code review *and* integration approval for the following bugfix: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007515 http://cr.openjdk.java.net/~smarks/reviews/8007515/webrev.0/ Now that all the RMI test fi

Re: [7u] Request for review and approval/backport: 7183373: URLClassloader.close() does not close JAR files loaded via getResource()

This is an area where issues (performance for example) have tended to show up with real world usage. For that reason, I wonder if it would be safer to wait a bit (a few weeks away) to see if issues emerge. At it stands, the jdk8 fix hasn't even got to a promoted build so it probably hasn't h

Re: Request for review: 8006757: Refactor Socket and File I/O tracing

On 24/01/2013 13:37, Claes Redestad wrote: Hi all, this is a refactoring of the I/O trace instrumentation that's going into JDK 7u14. The fix is only applicable to jdk7 since the corresponding code does not yet exist in jdk8. Bug: 8006757: Refactor Socket and File I/O tracing http://bugs.su

Re: a socket impl question?

On 13/01/2013 09:46, Sand Stone wrote: 2. Or provide a code path to allow framework builders to set OS specific custom socket options? This could be a general mechanism without JDK changes. The support that is there is intended to allow implementations support socket options beyond those de

Re: a socket impl question?

On 13/01/2013 08:22, Chris Hegarty wrote: : More generally, is there a general way to pass a non StandardSocketOptions option the down to the socket fd without having to go through the JNI path on Windows? Not that I am aware of. Just to add to Chris's comment. You can develop your own Sele

Re: [7u12] request for approval, 7109274, Restrict the use of certificates with RSA keys less than 1024 bits

On 28/12/2012 22:38, Phil Race wrote: In another "thread" there was a reference to a site which showed zero out of the top 178,000 sites using the weak key : https://www.trustworthyinternet.org/ssl-pulse/ -phil. That's useful to know although this is still a significant change that needs bake t

Re: Improving performance and reducing object allocations of java.util.UUID to/from string

Steven, You should bring your patch to core-libs-dev to discuss. -Alan On 28/12/2012 23:34, Steven Schlansker wrote: Hello JDK developers, My company uses UUIDs throughout our software. We recently identified that the java.util.UUID implementations of fromString and toString are horridly i

Re: [7u12] request for approval, 7109274, Restrict the use of certificates with RSA keys less than 1024 bits

On 28/12/2012 09:41, Xuelei Fan wrote: Hi, This is a request to backport a JDK 8 fix into JDK 7u12: 7109274: Restrict the use of certificates with RSA keys less than 1024 bits Do you have any data to know if RSA keys < 1024 bits are used much these days? On the surface it seems risky to

Re: Request of approval for 7132889

On 09/11/2012 20:54, Seán Coffey wrote: Doesn't look like Alan has a problem with this being backported to jdk7u-dev. I don't have any objection, just a bit surprised that anyone is actually running into it as it's an issue that has been thee for 10 years without any reports. -Alan

Re: New to forum - how do I track code changes

On 07/11/2012 15:17, Gordon, Bruce wrote: I am new to the forum - can anyone tell me how to find which code changes relate to a specific bug ? In particular I would like to see the code change for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193966 Thanks! That bug appears to be in the

Re: Request of approval for 7132889

On 07/11/2012 12:05, jayashree viswanathan wrote: Hi Alan , Thanks for your quick response . We are having the problem in JDK7U as well . Do you mean that 7192849 was already fixed in JDK7U ? It depends on which problem you are running into. The main issue in 7192849 has been addressed by 6

Re: Request of approval for 7132889

On 06/11/2012 11:44, jayashree viswanathan wrote: Hi All, This is a request for approval to push the fix for 7132889 from JDK 8 to JDK7u . Is this issue really causing a problem with jdk7u? I ask because the main issue that was the original bug report has already been fixed in 7u and 7132889

Re: Request for approval: 6610897: New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathSeparator

On 02/11/2012 02:55, Deven You wrote: Hi Alan, Thanks very much for your correction. I have updated the webre[1] according to your comments. Please review it. [1] http://cr.openjdk.java.net/~youdwei/ojdk-505/7u/webrev.02/ It look

Re: Request for approval: 6610897: New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathSeparator

On 01/11/2012 06:20, Deven You wrote: Hi All, This is a request for approval to push the fix of 6610897 from jdk8 to jdk7u, could anyone take a look? Link to the bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6610897 Webrev for jdk7u: http://cr.openjdk.java.net/~youdwei/ojdk-505

Re: Request for approval: 7014860: Socket.getInputStream().available() not clear for shutdown input

On 24/10/2012 10:27, Sean Chou wrote: Hello, This is request for approval to push the fix of 7014860 to jdk7u, please take a look. Link to the bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7014860 Changeset in jdk8: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5a28b040714 The we

Re: Approval Request: 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X

On 23/10/2012 15:02, Rob McKenna wrote: Hi folks, Requesting approval for the above. Changes are identical to 8: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84cd98a5641c Cheers, -Rob Thanks for taking this one. Once it's in a 7u build then would you sending mail to the folks at macosx-por

Re: Request For Approval: 7172826: (se) Selector based on the Solaris event port mechanism

On 18/10/2012 20:27, Rob McKenna wrote: : On 26/09/2012 23:43, Rob McKenna wrote: Hi folks, Looking for approval for: http://cr.openjdk.java.net/~robm/7172826/webrev.02/ To go into 7u-dev. Its a straight backport of the EventPortSelectorProvider in jdk8: http://hg.openjdk.java.net/jdk8/t

Re: [7u-dev] Request for approval: 8001124: jdk7u ProblemList.txt updates (10/2012)

On 18/10/2012 19:39, Seán Coffey wrote: Alan, thanks for looking into this. It's something many of us have had on our plates for a while now. The underlying testcases still need addressing and that's something I'm hoping to work on with team colleagues soon (for core libs area at least) App

hg: jdk7u/jdk7u-dev/jdk: 8001124: jdk7u ProblemList.txt updates (10/2012)

Changeset: eba28a14b777 Author:alanb Date: 2012-10-18 19:58 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/eba28a14b777 8001124: jdk7u ProblemList.txt updates (10/2012) Reviewed-by: coffeys, chegar ! test/ProblemList.txt

[7u-dev] Request for approval: 8001124: jdk7u ProblemList.txt updates (10/2012)

I don't work in jdk7u-dev too often but today I had to build it and I'm seeing a lot of test failures. The test are failures are mostly because the exclude list (jdk/test/ProblemList.txt) is not being maintained in jdk7u and also because a lot of test fixes from jdk8 have not been back-ported

Re: [7u10] Request for approval: 7193463: Terminator.setup should ignore IAE when registering signal handlers

On 25/09/2012 13:25, Seán Coffey wrote: Is this a behavioural change for an update release ? The jdk8 review thread suggests that it isn't but I'd like confirmation from original reviewer first (Alan and David) If either of them are ok, consider this approved for jdk7u-dev. I'll look after bu

Re: [7u12] Request for review & approval for CR 7199637: add serialization tests to jdk7u problem list for macosx

On 20/09/2012 19:44, Seán Coffey wrote: You can mark me as a reviewer if you wish, but you'll still need someone else with jdk7u reviewer status! Looks fine to me too. -Alan

Re: [7u10] Request for approval for CR 7188852 - Move implementation of De/Inflater.getBytesRead/Writtten() to java from native

On 19/09/2012 20:01, Seán Coffey wrote: On 19/09/2012 18:22, Andrew Hughes wrote: Sure, http://cr.openjdk.java.net/~andrew/zlib/webrev.01/ is the combined webrev. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/35e024c6a62c is the original jdk8 changeset for 7110151. Thanks - let's get approva

Re: Request for approval:7166048: Remove the embeded epoll data structure

On 19/09/2012 15:13, Seán Coffey wrote: I'm always cautious of header file changes in update releases. I believe 2.6 kernel version is minimum in JDK7 also. cc'ing Alan here, if he's ok with the port, then consider this approved for jdk7u-dev! No objection from me, it's just a clean-up that sh

Re: [7u10] Request for approval: 7112670: Inet4AddressImpl should use getaddrinfo/getnameinfo

On 19/09/2012 08:07, Shi Jun Zhang wrote: : I think the bug Alan mentioned is just a typo by Mac porting but not because of using getnameinfo and getaddrinfo. The bug I referenced stemmed from the Mac port inadvertently changing the code to use getnameinfo in 7u4. This resulted in a behavioral

Re: [7u10] Request for approval: 7114558: Inet4AddressImpl should use memset (rather than bzero) and NI_MAXHOST (rather than MAXHOSTNAMELEN)

Sean - this one is relative to 7112670 which is one of the changes that we have concerns about. -Alan. On 18/09/2012 19:09, Seán Coffey wrote: Approved for jdk7u-dev. Note that this most likely means the fix will end up in 7u12. If there's a strong justification for 7u10 inclusion, let me kn

Re: [7u10] Request for approval: 7166055: Javadoc for WeakHashMap contains misleading advice

On 17/09/2012 11:01, Artem Ananiev wrote: JavaDoc changes, even trivial corrections and clarifications, are potential compatibility issues. Previously unverifiable statement can become verifiable, and vice versa. We don't (can't!) change compatibility tests in update releases, therefore we ca

Re: [7u10] Request for approval: 7112670: Inet4AddressImpl should use getaddrinfo/getnameinfo

For the record, I have concerns about back-porting this to 7u. The reason is that switching to getnameinfo and getaddrinfo can result in subtle behavioral changes that cause problems for applications and developers. A recent one in this area was: http://bugs.sun.com/view_bug.do?bug_id=716668

Re: [7u communication] Proposal 7u10 stabilisation forests

On 13/09/2012 15:43, Edvard Wendelin wrote: Hi, I'd like to propose the following stabilisation forests for 7u10 to be created on September 19th: hg.openjdk.java.net/jdk7u/jdk7u10 based on hg.openjdk.java.net/jdk7u/jdk7u/ tag jdk7u10-b08 hg.openjdk.java.net/jdk7u/jdk7u10-dev based on hg.openj

Re: [7u10] Request for approval: 6183404: Many eudc characters are incorrectly mapped in MS936 and GBK converter

Edvard/Sean - would it be possible to hold off approving this one until you hear from Sherman Shen on this one? Sherman is the original author of these changes. I was the reviewer for this change but I have concerns about changing these mappings in an update release (but Sherman is the expert

Re: Request for approval: 7023713: HttpCookie.domainMatches("hostname.local", "hostname") should return true

Edvard/Sean - would it be possible to hold off approving this one until you hear from the original spsonor (Chris in this case) or someone in the networking area? This one brings a behavioral change and may not be a good candidate to back-port without further discussion. -Alan. On 14/09/201

Re: Request for approval: 7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx]

Also cc'ing Jason Greene as he contributed this fix (and has already tested it with 7u on Mac). On 06/09/2012 15:09, Seán Coffey wrote: I'd like to backport this changeset to the jdk7u release. Changeset applies without issue. Build & tests currently running and won't push until all looks

Re: Request for approval: 7190219 (bf) CharBuffer.put(String, int, int) modifies position even if BufferOverflowException thrown

On 04/09/2012 13:55, Seán Coffey wrote: Hey Neil, I wouldn't regard this as a risky fix and don't see a problem with it going into jdk7u-dev now (before phase2 approval process begins in mid September) It also benefits from having a unit testcase. Testing (jtreg tests) in the jdk8/tl repos wo

Re: Request for approval: 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

On 04/09/2012 03:23, Sean Chou wrote: Thank you ! On Mon, Sep 3, 2012 at 8:04 PM, Seán Coffey wrote: Good point on it having to be a race condition. OK - sounds reasonable for backport then. Sean - I've created a bug record for you. Will update when I see your push. regards, Sean. Out of c

Re: Request for approval: 7152519, 7159041, 7153343 Remove including of non-POSIX header link.h

On 03/09/2012 09:09, Jonathan Lu wrote: Hi all, Here's a request of porting the fix 7152519, 7159041, 7153343 to JDK7, could you please help to review? All the three patches serves for the same purpose of removing including of non-POSIX header link.h, so I suggest to contribute them in one

Re: Should back-ports cc the mailing lists for the area? (was Re: [7u8] Request for approval: 7113017: Use POSIX compliant include file headers in sun/awt/medialib/mlib_types.h)

On 08/08/2012 17:07, Dalibor Topic wrote: : I agree. When no links exist, we have to rely on having the right people in the right place at the right time to make the necessary, missing connections. So it seems that we're all in agreement of adapting the request for approval process slightly to in

Re: Should back-ports cc the mailing lists for the area? (was Re: [7u8] Request for approval: 7113017: Use POSIX compliant include file headers in sun/awt/medialib/mlib_types.h)

On 07/08/2012 13:51, Edvard Wendelin wrote: Hi, When I've been working on backports that I'm not the original author of, I have always asked the engineer if the fix is suitable to backport or not. Instead of having to CC the entire group I'd like to suggest the following alternative rule: If

Re: Should back-ports cc the mailing lists for the area? (was Re: [7u8] Request for approval: 7113017: Use POSIX compliant include file headers in sun/awt/medialib/mlib_types.h)

On 06/08/2012 03:00, David Holmes wrote: I raised the issue of bake-time previously: http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-September/000307.html See in particular Edvard's response: http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-September/000315.html I've no issue

Re: Request for approval: 7142596 RMI JPRT tests are failing

On 06/08/2012 20:14, Darryl Mocek wrote: Hello all, please review this backport the fix of bug 7142596 for JDK7. Bug:http://bugs.sun.com/view_bug.do?bug_id=7142596 This change includes 3 changesets from JDK8: http://hg.openjdk.java.net/jdk8

Should back-ports cc the mailing lists for the area? (was Re: [7u8] Request for approval: 7113017: Use POSIX compliant include file headers in sun/awt/medialib/mlib_types.h)

Phil's comment about the back-port only being discussed on jdk7u-dev is probably worth further discussion. One thing about jdk7u is that the barrier to get changes in is very low. On one hand this is is wonderful as it means we can get fixes into jdk7u in a timely manner and also keep the co

Re: Request for Review: AESCrypt.init performance JDK change

On 17/07/2012 16:10, Deneau, Tom wrote: Alan -- Can you tell me the procedure I should follow? I have submitted hotspot webrevs before but not JDK webrevs? -- Tom You'll need to get a sponsor from the security area (you've cc'ed security-dev so that's the right list). The initial target shou

Re: Request for Review: AESCrypt.init performance JDK change

On 16/07/2012 21:08, Deneau, Tom wrote: Please review the following webrev which improves performance for the com/sun/crypto/provider when the algorithm is AES for some kinds of Cipher usage patterns. http://cr.openjdk.java.net/~tdeneau/aescrypt-init-performance/webrev.01/ I do not have a bug n

Re: pack200 --repack not working in Java 1.7 or Java 1.8 on Mac OS X

On 14/07/2012 16:20, Stephen Bannasch wrote: Normally I'd reference the url to the bug report when committing the change in my project. However since it the bug is not visible yet I'll just refer to the bug-id. That is of course a bit less reliable since I can't confirm that the bug-id is c

Re: pack200 --repack not working in Java 1.7 or Java 1.8 on Mac OS X

On 14/07/2012 15:34, Stephen Bannasch wrote: Where is the bug you created listed? I can't see it here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184145 Give it day or so (bugs.sun.com is not a real-time view of the bug database). : That's great. I've confirmed the work-around w

Re: pack200 --repack not working in Java 1.7 or Java 1.8 on Mac OS X

On 14/07/2012 04:35, Stephen Bannasch wrote: Running pack200 --repack fails with a NullPointerException in Java 1.7 or Java 1.8 Mac OS X 10.7.4 Exception in thread "main" java.lang.NullPointerException at com.sun.java.util.jar.pack.Driver.createTempFile(Driver.java:389) at com.sun.java.

Re: regression: jdk1.7.0_04 java.net.InetAddress.getLocalHost().getHostName() return FQHN

gards, Wolfgang. On May 9, 2012, at 5:02 AM, Alan Bateman wrote: On 09/05/2012 10:15, Wolfgang Hoschek wrote: [7u6] In jdk1.7.0_04 GA java.net.InetAddress.getLocalHost().getHostName() return the fully qualified host name (e.g. "ip-10-172-17-93.us-west-1.compute.internal") instead of

Re: [7u6] Request for approval / patch for review : 7178548 : Hashtable ignores threshold default

On 20/06/2012 23:16, Mike Duigou wrote: Hello all; This is a small patch for review for 7u6 to correct a problem with the handling of the alternative hashing threshold. http://cr.openjdk.java.net/~mduigou/7178548/0/webrev/ The patch also includes a suggested documentation fix and an minor cha

  1   2   >