Re: RFR: 8170769 Provide a simple hexdump facility for binary data

ll those who provided review comments. > On 12 Dec 2018, at 12:32, Vincent Ryan wrote: > > Thanks for your proposal. > Comments below. > >> On 12 Dec 2018, at 02:35, Stuart Marks wrote: >> >> >> >> On 12/11/18 1:21 PM, Vincent Ryan wrote: >>>

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Thanks for your proposal. Comments below. > On 12 Dec 2018, at 02:35, Stuart Marks wrote: > > > > On 12/11/18 1:21 PM, Vincent Ryan wrote: >> My preference is for PrintStream rather than Writer, for the same reason as >> Roger: it’s more convenient >> f

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

a/util/HexFormat.html <http://cr.openjdk.java.net/~vinnie/8170769/javadoc.08/api/java.base/java/util/HexFormat.html> > On 11 Dec 2018, at 13:04, Alan Bateman wrote: > > On 08/12/2018 01:18, Vincent Ryan wrote: >> Here’s the latest version that addresses all the current open

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

> > Ho Vincent, > > On 12/11/2018 11:34 AM, Vincent Ryan wrote: >> Responses in-line. >> >>> >>>> Its really nice/necessary that examples can be copy/pasted and compile. >>>>> >>>>> >>>>> - dumpAsStream(

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

> On 11 Dec 2018, at 02:11, Stuart Marks wrote: > > On 12/7/18 10:22 AM, Vincent Ryan wrote: >>> I'm not convinced that the overloads that send output to an OutputStream >>> pull their weight. They basically wrap the OutputStream in a PrintStream, >>> whic

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Responses in-line. > On 10 Dec 2018, at 21:38, Roger Riggs wrote: > > Hi Vincent, > > On 12/10/2018 03:59 PM, Vincent Ryan wrote: >> Comments in-line. >> Thanks. >> >>> On 10 Dec 2018, at 16:59, Roger Riggs >> <mailto:roger.ri...@oracle.co

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

utputStream) - I don't think the example is correct, there is > no reference > to a stream, only the PrintStream::println method, which is not static. The code is just illustrative. Real values would have to be supplied for the input bytes and the chosen print method on the

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

t.html <http://cr.openjdk.java.net/~vinnie/8170769/javadoc.07/api/java.base/java/util/HexFormat.html> CSR: https://bugs.openjdk.java.net/browse/CCC-8170769 <https://bugs.openjdk.java.net/browse/CCC-8170769> > On 7 Dec 2018, at 19:51, Vincent Ryan wrote: > > Even shorter. I’ll

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

