Hi Sherman,
As a (minor) data point, IKVM.NET has been using a pure Java ZipFile
implementation since day one (based on the GNU Classpath version) and other
than a few compat bugs in the early days people have never complained about it.
For obvious reasons, I'd certainly prefer the pure Java
Hi everyone,
could you please review my change for JDK-8042887?
http://cr.openjdk.java.net/~alanb/8042887/webrev/
I also created following issues for appropriate docs/localization updates:
https://bugs.openjdk.java.net/browse/JDK-8043613
https://bugs.openjdk.java.net/browse/JDK-8043620
Thanks
Looks good!
Erik
Yekaterina Kantserova skrev 2014-05-20 15:48:
Thanks Staffan!
New webrev can be found here:
http://cr.openjdk.java.net/~ykantser/8043520/webrev.01/
// Katja
On 05/20/2014 03:07 PM, Staffan Larsen wrote:
Thanks Erik!
Staffan, could you please be my sponsor and push the change?
// Katja
On 05/22/2014 11:02 AM, Erik Gahlin wrote:
Looks good!
Erik
Yekaterina Kantserova skrev 2014-05-20 15:48:
Thanks Staffan!
New webrev can be found here:
On 22/05/2014 09:47, Pavel Rappo wrote:
Hi everyone,
could you please review my change for JDK-8042887?
http://cr.openjdk.java.net/~alanb/8042887/webrev
Thanks Pavel, good to see this legacy option going away. The change
looks good to me and I'm happy to sponsor it for you.
-Alan.
This looks good to me.
Trivially, I think you could remove the 3 and 4 arg Res.getText methods, as I
don’t see them being used.
-Chris.
On 22 May 2014, at 09:47, Pavel Rappo pavel.ra...@oracle.com wrote:
Hi everyone,
could you please review my change for JDK-8042887?
Yeah, I've done that before. But finally decided to exclude this change and
several more unrelated to the issue. I believe from the 'hg' history
perspective it will look cleaner. I can file a separate bug for a tiny
refactoring of this tool if you want, but being realistic I don't think anybody
It is up to you. Consider it reviewed, from my perspective, either way.
-Chris.
On 22 May 2014, at 14:47, Pavel Rappo pavel.ra...@oracle.com wrote:
Yeah, I've done that before. But finally decided to exclude this change and
several more unrelated to the issue. I believe from the 'hg' history
Hi,
The webrev has been updated to more completely describe the pid:
The native process id is an identification number that the operating
system assigns to the process.
Any other comments?
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/
Looks good. Don't forget @since 1.9 in the javadoc
Cheers,
Paul
On Thu, May 22, 2014 at 8:49 AM, roger riggs roger.ri...@oracle.com wrote:
Hi,
The webrev has been updated to more completely describe the pid:
The native process id is an identification number that the operating
system
Fix looks fine Rob.
Thanks.
On 16 May 2014, at 17:00, Rob McKenna rob.mcke...@oracle.com 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
Hi Roger!
On 22.05.2014 17:49, roger riggs wrote:
Hi,
The webrev has been updated to more completely describe the pid:
The native process id is an identification number that the operating
system assigns to the process.
Any other comments?
I assume it compiles fine, but in
On 22/05/2014 14:49, roger riggs wrote:
Hi,
The webrev has been updated to more completely describe the pid:
The native process id is an identification number that the operating
system assigns to the process.
Any other comments?
Webrev:
On 05/22/2014 08:49 AM, roger riggs wrote:
Hi,
The webrev has been updated to more completely describe the pid:
The native process id is an identification number that the operating
system assigns to the process.
Any other comments?
Webrev:
Hello!
Some functions were renamed with the fix for JDK-8015318.
A few of them kept their old names in the comments.
Would you please review this trivial fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043772
WEBREV: http://cr.openjdk.java.net/~igerasim/8043772/0/webrev/
Sincerely
On 22/05/2014 16:34, David M. Lloyd wrote:
I guess this is a little late, and minor, but the jstack tool uses
the acronym nid for this purpose, which I believe is mapped to the
same concept (on Linux it is anyway).
I think either this terminology should be unified on the jstack side,
or
Hi,
jstack -help uses pid; where are looking?
Roger
On 5/22/2014 11:34 AM, David M. Lloyd wrote:
On 05/22/2014 08:49 AM, roger riggs wrote:
Hi,
The webrev has been updated to more completely describe the pid:
The native process id is an identification number that the operating
system
On 05/22/2014 10:34 AM, David M. Lloyd wrote:
On 05/22/2014 08:49 AM, roger riggs wrote:
Hi,
The webrev has been updated to more completely describe the pid:
The native process id is an identification number that the operating
system assigns to the process.
Any other comments?
Webrev:
Hi Ivan,
Looks fine, Roger
On 5/22/2014 11:36 AM, Ivan Gerasimov wrote:
Hello!
Some functions were renamed with the fix for JDK-8015318.
A few of them kept their old names in the comments.
Would you please review this trivial fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043772
On 05/22/2014 10:44 AM, Alan Bateman wrote:
On 22/05/2014 16:34, David M. Lloyd wrote:
I guess this is a little late, and minor, but the jstack tool uses
the acronym nid for this purpose, which I believe is mapped to the
same concept (on Linux it is anyway).
I think either this terminology
Hi,
Thanks for the rationale.
Using the natural terminology familiar to developers seems most useful.
Mac, Windows, and Linux refer to these values a process id or pid
as the handle for a Process; it appears in the tools like ps and tasklist.
The javadoc can explain anything more specific or
Looks fine to me.
Mike
You are using an old version of webrev :-)
wget http://hg.openjdk.java.net/code-tools/webrev/raw-file/tip/webrev.ksh
On May 22 2014, at 08:36 , Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
Hello!
Some functions were renamed with the fix for JDK-8015318.
A few
Refer to 8042889, while verifying/testing 8042889, we noticed that the
tiny XML parser failed on UTF-16BE or LE. The cause of the failure was
that the parser was actually implemented to abide by the XML
specification that required entities encoded in UTF-16 to begin with
BOM. The test we used
Looks OK. I would suggest removing the commented out code from the test before
you push to the workspace
Best
Lace
On May 22, 2014, at 12:30 PM, huizhe wang huizhe.w...@oracle.com wrote:
Refer to 8042889, while verifying/testing 8042889, we noticed that the tiny
XML parser failed on
Hi
(1) Do we really need those shift at line ln#2989/90 and 2994/95? it appears to
me
those bytes have been decided to be ZERO already, we are talking about
mChar[0] = '' and mChar[1] = '?' here, right?
(2) for test, maybe we should just do p.loadFromXML(in) ? that path should
Masayoshi, Roger,
OK, let's forget the fancy TarInputStream for now:-)
Here is the webrev that just updates the code to use existing java.time classes
for tzdb data building.
http://cr.openjdk.java.net/~sherman/8042369/webrev
The difference compared to the last version [1] is that it reads in
Thanks for the feedback and recommendations; the webrev has been updated.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/
Alan, on the use of tasklist, I think a cleaner test can be written when the
Java API to inspect other processes is available. I did not find a
No additional code review necessary, this is just an FYI.
For internal reasons (i.e. we have to sign our JCE jar files), we have
separated the JCE portion for:
8041679: Replace uses of StringBuffer with StringBuilder within the JDK
into:
8043342: Replace uses of StringBuffer with
28 matches
Mail list logo
