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
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 l
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 crea
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" wrote:
> On 15/11/2013 11:11 PM, Vitaly Davidovich wrote:
>
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 a
On 11/15/2013 12:37 PM, Ioi Lam wrote:
From sun.misc.Launcher$ExtClassLoader:
private static URL[] getExtURLs(File[] dirs) throws IOException {
Vector urls = new Vector();
for (int i = 0; i < dirs.length; i++) {
String[] files = dirs[i].list();
On Nov 14, 2013, at 7:21 PM, Joseph Darcy 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 new code we
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
bi
From sun.misc.Launcher$ExtClassLoader:
private static URL[] getExtURLs(File[] dirs) throws IOException {
Vector urls = new Vector();
for (int i = 0; i < dirs.length; i++) {
String[] files = dirs[i].list();
if (files != null) {
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)
! ?
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.
>
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 occ
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/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 much
On 15/11/2013 8:36 PM, Volker Simonis wrote:
On Fri, Nov 15, 2013 at 12:32 AM, David Holmes 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"
(https://bugs.openjdk.java.n
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 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,
Yes
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 po
Hi Erik,
On Fri, Nov 15, 2013 at 10:09 AM, Erik Joelsson
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:
http://mail.openjdk.java.net/pipermail/build-dev/2013-November/011108.html
with tw
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 Cha
+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 15 November 2013 03:21, Joseph Darcy 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 new code we write
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 pref
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 f
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 possibl
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 misse
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 we
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
!
On Fri, Nov 15, 2013 at 12:32 AM, David Holmes 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"
>> (https://bugs.openjdk.java.net/browse/JDK-8026964) and
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 arise
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) a
31 matches
Mail list logo
