On 08/03/2013 01:48, David Holmes wrote:
Not sure which is best list for this given Alan will likely be the
only reviewer anyway :)
Webrevs under:
http://cr.openjdk.java.net/~dholmes/8009428_8009429/
As further background to others, the reverting of the $ substitution
became possible when
Alan,
I guess that one of the reasons for all these classes
(MutableBigInteger and SignedMutableBigInteger, FDBigInteger)
is that they are mutable. The immutable class java.math.BigInteger
will require more memory allocations.
The efficient conversion from string to double has some aspects that
On 2013-03-08 10:19, Alan Bateman wrote:
On 08/03/2013 01:48, David Holmes wrote:
Not sure which is best list for this given Alan will likely be the
only reviewer anyway :)
Webrevs under:
http://cr.openjdk.java.net/~dholmes/8009428_8009429/
As further background to others, the reverting of
On 8/03/2013 7:19 PM, Alan Bateman wrote:
On 08/03/2013 01:48, David Holmes wrote:
Not sure which is best list for this given Alan will likely be the
only reviewer anyway :)
Webrevs under:
http://cr.openjdk.java.net/~dholmes/8009428_8009429/
As further background to others, the reverting of
Thanks Erik!
David
On 8/03/2013 9:25 PM, Erik Joelsson wrote:
On 2013-03-08 10:19, Alan Bateman wrote:
On 08/03/2013 01:48, David Holmes wrote:
Not sure which is best list for this given Alan will likely be the
only reviewer anyway :)
Webrevs under:
On 08/03/2013 11:28, David Holmes wrote:
Now I'm a little concerned. I had not considered whether javac/javadoc
considered these to be complete lists. They have to know how to
combine the includes at a low-level with the excludes of a
higher-level - and potentially vice-versa.
I think javac
Changeset: 98cf76df3e6e
Author:alanb
Date: 2013-03-08 12:03 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98cf76df3e6e
8006000: TEST_BUG: java/lang/invoke/lambda/LambdaAccessControlTest.java fails
intermittently
Reviewed-by: chegar
+
Since the new build does not enable -Werror when compiling any java
code, and disables quite a few lint options, new changes my
inadvertently introduce warnings without even realizing. This can cause
problems when building with the old build as many areas do compile with
-Werror set. Since the
John Rose wrote:
Remi's idea (using invokedynamic) makes a good proof of concept, too.
But because we use getCallerClass to observe a non-forgeable caller
identity, the @CS mechanism has to be something that works underneath
any visible bytecode pattern, at least in the caller.
Yes. In IKVM
On 08/03/2013 13:24, Chris Hegarty wrote:
Since the new build does not enable -Werror when compiling any java
code, and disables quite a few lint options, new changes my
inadvertently introduce warnings without even realizing. This can
cause problems when building with the old build as many
Looks fine to me. Do we have an issue open for restoring warnings to the new
build?
Mike
On Mar 8 2013, at 05:24 , Chris Hegarty wrote:
Since the new build does not enable -Werror when compiling any java code, and
disables quite a few lint options, new changes my inadvertently introduce
On 08/03/2013 15:49, Mike Duigou wrote:
Looks fine to me. Do we have an issue open for restoring warnings to the new
build?
Mike
I don't know if there is an issue for that yet but as the new build
compiles thousands of classes in a single compilation unit then it means
we will need to make
On 08/03/2013 15:49, Mike Duigou wrote:
Looks fine to me.
Thanks Mike.
Do we have an issue open for restoring warnings to the new build?
Not yet, that I am aware of. We really need the ability to set lint
options per package/subpackage.
-Chris.
Mike
On Mar 8 2013, at 05:24 , Chris
On 08/03/2013 16:09, Mike Duigou wrote:
:
Understood. Perhaps we can at least use JDK_FILTER incrementally. Do we have a
way to override the warnings used by the makefile?
I haven't tried it but Erik suggested in a reply to Dan a few months
ago, that is should be possible:
Those changes look fine to me. None of those typedefs make sense with JNIEXPORT
since they're only used locally, and most are scoped to a single function…
I agree with the __has_attribute comment.
The next step would be to try setting -fvisibility=hidden and
-fvisibility-inlines-hidden :) I
http://cr.openjdk.java.net/~alanb/8009645/webrev/
Wow. I remember when this code was new. So happy to see it going.
The changes look great to me!
Thanks,
iris
The hotspot definitions of JNIEXPORT don't match in all the files to the
JDK definition. I think a hotspot bug should be filed to fix the
jni_cpu.h definitions which now none of them match. After someone in
core-libs checks this in, we'll update the hotspot files to match the
final version
Changeset: 01908630df14
Author:alanb
Date: 2013-03-08 19:51 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01908630df14
8009645: ClassFileTransformer hooks in ClassLoader no longer required
Reviewed-by: mchung, iris
! src/share/classes/java/lang/ClassLoader.java
!
On Mar 5 2013, at 07:12 , Alan Bateman wrote:
Just a couple of small things.
Will the docs build complain about the unknown taglets? (@apiNote, @implNote
...)
It currently issues a warning. I have a Javadoc.gmk patch which I am pursuing
separately to enable recognition of these tags.
IIRC, there have already been centithreads discussing Optional; I don't
think the final decision is likely to change at this point.
On Fri, Mar 8, 2013 at 12:26 PM, Mike Duigou mike.dui...@oracle.com wrote:
On Mar 5 2013, at 07:12 , Alan Bateman wrote:
Just a couple of small things.
On 3/5/2013 11:12 AM, Jim Gish wrote:
For the LoggerResourceBundleRace test then does it have to run in its
own VM?
Because we no longer search up the stack for the bundles, this test
fails unless run in its own vm. However, to avoid this, I'll try to
change the test to set the context
I've update the webrev with the suggested changes:
http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/
http://cr.openjdk.java.net/%7Ejgish/Bug8002070-RemoveResourceBundleStackSearch/
Thanks,
Jim
On 03/08/2013 03:41 PM, Mandy Chung wrote:
On 3/5/2013 11:12 AM,
On 3/8/2013 2:39 PM, Jim Gish wrote:
I've update the webrev with the suggested changes:
http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/
http://cr.openjdk.java.net/%7Ejgish/Bug8002070-RemoveResourceBundleStackSearch/
Thumbs up. Thanks for adding the comment in
Changeset: e38b46041049
Author:mduigou
Date: 2013-03-08 15:45 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e38b46041049
8001667: Comparator combinators and extension methods
Reviewed-by: mduigou, briangoetz
Contributed-by: henry@oracle.com
!
I responded in another thread (wasn't aware of this one, sorry), there
is an alternate to completely disabling -Werror.
On 3/8/2013 7:58 AM, Chris Hegarty wrote:
On 08/03/2013 15:49, Mike Duigou wrote:
Looks fine to me.
Thanks Mike.
Do we have an issue open for restoring warnings to
Hello Alan,
Thanks for the comments.
On Mar 8, 2013, at 2:01 AM, Alan Eliasen wrote:
I notice that the solution introduces yet another version of
BigInteger to add to BigInteger, MutableBigInteger,
SignedMutableBigInteger, and whatever other proprietary classes are
lurking. That should
26 matches
Mail list logo
