Brian, you wrote: It would be utterly criminal if someone were to
restructure the above code into the below code because some IDE inspection
complained about
must call close or use TWR.
I agree here. However, the inheritance of AutoCloseable is going to likely
prompt some kind of action by
On 7/17/2013 10:29 PM, Dan Xu wrote:
I don't know the difference between (*env)-NewStringUTF(env, buf) and
JNU_NewStringPlatform(env, buf). Does the JNU_NewStringPlatform()
function currently fail to process non-western locale? According to
the code, JNU_NewStringPlatform() is also trying to
On 18/07/2013 06:12, Joe Darcy wrote:
Looks fine.
+1.
-Chris.
Thanks,
-Joe
On 07/17/2013 04:19 PM, Jason Uh wrote:
Thanks, Mike.
I'll add that before I push.
On 7/17/13 4:00 PM, Mike Duigou wrote:
Looks good to me.
You could add {@code} around true in ObjectStreamField
Mike
On Jul
Sync's from jsr166 - jdk8 are in progress. Paul and I have pushed, or
still in flight, a number of changeset over the past number of weeks. I
would hope to have the remainder of changes in jdk8 soon.
doclint issues should be fixed in jsr166 CVS first. Either work with
Doug or Martin to
On 07/17/13 21:03, Martin Buchholz wrote:
I'm surprised no one has explained.
The jsr166 project is upstream of openjdk and is primarily maintained by
Doug Lea.
http://gee.cs.oswego.edu/dl/concurrency-interest/index.html
Essentially every file that can be found in Doug's CVS under src/main/util
I see. Thanks for your good explanation. The change looks good to me.
-Dan
On 07/18/2013 12:56 AM, Alexey Utkin wrote:
On 7/17/2013 10:29 PM, Dan Xu wrote:
I don't know the difference between (*env)-NewStringUTF(env, buf)
and JNU_NewStringPlatform(env, buf). Does the JNU_NewStringPlatform()
Changeset: 6e10d93273d0
Author:juh
Date: 2013-07-18 10:49 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6e10d93273d0
8020426: Fix doclint accessibility issues in java.io
Reviewed-by: mduigou, darcy, chegar
! src/share/classes/java/io/DataInput.java
!
Changeset: b39797bb86c0
Author:sherman
Date: 2013-07-18 11:02 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b39797bb86c0
8016025: JSR 310 DateTime API Updates IV
8020418: Cleanup of -Xlint warnings in java.time
8016623: test/java/time/format/TestDateTimeTextProvider.java
On Jul 17, 2013, at 10:07 PM, Joe Darcy wrote:
In Random.java, I would prefer if the font size manipulation of the
exponent was removed instead of
373 * All 2fontstyle=font-size:smaller;sup24/sup/font possible
{@code float} values
just
373 * All 2sup24/sup possible {@code
On 07/18/2013 11:16 AM, Brian Burkhalter wrote:
On Jul 17, 2013, at 10:07 PM, Joe Darcy wrote:
In Random.java, I would prefer if the font size manipulation of the
exponent was removed instead of
373 * All 2fontstyle=font-size:smaller;sup24/sup/font
possible {@code float} values
just
On 07/18/2013 11:35 AM, Martin Buchholz wrote:
As of today, jsr166 CVS src/main is doclint-clean, and will stay that way
because of the added
compilerarg value=-Xdoclint:all/protected/
in build.xml
Excellent news! Looking forward to the next sync :-)
(Note there are some bugs in
On 18 Jul 2013, at 19:35, Martin Buchholz marti...@google.com wrote:
As of today, jsr166 CVS src/main is doclint-clean, and will stay that way
because of the added
compilerarg value=-Xdoclint:all/protected/
in build.xml
Thanks Martin, we'll sync these changes soon.
-Chris
On
On Jul 18, 2013, at 11:50 AM, Joe Darcy wrote:
This I interpret to mean the second example in the first block in this
section http://docs.oracle.com/javase/specs/jls/se7/html/jls-2.html#jls-2.4.
Right (although the on-line rendering in the browser I'm using while typing
this doesn't look
On Jul 18, 2013, at 12:04 PM, Brian Burkhalter wrote:
I don't at first glance see a mapping of the regular expression + (one or
more) to something in the JLS grammar. There are
? = [x] zero or one x
* = {x} zero or more x
but
On Jul 17, 2013, at 10:07 PM, Joe Darcy wrote:
In Random.java, I would prefer if the font size manipulation of the
exponent was removed instead of
373 * All 2fontstyle=font-size:smaller;sup24/sup/font possible
{@code float} values
just
373 * All 2sup24/sup possible {@code
Hi Joe,
On Jul 17, 2013, at 10:31 PM, Joe Darcy wrote:
In the javadoc change, is there a reason for
#91;1,nbsp;12#93;,
rather than just
[1,nbsp;12],
?
Not really.
The update should discuss how normal (that is non-subnormal) values are
handled with reduced precision.
Telling people that your random source passes the die-hard test but at the
same time only using the current time as the seed is just pure evil.
Imagine spinning up a couple of thousands images with a JVM on Amazon. You
are going to see collisions among the seed values a lot sooner than you
think.
Hello,
Please review the patch below which addresses
JDK-8020810: Typo in javadoc for Class.toGenericString()
A note of explanation for the change in j.l.Class, the essence of the
change is replacing
{@code #64;interface}
with
code#64;/code{@code interface}
The construct
18 matches
Mail list logo
