On 04/15/2015 01:04 PM, Paul Sandoz wrote:
Hi Markus,
Sorry for the late reply i have been away for the last 3 weeks.
You and your colleagues might be interested in discussion of JEP 238 on
org.apache.maven.dev:
On Apr 15, 2015, at 2:03 PM, Remi Forax fo...@univ-mlv.fr wrote:
Of course we cannot feasibly backport every new API in N to N-1, N-2 etc. In
selective cases that might be possible, but for the core of the JDK it's
like pulling on a string of public dependencies, internal dependencies and
When this simple program is run:
public class TestSystemVersion {
public static void main(String[] args) {
System.out.println(1. java.version: +
System.getProperty(java.version));
System.out.println(1. java.runtime.version: +
System.getProperty(java.runtime.version));
Hi Remi,
On Apr 15, 2015, at 1:58 PM, Remi Forax fo...@univ-mlv.fr wrote:
Hi Paul,
I think you're seriously underestimate the cost of this JEP.
That is why we are asking for feedback :-) I want to understand the impact and
get some concrete reasons why certain aspects are difficult.
On 15/04/2015 13:37, Magnus Ihse Bursie wrote:
When this simple program is run:
public class TestSystemVersion {
public static void main(String[] args) {
System.out.println(1. java.version: +
System.getProperty(java.version));
System.out.println(1. java.runtime.version: +
Hi Paul,
I think you're seriously underestimate the cost of this JEP.
You're asking Java devs to:
- be able to maintain several codes with different source level
compatibility in the same code tree.
- add a level of indirection in all tools that crawle/compile Java
source code
- add a level
Roland, thanks for looking into the fix!
You are right.
I moved VM_ENTRY_MARK to the beginning of the method [1].
Updated webrev in place.
http://cr.openjdk.java.net/~vlivanov/8057967/webrev.01/
Best regards,
Vladimir Ivanov
[1]
diff --git a/src/share/vm/ci/ciCallSite.cpp
Hello Joe,
The copyright changes were reverted.
Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/
(code/code replaced with {@code}, removed unnecessary /p,
used @literal tag).
Thanks,
Alexander
On 13.04.2015 21:19, huizhe wang wrote:
On 4/13/2015
http://cr.openjdk.java.net/~vlivanov/8057967/webrev.01/
That looks good to me.
Roland.
Hi Brian,
Looks fine as is.
But I'm curious why CODE_POINT_U000 is defined as String instead of char?
The indexOf() operation is more efficient for single characters.
Thanks, Roger
On 4/14/2015 5:56 PM, Brian Burkhalter wrote:
Please review at your convenience this latest patch modified
Hi Roger,
On Apr 15, 2015, at 9:50 AM, Roger Riggs roger.ri...@oracle.com wrote:
Looks fine as is.
Thanks for reviewing it.
But I'm curious why CODE_POINT_U000 is defined as String instead of char?
The indexOf() operation is more efficient for single characters.
Probably because I had
I was at least partly responsible for the pipe buffer cleanup code.
Subprocess terminates, but may have written some data to the pipe buffer
(typically 4k on Linux). Usually the pipe buffer is empty, but in case
it's not, you don't want to lose the straggler data, you want to drain it
and close
Hi Peter,
I don't know the history behind the stream draining in ProcessImpl.
I understood it to be a performance/scalability issue.
Maybe Martin, Alan, or someone else can fill in the history.
Roger
On 4/15/2015 2:31 AM, Peter Levart wrote:
Hi Roger,
So I started new thread...
On
Updated and hopefully final patch here:
http://cr.openjdk.java.net/~bpb/8075156/webrev.02/
Test run in progress.
Barring any objections I assume that changing CODE_POINT_U from a String to
an int does not require another Reviewer approval, so I will go ahead and push
the fix after the yet
Hi Brian,
Looks fine to me.
Thanks, Roger
On 4/15/2015 2:41 PM, Brian Burkhalter wrote:
Updated and hopefully final patch here:
http://cr.openjdk.java.net/~bpb/8075156/webrev.02/
Test run in progress.
Barring any objections I assume that changing CODE_POINT_U from a String to
an int
Hi Martin,
That sounds like finalization of the FileDescriptor, but perhaps a
mechanism built on PhantomRef
would be easier enough to maintain and can leave the data in the pipe.
Roger
On 4/15/2015 1:59 PM, Martin Buchholz wrote:
I was at least partly responsible for the pipe buffer cleanup
On 15/04/2015 20:23, huizhe wang wrote:
Please review the change related to the non-SE org.w3c.dom.** API:
org.w3c.dom.css, org.w3c.dom.html, org.w3c.dom.stylesheets,
org.w3c.dom.xpath.
They came into Java SE along with the DOM API, but were not part of
the Java SE and JAXP specification.
Please review the change related to the non-SE org.w3c.dom.** API:
org.w3c.dom.css, org.w3c.dom.html, org.w3c.dom.stylesheets,
org.w3c.dom.xpath.
They came into Java SE along with the DOM API, but were not part of the
Java SE and JAXP specification. For css, html and stylesheets, there is
no
On 04/15/2015 07:59 PM, Martin Buchholz wrote:
I was at least partly responsible for the pipe buffer cleanup code.
Subprocess terminates, but may have written some data to the pipe
buffer (typically 4k on Linux). Usually the pipe buffer is empty, but
in case it's not, you don't want to
I have internalized the idea that finalization is a method of last resort.
If there's a chance to free some OS resource by doing some work NOW, do it,
and don't leave it for a finalizer to do later.
On Wed, Apr 15, 2015 at 12:31 PM, Peter Levart peter.lev...@gmail.com
wrote:
On 04/15/2015
Hi Alan, Lance,
On 4/15/2015 2:26 PM, Lance Andersen wrote:
Looks OK other than what Alan suggested which I would think we could
add the SUID given it is in our code base.
You guessed it right. It was the upstream source that was on my mind
when I decided not to add a SUID. Yes, it's in our
Hi Joe,
On Apr 15, 2015, at 6:11 PM, huizhe wang huizhe.w...@oracle.com wrote:
Hi Alan, Lance,
On 4/15/2015 2:26 PM, Lance Andersen wrote:
Looks OK other than what Alan suggested which I would think we could add the
SUID given it is in our code base.
You guessed it right. It was the
Note that one possible feature of JDK 9 is a -platform N option to javac
which would allow compiling against older versions of the platform
libraries:
JEP draft: Compile for Specific Platform Version
http://openjdk.java.net/jeps/8058150
This feature would address some of the concerns
Looks OK other than what Alan suggested which I would think we could add the
SUID given it is in our code base.
Please check DOMXPathTest as it looks like you were bit by netbeans formatting
for the comment for test(). Same is true for some of the other classes where
in some cases there is an
On 4/15/2015 3:22 PM, Lance Andersen wrote:
Hi Joe,
On Apr 15, 2015, at 6:11 PM, huizhe wang huizhe.w...@oracle.com
mailto:huizhe.w...@oracle.com wrote:
Hi Alan, Lance,
On 4/15/2015 2:26 PM, Lance Andersen wrote:
Looks OK other than what Alan suggested which I would think we could
add
On 04/15/2015 02:59 PM, Paul Sandoz wrote:
On Apr 15, 2015, at 2:03 PM, Remi Forax fo...@univ-mlv.fr wrote:
Of course we cannot feasibly backport every new API in N to N-1, N-2 etc. In
selective cases that might be possible, but for the core of the JDK it's like
pulling on a string of public
On 04/15/2015 02:44 PM, Paul Sandoz wrote:
Hi Remi,
On Apr 15, 2015, at 1:58 PM, Remi Forax fo...@univ-mlv.fr wrote:
Hi Paul,
I think you're seriously underestimate the cost of this JEP.
That is why we are asking for feedback :-) I want to understand the impact and
get some concrete
Hi Roger,
So I started new thread...
On 04/14/2015 11:33 PM, Roger Riggs wrote:
On 4/14/2015 11:47 AM, Peter Levart wrote:
I have been thinking of another small Process API update. Some people
find it odd how redirected in/out/err streams are exposed:
Hi Roger,
On 04/14/2015 11:33 PM, Roger Riggs wrote:
Hi Peter,
Thanks for the review.
On 4/14/2015 11:47 AM, Peter Levart wrote:
On 04/09/2015 10:00 PM, Roger Riggs wrote:
Please review the API and implementation of the Process API Updates
described inJEP 102
Hi Vladimir,
http://cr.openjdk.java.net/~vlivanov/8057967/webrev.01/hotspot/
In ciCallSite::get_context(), is it safe to manipulate a raw oop the way you do
it (with 2 different oops). Can’t it be moved concurrently by the GC?
Roland.
Hi Markus,
Sorry for the late reply i have been away for the last 3 weeks.
You and your colleagues might be interested in discussion of JEP 238 on
org.apache.maven.dev:
http://markmail.org/thread/v5ywgdpuprntrvfu#query:+page:1+mid:v5ywgdpuprntrvfu+state:results
especially when it gets to
31 matches
Mail list logo