&& ch <= 'f') { >> return ch - 'a' + 10; >> } >> return -1; >> } >> >> with >> >> private static int hexToBinary(char ch) { >> return ch <= 'f' ? staticPrecomputedArray[ch

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

h && ch <= 'f') { > return ch - 'a' + 10; > } > return -1; > } > > with > > private static int hexToBinary(char ch) { > return ch <= 'f' ? staticPrecomputedArray[ch] : -1; > } > > where int[

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Thanks for your review Stuart. Comments below. > On 6 Dec 2018, at 02:18, Stuart Marks wrote: > > Hi Vinnie, > > Roger Riggs wrote: >>> The 'forEachOrdered' should not be necessary and may raise questions about >>> why. >>> if there's no good reason, use 'forEach’. > > Using forEachOrdered()

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

" ".repeat(8); > final StringBuilder sb = new StringBuilder(16 * 5); > sb.append(indent); > > System.out.print("byte[] bytes = {\n"); > try (ByteArrayInputStream is = new ByteArrayInputStream(b)) { > dumpAsStream(is, 16, (o, c, s, e) -> { >

RFR: 8170769 Provide a simple hexdump facility for binary data

Hello, Please review this proposal for a new API to conveniently generate and display binary data using hexadecimal string representation. It supports both bulk and stream operations and it can also generate the well-known hexdump format [1]. This latest revision addresses review comments pro

Re: [11] RFR: 8170769 Provide a simple hexdump facility for binary data

> On 10 May 2018, at 01:08, Weijun Wang wrote: > > > >> On May 10, 2018, at 6:49 AM, Vincent Ryan wrote: >> >>> >>> - As Max observes, being able to supply the delimiters might be a good >>> addition. (I'm thinking IP addresse

Re: [11] RFR: 8170769 Provide a simple hexdump facility for binary data

dump method is both powerful and simple enough to create > 2) above, I'll be happy. Otherwise, I can live with > toHexString().replaceAll("(..)(?=.)", "$1:”). How about adding another toHexString method that takes a delimiter character? > > Thanks > Max > >&

Re: [11] RFR: 8170769 Provide a simple hexdump facility for binary data

f >> >> 1. The existing sun.security.HexDumpEncoder format, when I want to dump a >> lot of bytes as a block >> 2. "00:11:22:33:AA:BB:CC" which fits in one line and also easy to read, when >> I want inline debugging output >> >> If the customizable du

[11] RFR: 8170769 Provide a simple hexdump facility for binary data

Hello, Please review this proposal for a new API to conveniently generate and display binary data using hex string representation. It supports both bulk and stream operations and it can also generate the well-known hexdump format [1]. Thanks Bug: https://bugs.openjdk.java.net/browse/JDK-81707

Re: Charsets for hex/base64

FYI here’s the javadoc for a draft of the Hex API that Alan mentioned below: http://cr.openjdk.java.net/~vinnie/8170769/javadoc.05/api/java.base/java/util/Hex.html Thanks. > On 2 May 2018, at 10:55, Jonas Konrad wrote: > > I did not know about the old HexDumpEncoder. It extends an internal cla

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

Unfortunately this feature has arrived a little too late so I’m withdrawing it from consideration for JDK 9. Thanks again to those who took time to review it. > On 10 Dec 2016, at 01:02, Vincent Ryan wrote: > > Thanks to those who provided review comments. > > I have incor

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

Thanks to those who provided review comments. I have incorporated most of them and updated the webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.01/ The main changes are to tighten up the javadoc spec and to add three additional methods to support byte array ranges. The total number

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

Some ByteBuffers can be converted to a byte[] without the penalty of a copy operation. If performance becomes an issue then we can re-visit supporting ByteBuffer. > > Comments below. > > Paul. > >> On 7 Dec 2016, at 08:32, Vincent Ryan wrote: >> >> A hexdum

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

Thanks for your review comments Alan. Responses below. > On 8 Dec 2016, at 19:44, Alan Bateman wrote: > > On 07/12/2016 16:32, Vincent Ryan wrote: > >> A hexdump facility has been available for many, many years via an >> unsupported class: sun.misc.HexDumpEncoder. &g

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

> On 8 Dec 2016, at 12:10, Vincent Ryan wrote: > > >> On 8 Dec 2016, at 07:22, David Holmes wrote: >> >> On 8/12/2016 2:32 AM, Vincent Ryan wrote: >>> A hexdump facility has been available for many, many years via an >>> unsupported class: sun

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

> On 8 Dec 2016, at 07:22, David Holmes wrote: > > On 8/12/2016 2:32 AM, Vincent Ryan wrote: >> A hexdump facility has been available for many, many years via an >> unsupported class: sun.misc.HexDumpEncoder. >> Although that class was always unsupported, it

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

ching one for dumpToStream ? > > -Ulf > > Am 07.12.2016 um 17:32 schrieb Vincent Ryan: >> A hexdump facility has been available for many, many years via an >> unsupported class: sun.misc.HexDumpEncoder. >> Although that class was always unsupported, it was st

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

> > [1] http://openjdk.java.net/projects/jdk9/fc-extension-process > > On Wed, Dec 7, 2016 at 5:32 PM, Vincent Ryan > wrote: >> A hexdump facility has been available for many, many years via an >> unsupported class: sun.misc.HexDumpEncoder. >> Although that cl

[9] RFR 8170769: Provide a simple hexdump facility for binary data

A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I’m proposing a very simple replacement in a new and supported class: java.u

Re: Process to add some default methods to javax.naming.Context?

ote: > > On Fri, Oct 14, 2016 at 7:19 AM Vincent Ryan <mailto:vincent.x.r...@oracle.com>> wrote: > The problem of having to cast the result of Context.lookup > <http://download.java.net/java/jdk9/docs/api/javax/naming/Context.html#lookup-javax.naming.Name-> > can b

Re: Process to add some default methods to javax.naming.Context?

Hello Laird, The problem of having to cast the result of Context.lookup can be solved using an existing method: InitialContext.doLookup

Re: RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

IIRC pausing the receiver was introduced to prevent an LDAP client (with limited memory) from being overwhelmed by server results and having no opportunity to transmit an abandon request. The 80% value was chosen to balance maximising queue capacity against the risk of an OOME. If that behaviour

Re: Review request for JDK-8151065 : Typo in javax.naming.CompoundName

ly. > So, please let me know your suggestion. > > Thank you. > > Kind regards, > Abhijit > > > -Original Message- > From: Pavel Rappo > Sent: Friday, March 11, 2016 2:40 PM > To: Abhijit Roy > Cc: core-libs-dev; Vincent Ryan > Subject: Re: Revi

Re: 8141370: com/sun/jndi/ldap/LdapTimeoutTest.java failed intermittently

This change to restructure the test looks fine. Thanks. > On 8 Dec 2015, at 16:11, Rob McKenna wrote: > > Thanks, just spotted that myself after attempting to run it in a loop via > jtreg. (in case jtreg is somehow involved in causing the intermittent > failure) Will be corrected pre-push. >

Re: RFR: 8132455 - com/sun/jndi/ldap/LdapTimeoutTest.java fails at handleNamingException

That looks fine for now. Thanks. > On 11 Nov 2015, at 15:11, Rob McKenna wrote: > > So unfortunately this isn't a real fix for this failing test. (intermittent, > certain platforms only) However since I have enough information to > investigate this problem separately I'd like to silence this s

Re: RFR: 8129957 - Deadlock in JNDI LDAP implementation when closing the LDAP context

Your proposed fix looks fine Rob. Thanks. > On 14 Sep 2015, at 16:25, Rob McKenna wrote: > > Hi folks, > > So on further investigation it looks like we could get away with reducing the > amount of locking in LdapClient. Here is a proposed fix followed by a > description: > > http://cr.openj

Re: RFR (XS) 8074761: Empty optional parameters of LDAP query are not interpreted as empty

Your fix looks good to me. Thanks for contributing the patch. > On 25 Mar 2015, at 14:47, Stanislav Baiduzhyi > wrote: > > On Tuesday 10 March 2015 17:18:06 Stanislav Baiduzhyi wrote: >> Hi All, >> >> Please review the patch for LdapURL. Patch fixes the parsing of query part >> of LDAP URL, l

Re: RFR: 8065238 - javax.naming.NamingException after upgrade to JDK 8

Changes look fine to me Rob. Thanks. On 5 Dec 2014, at 05:17, Rob McKenna wrote: > Just updated the test to workaround a seemingly unrelated platform specific > issue. (that only manifests on older kernels) > > http://cr.openjdk.java.net/~robm/8065238/webrev.02/ > >-Rob > > On 03/12/14

Re: RFR JDK-8059311: com/sun/jndi/ldap/LdapTimeoutTest.java fails with exit_code == 0

All looks good. Thanks. On 7 Nov 2014, at 12:14, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8059311? > > http://cr.openjdk.java.net/~prappo/8059311/webrev.00/ > > > It looks like one of the

Re: RFR JDK-8054158: Fix typos in JNDI-related packages

Thanks for fixing those typso. On 1 Aug 2014, at 16:50, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8054158? > > http://cr.openjdk.java.net/~prappo/8054158/webrev.00/ > > -Pavel

Re: RFR JDK-8051991: Flatten VersionHelper hierarchies

Look fine Pavel. Thanks. On 25 Jul 2014, at 13:59, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8051991? > > http://cr.openjdk.java.net/~prappo/8051991/webrev.00/ > > -Pavel

Re: RFR JDK-8048175: Remove redundant use of reflection on core classes from JNDI

The LDAP changes look fine to me. Thanks. On 15 Jul 2014, at 15:07, Mark Sheppard wrote: > Hi Pavel, > the changes look ok I've run some relevant jck tests (naming > management rmi) and the CORBA regression suite > for the changeset, with no perceptible issues > > regards > Mark > > On

Re: RFR JDK-8049884: Reduce possible timing noise in com/sun/jndi/ldap/LdapTimeoutTest.java

This change looks fine Pavel and eliminates another intermittent test failure. Thanks. On 11 Jul 2014, at 14:59, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8049884? > > http://cr.openjdk.java.net/~prappo/8049884/webrev.00/ > > Thanks > -Pavel

Re: [9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded

There is precedence for revealing the full pathname only when a security manager is not running. Would that be acceptable? On 20 Jun 2014, at 13:21, Vincent Ryan wrote: > Hello Aaron, > > I considered using your testcase that manually generates the necessary > malformed JAR &g

Re: [9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded

Hello Aaron, I considered using your testcase that manually generates the necessary malformed JAR but as there was a suitable signed JAR already in the test suite I decided to re-use that. I think it makes sense to re-work the test as a Java program. Unfortunately I’ll be on vacation from toda

Re: [9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded

I shortened the output to display only the JAR filename to avoid leaking filesystem information. I’ve updated the webrev in-place. Thanks. On 19 Jun 2014, at 17:59, Vincent Ryan wrote: > Please review the following simple changeset to identify the offending JAR > file following a sig

[9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded

Please review the following simple changeset to identify the offending JAR file following a signature verification error. Previously, only the offending entry in the JAR was identified. This helps during troubleshooting when several JAR files being processed. The request was originally submitted

Re: RFR JDK-8047062: Improve diagnostic output in com/sun/jndi/ldap/LdapTimeoutTest.java

Looks fine Pavel. On 17 Jun 2014, at 14:06, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8047062? > > http://cr.openjdk.java.net/~prappo/8047062/webrev.00/ > > Thanks > -Pavel

Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation

, if you want. > > Jeremy > > > On Wed, May 28, 2014 at 8:52 AM, Vincent Ryan > wrote: > I’ll begin reviewing your changeset and get back to you. > Thanks. > > On 28 May 2014, at 16:28, Jeremy Manson wrote: > >> Ah, okay. Thanks, Iris. I should al

Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation

mitter > > -Original Message- > From: Jeremy Manson [mailto:jeremyman...@google.com] > Sent: Tuesday, May 27, 2014 2:19 PM > To: Vincent Ryan > Cc: OpenJDK; core-libs-dev > Subject: Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key > Generation >

Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation

Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor your fix if you wish. On 27 May 2014, at 21:09, Jeremy Manson wrote: > Just like the title says - every time you generate a new private key, you > leak a little memory. Webrev here: > > http://cr.openjdk.java.net/~jmanson/80

Re: RFR - 8041451: com.sun.jndi.ldap.Connection:ReadTimeout should abandon ldap request

That fix looks fine. Thanks. On 23 May 2014, at 18:08, Rob McKenna wrote: > Hi folks, > > Very simple fix to ensure that a slow server isn't left waiting around for a > request we have already given up on. > > http://cr.openjdk.java.net/~robm/8041451/webrev.01/ > >-Rob >

Re: RFR - 8042857: 14 stuck threads waiting for notification on LDAPRequest

Fix looks fine Rob. Thanks. On 16 May 2014, at 17:00, Rob McKenna wrote: > Hi folks, > > A simple fix to eliminate a possible infinite loop when an Ldap Connection > cannot contact the server. > > http://cr.openjdk.java.net/~robm/8042857/webrev.01/ > >-Rob >

Re: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

ge and I'll file a CCC to track > this. Yes. I think that’s the right approach as the compatibility risk is low. > > Mandy > > On 3/21/2014 2:23 AM, Vincent Ryan wrote: >> You’re right but we’ve never received a report of any charset interop. >> issues.

Re: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

You’re right but we’ve never received a report of any charset interop. issues. Probably such a scenario has never been encountered by customers. On 21 Mar 2014, at 05:54, Xueming Shen wrote: > Obj.java:#482 >It appears sun.misc.BASE64Decoder.decodeBuffer(String) uses String's > deprecated

Re: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

OK. Thanks. On 19 Mar 2014, at 19:06, Mandy Chung wrote: > On 3/19/2014 12:03 PM, Vincent Ryan wrote: >> Fix looks fine. You just need to update the import statements in Obj.java > > Fixed. Not sure how it's missed in the webrev :) > > thanks > Mandy > >&g

Re: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

Fix looks fine. You just need to update the import statements in Obj.java On 19 Mar 2014, at 18:37, Mandy Chung wrote: > https://bugs.openjdk.java.net/browse/JDK-8035807 > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ > > This patch converts the last 2 refe

Re: RFR [6968459] JNDI timeout fails before timeout is reached

Hello Ivan, Thanks for the updated patch. I would like to see a testcase along with this fix, since it is modifying a critical component of the LDAP client code. An LDAP server may not even be required in order to exercise the timeouts. Thanks. On 3 Dec 2013, at 14:35, Ivan Gerasimov wrote:

Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected

igure.sh, I just assume is ok once > common/autoconf/autogen.sh is run ). > > -Chris. > > On 30/10/2013 16:24, Vincent Ryan wrote: >> Sure. I’ll re-run autogen.sh and submit an updated webrev. >> Thanks. >> >> >> On 30 Oct 2013, at 16:15, Erik Joelsson

Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected

to also submit > the closed generated-configure. > > /Erik > > On 2013-10-30 17:07, Vincent Ryan wrote: >> Thanks Erik. We’re seeing the issue in TL so it’d be great to get this fixed >> today. >> Would you like to take ownership of this issue or shall I push yo

Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected

; It seems the problem is with the grep tool used to parse the version string. >> /usr/xpg4/bin/grep doesn't handle '\(3\.8[12]\)\|\(4\.\)' the same as gnu >> grep. In jprt it finds /usr/sfw/bin/ggrep which works better. I will see if >> I can figure out something

Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected

ter. > > I guess we can still resolve the problem in tl, and sync back into master, > but Erik should ensure that the original issue is still fixed, "8026528: > [build] configure does not recognize newer make in cygwin" > > -Chris. > > [1] http://hg.openjdk.java.

[8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected

Please review this fix to correct the JDK8 build Configure script. It reverts a recent change to common/autoconf/basics.m4 that was causing a build failure on Solaris. Bug: https://bugs.openjdk.java.net/browse/JDK-8027567 Webrev: http://cr.openjdk.java.net/~vinnie/8027567/

Re: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

The JAAS and JGSS changes look fine too. On 7 Oct 2013, at 09:23, Chris Hegarty wrote: > Alan, > > I checked the httpsever and sctp changes. All look good to me. > > -Chris. > > On 10/06/2013 09:03 PM, Alan Bateman wrote: >> >> As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exp

Re: Fake DNS query result inside a test

Are you suggesting to run a local DNS server? If so then it is easy to access that via a JNDI context. If you're proposing developing a basic JNDI service provider then that would be more effort. On 7 Nov 2012, at 01:05, Weijun Wang wrote: > Hi Vinnie > > I want to write a regression test so

Re: Request for review: 8000487: Java JNDI connection library on ldap conn is not honoring configured timeout

Those changes look good Rob. Thanks. On 11 Oct 2012, at 21:22, Rob McKenna wrote: > Hi folks, > > Seemingly when using ldap's simple authentication we perform a > readReply. (an operation which is subject to > com.sun.jndi.ldap.read.timeout as opposed to > com.sun.jndi.ldap.connect.timeout) Th

Re: Code review request: 6961765: Double byte characters corrupted in DN for LDAP referrals

Your fix looks fine. On 03/ 6/12 08:32 AM, Weijun Wang wrote: Hi Vinnie This bug is about using UrlUtil.decode() to decode a URL that is not fully encoded, i.e. including non-ASCII characters. The webrev is at http://cr.openjdk.java.net/~weijun/6961765/webrev.00/ It simply delegates the cal

Re: 7056489: test/com/sun/jndi/ldap/ReadTimeoutTest.java loops or times out

Apologies for overlooking the core-libs audience. On 06/20/11 23:42, Joe Darcy wrote: > Vincent Ryan wrote: >> On 06/20/11 16:08, Alan Bateman wrote: >> >>> Vincent Ryan wrote: >>> >>>> : >>>> Thanks Alan. JNDI applications are encou

Re: 7056489: test/com/sun/jndi/ldap/ReadTimeoutTest.java loops or times out

Your fix looks good. On 18/06/2011 20:39, Alan Bateman wrote: I need a reviewer for a small fix to a test that I caught looping on my syst.em. The test creates a server thread that emulates a non responding LDAP server. Unfortunately the thread goes into a loop reading from the connection once

hg: jdk7/tl/jdk: 2 new changesets

Changeset: 78d91c4223cb Author:vinnie Date: 2010-03-01 17:54 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/78d91c4223cb 6921001: api/java_security/IdentityScope/IdentityScopeTests.html#getSystemScope fails starting from b78 JDK7 Reviewed-by: mullan ! src/share/classes/java

hg: jdk7/tl/jdk: 2 new changesets

Changeset: 117b245b5bb9 Author:vinnie Date: 2010-01-21 23:59 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/117b245b5bb9 6763530: Cannot decode PublicKey (Proider SunPKCS11, curve prime256v1) Reviewed-by: andrew ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java !

hg: jdk7/tl/jdk: 6876158: Remove dependencies on Signer, Certificate, Identity, IdentityScope classes from java.security pkg

Changeset: 327adb1c2224 Author:vinnie Date: 2009-12-07 17:06 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/327adb1c2224 6876158: Remove dependencies on Signer, Certificate, Identity, IdentityScope classes from java.security pkg Reviewed-by: alanb, mullan ! src/share/classe

hg: jdk7/tl/jdk: 6906854: SSL/Krb5 testcase should not use a fixed port number

Changeset: bc12627832e0 Author:vinnie Date: 2009-12-03 21:30 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc12627832e0 6906854: SSL/Krb5 testcase should not use a fixed port number Reviewed-by: alanb ! test/ProblemList.txt ! test/sun/security/krb5/auto/SSL.java

hg: jdk7/tl/jdk: 2 new changesets

Changeset: 561186928899 Author:vinnie Date: 2009-12-02 17:06 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/561186928899 6906510: Fix testcase for 6894643: Separate out dependency on Kerberos Reviewed-by: weijun ! test/sun/security/krb5/auto/SSL.java Changeset: 79d91585d7d7

hg: jdk7/tl/jdk: 2 new changesets

Changeset: 7475a2e71c40 Author:vinnie Date: 2009-11-12 23:00 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7475a2e71c40 6894643: Separate out dependency on Kerberos Reviewed-by: alanb, xuelei ! make/sun/security/other/Makefile ! src/share/classes/com/sun/jndi/ldap/ext/Start

hg: jdk7/tl/jdk: 6885204: JSSE should not require Kerberos to be present

Changeset: 54118c8e0ebe Author:vinnie Date: 2009-10-05 23:42 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/54118c8e0ebe 6885204: JSSE should not require Kerberos to be present Reviewed-by: wetmore, alanb ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/Deleg

hg: jdk7/tl/jdk: 6884175: CR cleanup for 6840752: Provide out-of-the-box support for ECC algorithms

Changeset: 845fefff00a4 Author:vinnie Date: 2009-09-21 23:01 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/845fefff00a4 6884175: CR cleanup for 6840752: Provide out-of-the-box support for ECC algorithms Reviewed-by: wetmore ! make/sun/security/ec/Makefile ! make/sun/securi

hg: jdk7/tl/jdk: 6872048: bad private keys are generated for 2 specific ECC curves

Changeset: dd997cc0c823 Author:vinnie Date: 2009-08-24 18:37 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd997cc0c823 6872048: bad private keys are generated for 2 specific ECC curves Reviewed-by: wetmore ! src/share/native/sun/security/ec/ec.c ! test/sun/security/ec/Test

hg: jdk7/tl/jdk: 3 new changesets

Changeset: 1ff7163fc5f7 Author:vinnie Date: 2009-08-11 16:52 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1ff7163fc5f7 6840752: Provide out-of-the-box support for ECC algorithms Reviewed-by: alanb, mullan, wetmore ! make/sun/security/Makefile + make/sun/security/ec/FILES_c