Hello Volker,
I like this solution, even if it could be viewed as a bit of overkill.
/Erik
On 2013-11-14 17:35, Volker Simonis wrote:
Hi,
I wanted to solve 8026964: Building with an IBM J9 boot jdk requires
special settings for BOOT_RTJAR
(https://bugs.openjdk.java.net/browse/JDK-8026964)
On 14/11/2013 21:37, Mark Sheppard wrote:
Hi,
please oblige and review the following fix
http://cr.openjdk.java.net/~msheppar/8028215/webrev/
which addresses the issue detailed in
https://bugs.openjdk.java.net/browse/JDK-8028215
This addresses an ORB initialization problem, which has
On Fri, Nov 15, 2013 at 12:32 AM, David Holmes david.hol...@oracle.com wrote:
Hi Volker,
On 15/11/2013 2:35 AM, Volker Simonis wrote:
Hi,
I wanted to solve 8026964: Building with an IBM J9 boot jdk requires
special settings for BOOT_RTJAR
Changeset: d4cbb671de1c
Author:vromero
Date: 2013-11-15 11:08 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d4cbb671de1c
8026231: Look at 'static' flag when checking method references
Reviewed-by: jjg, dlsmith
! src/share/classes/com/sun/tools/javac/code/Kinds.java
!
Looks good to me too Aleksej.
regards,
Sean.
On 08/11/2013 16:42, Xueming Shen wrote:
looks fine. I would assume you've also run the corresponding tests at
test/closed repo.
-Sherman
On 11/5/2013 8:38 AM, Aleksej Efimov wrote:
Hi,
Can I have a review for tzdata2013h integration [1]. The
Looks good here too Aleksej.. in case you need a second reviewer.
regards,
Sean.
On 06/11/2013 17:18, Xueming Shen wrote:
Looks fine.
thanks!
-Sherman
On 11/05/2013 03:21 PM, Aleksej Efimov wrote:
Sherman,
Thank you for a quick review. I totally agree with you on all items.
Actually, I
On 14/11/2013 23:27, Bill Shannon wrote:
:
I'd prefer that all variants of the API report the error in a way that allows
the users of the API to ignore the error, access the data that caused the error,
and supply replacement data if desired.
For most of the APIs, decoding as much data as
Hi
Please review this javadoc clarification for j.l.annnotation.Target and
j.l.annotation.ElementType as part of the type annotations work.
Webrev: http://cr.openjdk.java.net/~jfranck/8027413/webrev.00/
JBS:https://bugs.openjdk.java.net/browse/JDK-8027413
This is based on the update to JLS
On Thu, Nov 14, 2013 at 07:21:38PM -0800, Joseph Darcy wrote:
Hello,
Catching up on email, the specification of java.lang.Class does not
explicitly promise that its notion of equality must be identity for
all time. Therefore, while not required for today's implementations,
I would prefer
On 15 November 2013 03:21, Joseph Darcy joe.da...@oracle.com wrote:
Catching up on email, the specification of java.lang.Class does not
explicitly promise that its notion of equality must be identity for all
time. Therefore, while not required for today's implementations, I would
prefer that
+1
The amount of code in the wild that would break (if this were to change)
virtually guarantees that such a change won't happen, regardless of what
current spec does or does not say. It would probably be easier to just
update the spec at this point to match implementation.
Vitaly
Sent from my
On 14/11/2013 20:59, Xueming Shen wrote:
:
Here is the webrev for the undo (keep the mime encoder(...) rename
change)
http://cr.openjdk.java.net/~sherman/8028397/webrev
I think is okay except for the restoring of the buffer position when an
error occurs. If we try to keep consistent with
On 15/11/2013 11:11 PM, Vitaly Davidovich wrote:
+1
The amount of code in the wild that would break (if this were to change)
virtually guarantees that such a change won't happen, regardless of what
current spec does or does not say. It would probably be easier to just
update the spec at this
Hi Erik,
On Fri, Nov 15, 2013 at 10:09 AM, Erik Joelsson
erik.joels...@oracle.com wrote:
Hello Volker,
I like this solution, even if it could be viewed as a bit of overkill.
thanks:)
I've just posted a RFR to the build-dev list:
On 14/11/2013 23:56, Stuart Marks wrote:
On 11/14/13 2:04 AM, David Holmes wrote:
Sorry for the delay (been enroute). Only issue I have remains the
subSequence
change - you can't weaken the post-condition of
CharSequence.subSequence without
breaking subtype substitutability.
Hi David,
Hi David,
Hi Kumar,
I don't quite see how this gets the jre part of a JDK:
! JAVA_JRE_BIN = new File(JAVAHOME, bin).getAbsolutePath();
!
! File libDir = (isSDK)
! ? new File((new File(JAVAHOME)).getParentFile(), lib)
! : new File(JAVAHOME,
On 15/11/2013 8:36 PM, Volker Simonis wrote:
On Fri, Nov 15, 2013 at 12:32 AM, David Holmes david.hol...@oracle.com wrote:
Hi Volker,
On 15/11/2013 2:35 AM, Volker Simonis wrote:
Hi,
I wanted to solve 8026964: Building with an IBM J9 boot jdk requires
special settings for BOOT_RTJAR
On 11/14/2013 7:11 PM, Mandy Chung wrote:
On 11/14/2013 6:54 PM, Kumar Srinivasan wrote:
New full webrev:
http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/index.html
Delta webrev wrt. webrev.0
http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/webrev.delta/index.html
This looks
On 16/11/2013 2:37 AM, Kumar Srinivasan wrote:
Hi David,
Hi Kumar,
I don't quite see how this gets the jre part of a JDK:
! JAVA_JRE_BIN = new File(JAVAHOME, bin).getAbsolutePath();
!
! File libDir = (isSDK)
! ? new File((new File(JAVAHOME)).getParentFile(),
On 11/15/13 6:36 AM, Alan Bateman wrote:
On 14/11/2013 20:59, Xueming Shen wrote:
:
Here is the webrev for the undo (keep the mime encoder(...) rename
change)
http://cr.openjdk.java.net/~sherman/8028397/webrev
I think is okay except for the restoring of the buffer position when
an error
Alan Bateman wrote on 11/15/13 04:21:
On 14/11/2013 23:27, Bill Shannon wrote:
:
I'd prefer that all variants of the API report the error in a way that allows
the users of the API to ignore the error, access the data that caused the
error,
and supply replacement data if desired.
For most
On 11/15/2013 9:07 AM, David Holmes wrote:
On 16/11/2013 2:37 AM, Kumar Srinivasan wrote:
Hi David,
Hi Kumar,
I don't quite see how this gets the jre part of a JDK:
! JAVA_JRE_BIN = new File(JAVAHOME, bin).getAbsolutePath();
!
! File libDir = (isSDK)
! ?
From sun.misc.Launcher$ExtClassLoader:
private static URL[] getExtURLs(File[] dirs) throws IOException {
VectorURL urls = new VectorURL();
for (int i = 0; i dirs.length; i++) {
String[] files = dirs[i].list();
if (files != null) {
On 15/11/2013 17:12, Xueming Shen wrote:
I'm happy to put the IAE with advanced positions change back, the
webrev has been updated
according.
http://cr.openjdk.java.net/~sherman/8028397/webrev/
That looks much better.
One case that is still a bit awkward is where there are insufficient
On Nov 14, 2013, at 7:21 PM, Joseph Darcy joe.da...@oracle.com wrote:
Catching up on email, the specification of java.lang.Class does not
explicitly promise that its notion of equality must be identity for all time.
Therefore, while not required for today's implementations, I would prefer
On 11/15/2013 12:37 PM, Ioi Lam wrote:
From sun.misc.Launcher$ExtClassLoader:
private static URL[] getExtURLs(File[] dirs) throws IOException {
VectorURL urls = new VectorURL();
for (int i = 0; i dirs.length; i++) {
String[] files =
On 11/15/13 1:01 PM, Alan Bateman wrote:
On 15/11/2013 17:12, Xueming Shen wrote:
I'm happy to put the IAE with advanced positions change back, the
webrev has been updated
according.
http://cr.openjdk.java.net/~sherman/8028397/webrev/
That looks much better.
One case that is still a bit
Well using equals() would make byte code slightly larger and probably slow
down interpreter for no good reason, so it's not fully harmless (with JIT
code, yes, it's harmless).
Sent from my phone
On Nov 15, 2013 11:34 AM, David Holmes david.hol...@oracle.com wrote:
On 15/11/2013 11:11 PM, Vitaly
On 11/14/2013 1:37 PM, Mark Sheppard wrote:
Hi,
please oblige and review the following fix
http://cr.openjdk.java.net/~msheppar/8028215/webrev/
Looks okay. Seems like it worths some refactoring and change
create_impl to take the classname of the default implementation and move
the
Hi Robert;
As mentioned in another thread with Steven Schlansker there is a patch in
progress with similar goals. I will look at your patch and see how much overlap
there is and merge in any relevant parts. This improvement won't make it into
Java 8 but will be implemented early in the Java 9
Hi Steven;
We were able to get some parts of your UUID patch into Java 8 but I
unfortunately didn't get time to get all the pieces in before the Java 8
rampdown began. I was hoping to get the parsing part in next as it seemed to
have a bigger payoff than the remaining toString() changes. These
31 matches
Mail list logo
