On 2/5/2014 2:58 PM, roger riggs wrote:
Please review this change to remove unused support in jni_util.c for
functions nativeNewStringPlatform and nativeGetStringPlatformChars.
On Windows, both were conditional on jvm.dll being installed on a path
containing kernel.
On Solaris, Linux, and
Hi Daniel,
On 2/6/2014 7:29 AM, Daniel Fuchs wrote:
https://bugs.openjdk.java.net/browse/JDK-8029876
8029876: Add a test to verify that Logger.getLogger
LogManager.getLogManager don't throw NPE
when System.out == null
webrev (trivial copy of the test to jdk9-dev):
On 2/7/2014 10:44 AM, Rob McKenna wrote:
Hi folks,
When files are copied by our test harness the permissions are left
unchanged. This can cause trouble for a few tests when the test folder
is read only.
http://cr.openjdk.java.net/~robm/7152892/webrev.01/
AIX is missing in your change in
On 2/6/2014 9:04 AM, Daniel Fuchs wrote:
On 2/6/14 4:49 PM, Mandy Chung wrote:
Hi Daniel,
On 2/6/2014 7:29 AM, Daniel Fuchs wrote:
https://bugs.openjdk.java.net/browse/JDK-8029876
8029876: Add a test to verify that Logger.getLogger
LogManager.getLogManager don't throw NPE
On 2/12/2014 4:47 AM, Alan Bateman wrote:
On 11/02/2014 11:44, Paul Sandoz wrote:
:
Scrub it!
AFAICT it is not widely used (looking at the use of s.m.Service
static methods on grep code there are only a handful of dependent
artifacts). And the upgrade is quite easy.
I didn't see any more
This patch cleans up a few trivial native warnings (mainly remove local
unreferenced variable)
https://bugs.openjdk.java.net/browse/JDK-8030010
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8030010/webrev.00/
This patch was contributed by Francis Andre [1] and I fixed a couple
This looks good to me too.
Mandy
On 2/12/2014 10:10 AM, roger riggs wrote:
Hi Phil,
The changes look fine. (Not a Reviewer).
Thanks for doing the backport,
Roger
On 2/11/2014 6:42 PM, Phil Race wrote:
Here's a JDk8u webrev : -http://cr.openjdk.java.net/~prr/8031737.8u/
-phil.
On
On 2/13/14 9:54 AM, Rob McKenna wrote:
Sorry Mandy, I totally missed your reply. I'll get this resolved
separately.
No worries. It's fine to do it separately.
Mandy
-Rob
On 10/02/14 15:43, Mandy Chung wrote:
On 2/7/2014 10:44 AM, Rob McKenna wrote:
Hi folks,
When files are copied
Looks good. Sorry I didn't catch this earlier and I was counting on
the test build :)
Mandy
[1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c58c6b0fbe34
On 2/13/2014 1:50 PM, Phil Race wrote:
That worked on Mac but I just found it doesn't build on Linux because
a macro-redefinition
On 2/14/14 10:31 AM, Michael McMahon wrote:
On 14/02/14 18:20, Alan Bateman wrote:
On 14/02/2014 17:42, Michael McMahon wrote:
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8034853/webrev.1/
The change is to remove the class sun.misc.ClassLoaderUtil.
Thumbs up.
FYI - jdeps follows the langtools convention to define a static int
run(String... args) method that doesn't exit but instead returns the
error exit code (whereas the main method will exit with an error code)
so that the test can test the tool with different options in the same VM
On 2/23/14 9:59 PM, Ivan Gerasimov wrote:
Hello!
ReferenceQueue.remove(timeout) may return too early, i.e. before the
specified timeout has elapsed.
Would you please review the fix?
The change also includes a regression test, which can be used to
demonstrate the issue.
BUGURL:
On 2/25/14 6:32 AM, Ivan Gerasimov wrote:
line 76: why do you want to catch InterruptedException? If
interrupted, should the test fail?
ReferenceQueue#remove() can throw InterruptedException, so I had to
handle it.
In the new webrev I set the initial value of actual to TIMEOUT, so if
the
On 2/25/2014 1:46 PM, Ivan Gerasimov wrote:
line 61: I think the test should be:
if (thread.reference != null || thread.actual TIMEOUT)
Sorry, I'm not clear why.
We have two threads:
1) The lucky one gets non-null reference when it calls remove(). For
this thread the actual time it
On 2/25/2014 11:08 PM, Ivan Gerasimov wrote:
I missed that you remove the strong reference (line 57). I think
it's good to hold the strong reference so that
ReferenceQueue.remove(timeout) will timeout and the test can verify
reliably.
This is an important part.
If we didn't remove the
Looks good to me.
Mandy
On 2/26/2014 1:47 PM, Seán Coffey wrote:
Good points Alan. Changes uploaded here :
http://cr.openjdk.java.net/~coffeys/webrev.8035618.v2/webrev/
regards,
Sean.
On 26/02/14 18:54, Alan Bateman wrote:
On 26/02/2014 16:50, Seán Coffey wrote:
Looking to push a fix to JDK
On 2/26/2014 2:12 PM, Ivan Gerasimov wrote:
Good point, thank you Mandy. I should have added comments at the very
beginning.
Would you take a look at the last updated webrev, with the suggested
changes?
http://cr.openjdk.java.net/~igerasim/6853696/3/webrev/
thanks for making the change.
On 2/26/2014 12:54 PM, Martin Buchholz wrote:
I don't recall having added this particular wart
to test/java/lang/ProcessBuilder/Basic.java, and history suggests that
others did that.
It does seem that being able to tell whether a java object monitor is
currently locked is useful for debugging
Hi Roger,
On 2/26/2014 12:34 PM, roger riggs wrote:
The testlibrary for the jdk should be printing the values in the failed
assertions to make debugging easier and quicker.
The webrev adds the printing of the failed assertions and added methods
for formatting and unconditional fail methods.
for
example, how can we run TestNG tests? We need to address that certainly.
My comment on TestNG is a question for new tests using this Asserts
class. Your patch is fine to go (after taking out @library tag if I got
it correct).
Mandy
Thanks, Roger
On 2/26/14 9:01 PM, Mandy Chung wrote
if it is possible to use the TestNG Assert
classes without
the TestNG execution framework.
It would be necessary to compile/run against TestNG.jar but it might not
need the entire mechanism.
Thanks, Roger
On 2/26/2014 10:17 PM, Mandy Chung wrote:
On 2/26/2014 7:09 PM, Roger Riggs wrote:
Hi Mandy,
Yes
On 2/27/14 4:29 AM, Paul Sandoz wrote:
This will allocate about 10 Thread objects per second until the other thread
finally reaches the synchronized read() method in BufferedInputStream...
I like it.
I like it too.
I do have a slight preference for Mandy's solution, see below, but i am not
Thumbs up.
Mandy
On 3/5/2014 4:52 PM, Joe Darcy wrote:
Hello,
Please review the simple patch below which resolves two unchecked cast
lint warnings in java.lang.reflect.WeakCache.
Thanks,
-Joe
diff -r 9099a251d211 src/share/classes/java/lang/reflect/WeakCache.java
---
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035808/webrev.00/
This patch converts the use of sun.security.action.GetPropertyAction
tolambda
(PrivilegedActionString) () - System.getProperty(key)
Similarly for GetIntegerAction and GetLongAction.
The sun.security.action.*
Thumbs up.
Mandy
On 3/7/14 11:46 AM, Brian Burkhalter wrote:
On Mar 7, 2014, at 10:52 AM, Brian Burkhalter wrote:
Patch: http://cr.openjdk.java.net/~bpb/8036848/
I updated this patch to change some ugly albeit legal syntax.
Old:
On 3/7/14 7:03 AM, Sergey Bylokhov wrote:
Is this absolutely necessary? Does it mean that Get**Actions are
deprecated now?
The question should be whether this dependency is absolutely necessary
and it's not. Get**Action classes are simple convenient classes that
you could either use lambda
On 3/7/14 1:24 PM, Mark Sheppard wrote:
Hi,
Please oblige and review the changes
http://cr.openjdk.java.net/~msheppar/8036603/webrev/
Better to rename the variable to stringClass or something more
explicit. Also you can get rid of line 65-66 to simply use stringClass.
I think the
Hi Volker,
On 3/10/14 11:16 AM, Volker Simonis wrote:
Hi,
could you please review the following trivial change which adds AIX to
the list of known OSs in test/java/lang/ClassLoader/Assert.sh:
https://bugs.openjdk.java.net/browse/JDK-8037013
http://cr.openjdk.java.net/~simonis/webrevs/8037013/
On 3/10/2014 11:55 AM, Mandy Chung wrote:
Hi Volker,
On 3/10/14 11:16 AM, Volker Simonis wrote:
Hi,
could you please review the following trivial change which adds AIX to
the list of known OSs in test/java/lang/ClassLoader/Assert.sh:
https://bugs.openjdk.java.net/browse/JDK-8037013
http
On 3/12/2014 11:27 AM, Daniel Fuchs wrote:
Hi,
Please find below a trivial fix for [1]:
8036916: Deprecation warnings in LogManager
[1] https://bugs.openjdk.java.net/browse/JDK-8036916
webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8036916/webrev.00/
Oops.. I didn't catch the typo in
On 3/12/2014 11:51 AM, Daniel Fuchs wrote:
Hi Mandy,
Oh - of course - we don't need the new method actually. I was not
thinking right:
http://cr.openjdk.java.net/~dfuchs/webrev_8036916/webrev.01/
Thumbs up.
Mandy
https://bugs.openjdk.java.net/browse/JDK-8035807
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/
This patch converts the last 2 references to
sun.misc.BASE64Encoder/Decoder from the jdk repo with
java.util.Base64. We should also update the tests and I have
On 3/19/2014 12:03 PM, Vincent Ryan wrote:
Fix looks fine. You just need to update the import statements in Obj.java
Fixed. Not sure how it's missed in the webrev :)
thanks
Mandy
On 19 Mar 2014, at 18:37, Mandy Chung mandy.ch...@oracle.com wrote:
https://bugs.openjdk.java.net/browse/JDK
On 3/19/2014 12:28 PM, Xueming Shen wrote:
On 03/19/2014 11:37 AM, Mandy Chung wrote:
https://bugs.openjdk.java.net/browse/JDK-8035807
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/
This patch converts the last 2 references to
sun.misc.BASE64Encoder/Decoder
On 3/19/14 12:28 PM, Xueming Shen wrote:
On 03/19/2014 11:37 AM, Mandy Chung wrote:
https://bugs.openjdk.java.net/browse/JDK-8035807
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/
This patch converts the last 2 references to
sun.misc.BASE64Encoder/Decoder from
This is the second patch to eliminate the dependencies to
sun.security.action:
https://bugs.openjdk.java.net/browse/JDK-8038177
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8038177/webrev.00/
Mandy
was encoded
with the platform default charset (as the new comment suggested), the old
implementation
actually did not work on platform that the default encoding is not ASCII
compatible, such
as the IBM ebcdic.
-Sherman
On 3/20/14 3:48 PM, Mandy Chung wrote:
On 3/19/14 12:28 PM, Xueming
On 3/24/2014 8:15 AM, Alan Bateman wrote:
On 21/03/2014 21:28, Mandy Chung wrote:
This is the second patch to eliminate the dependencies to
sun.security.action:
https://bugs.openjdk.java.net/browse/JDK-8038177
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8038177/webrev.00
Hi Ivan,
On 3/26/2014 6:15 AM, Ivan Gerasimov wrote:
Hello!
The test java/lang/ref/EarlyTimeout.java, which has been recently
added to the repository with the fix for 6853696 has failed.
The error message of the failure more than one references were
removed from queue seems to be misguiding.
On 3/26/2014 3:57 PM, David Holmes wrote:
Ivan,
I think the problem is that the EarlyTimeout threads can complete
their remove(TIMEOUT) before the main thread has started them all,
cleared the reference and called System.gc().
Depending on exactly what is being tested, the EarlyTimeout
On 3/27/2014 6:36 AM, Ivan Gerasimov wrote:
Now, I updated the webrev with the additional delay as you suggested:
http://cr.openjdk.java.net/~igerasim/8038333/2/webrev/
Thanks for the updated patch, Ivan and also Peter for the suggestion to
delay to give a chance for the threads to wait on
Below is a draft JEP we are considering submitting for JDK 9.
Mandy
Title: Efficient API for Stack Walking
Goal
Define a standard API for stack walking that will be efficient and
performant.
Non-goal
It is not a goal for this API be easy to use via
On 4/2/2014 7:44 AM, Seán Coffey wrote:
On 02/04/14 15:05, Alan Bateman wrote:
On 02/04/2014 11:42, Seán Coffey wrote:
I'm looking to port this fix from JDK 8 to 9. Other changes were
made for JDK 9 given that we have access to the
javaAwtAccess.getAppletContext() method when using JDK 8 as
Hi Shura,
On 4/9/2014 9:00 AM, Alexandre (Shura) Iline wrote:
Hi.
I'd like to ask for review of this fix:
http://cr.openjdk.java.net/~shurailine/8039438/webrev.00/
It's good to see this dependency be removed from the tests. Looks
reasonable. I'll sponsor this change.
Mandy
On 4/10/14 11:05 AM, Mike Duigou wrote:
Isn't all this sun.misc stuff going go away soon anyway? -- wishful thinking
We use them in our implementation and can't go away but at least access
will be denied with module boundary enforcement.
Mandy
On 4/11/2014 3:42 PM, Xueming Shen wrote:
webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev
It's good to see the source of the zip provider moved to the jdk repo.
You have made some public classes to package-private which is good. I
wonder whether a few remaining public classes
Does anyone know of a native library whose JNI_OnUnload calls
JNI_FindClass?
I'm wondering how much existing code out there depends on the
existing behavior that is unsupported.
During the investigation of JDK-4240589, I found that the implementation
JNI_FindClass has a special handling that
On 4/14/2014 2:48 AM, Alexandre (Shura) Iline wrote:
Hi.
I'd like to ask for review of this fix:
http://cr.openjdk.java.net/~shurailine/8039816/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8039816
This change looks fine. Thanks for these test cleanup.
Mandy
On 4/14/2014 6:21 AM, Ivan Gerasimov wrote:
Hello!
The test EarlyTimeout.java failed again, now with message elapsed
time 981 is less than timeout 1000.
The root cause seems to be non-accurate time measurement in Windows:
On 4/14/2014 11:26 AM, Ivan Gerasimov wrote:
Actually, zero tolerance should be sufficient now even for Windows
platform.
Measuring the time with nanoTime() should make the inner and outer
time intervals consistent.
I've added the tolerance just to play safer.
I can remove it.
That'd be
On 4/14/14 8:48 PM, Xueming Shen wrote:
Hi,
webrev has been updated to use the name space jdk.nio.zipfs.
http://cr.openjdk.java.net/~sherman/8038500/webrev/
This patch looks fine. JarFileSystemProvider is currently not used and
it's fine to include it as it will need discussion to decide
Thumbs up
Mandy
On 4/18/2014 4:21 AM, Ivan Gerasimov wrote:
Hi Mandy!
May I consider this fix approved?
Sincerely yours,
Ivan
On 15.04.2014 10:10, Ivan Gerasimov wrote:
On 15.04.2014 6:23, Mandy Chung wrote:
On 4/14/2014 11:26 AM, Ivan Gerasimov wrote:
Actually, zero tolerance should
On 4/18/2014 10:43 AM, Lois Foltan wrote:
Please review the following change to remove a test from ProblemList.txt.
Webrev:
http://cr.openjdk.java.net/~lfoltan/bug_jdk8033584/
Bug: Remove
java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java
from exclude list
Sherman,
Is it better to group zipfs in jdk_nio?
Mandy
On 4/22/2014 7:44 AM, Xueming Shen wrote:
Looks good.
On Apr 22, 2014, at 6:05 AM, Lance Andersen lance.ander...@oracle.com wrote:
Here is the diff for this via bug 8041485
hg diff test/Test.groups
diff -r 3aeb306d985c
This change proposes to remove granting all permissions for extensions
as the default and implements the principle of least privilege.In JDK 9,
we want to reduce the privileges of as many system classes as possible.
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.00/
This patch
creates as implementation details. I'll let Sherman follow up and
fine-tune the permission set.
Thanks for the feedback. I'll send an updated webrev that will also
have the change for os-specific version of java.policy.
Mandy
--Sean
On 04/22/2014 03:39 PM, Mandy Chung wrote:
This change
Thanks Sean.
I have updated the webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/
Erik - I'm including build-dev to review the build change for
java.policy file.
Thanks
Mandy
On 4/24/14 11:32 AM, Sean Mullan wrote:
On 04/23/2014 05:29 PM, Mandy Chung wrote:
On 4
of just =. We only use = assignment
when explicitly needed.
Thanks for the review Erik. I'll make the change before the push.
Mandy
/Erik
On 2014-04-25 01:07, Mandy Chung wrote:
Thanks Sean.
I have updated the webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/
Erik
Miran,
Looks good to me. I'll sponsor this patch for you.
Mandy
On 4/28/14 7:30 AM, Chris Hegarty wrote:
Miran,
This change looks good to me. Reviewed.
I applied the patch to the latest jdk9/dev and all tests pass as
expected.
I see Mandy is sponsoring this for you.
-Chris.
On
Looks fine to me.
Nit: line 528: space after ( and before mainClass can be removed
Mandy
On 4/30/14 3:42 PM, Kumar Srinivasan wrote:
For completeness the bugid line needs the bugid as shown, otherwise
SQE will open
another bug to have you fix this.
-26 * @bug 8001533 8004547
+26 * @bug
On 5/12/14 11:02 AM, Alan Bateman wrote:
In JDK 8 we brought in a tiny XML parser to support the Properties
loadFromXML/storeToXML methods. We needed this for the Compact
Profiles work, specifically builds of compact1 as they do not have
JAXP/XML APIs.
At the time we were a bit nervous
On 5/14/14 4:03 AM, Alan Bateman wrote:
This is a follow-up to the recent change to the modules motivated
switch of the Properties XML methods to consistently use the UKit
parser. An issue that has surfaced since is that the wrapper around
UKit is incorrectly closing the output stream after
com.sun.java.browser.dom and com.sun.java.browser.net classes
are legacy and only used by old plugin. Time to remove them.
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8044063/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8044063
Jon - having a second thought and decide to
, Alan Bateman wrote:
On 18/06/2014 19:22, Mandy Chung wrote:
com.sun.java.browser.dom and com.sun.java.browser.net classes
are legacy and only used by old plugin. Time to remove them.
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8044063/webrev.00/
Good to see this being removed
The loadLibrary implementation is missing to wrap the call
to File.getCanonicalPath method with doPrivileged block.
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8047904/webrev.00/
thanks
Mandy
.
Mandy
open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
bug link https://bugs.openjdk.java.net/browse/JDK-6642881
Thanks,
Coleen
On 6/19/14, 11:01 PM, David Holmes wrote:
On 20/06/2014 6:53 AM, Joel Borggrén-Franck wrote:
Hi Mandy,
On 19 jun 2014, at 22:34, Mandy Chung mandy.ch
On 6/30/14 2:32 PM, huizhe wang wrote:
Hi,
Three packages are missing from the DOM API documentation in JAXP:
org.w3c.dom.views
org.w3c.dom.ranges
org.w3c.dom.traversal
We added org.w3c.dom.views in JAXP 1.6 and fixed JDK-8006843. But
since we were too close to the
On 6/30/2014 9:51 PM, Christian Thalinger wrote:
On Jun 30, 2014, at 5:50 PM, Coleen Phillimore coleen.phillim...@oracle.com
wrote:
On 6/30/14, 3:50 PM, Christian Thalinger wrote:
private Class(ClassLoader loader) {
// Initialize final field for classLoader. The
the code.
Coleen
On 7/2/14, 2:26 AM, Mandy Chung wrote:
On 6/30/2014 9:51 PM, Christian Thalinger wrote:
On Jun 30, 2014, at 5:50 PM, Coleen Phillimore
coleen.phillim...@oracle.com wrote:
On 6/30/14, 3:50 PM, Christian Thalinger wrote:
private Class(ClassLoader loader
I reviewed the jconsole change that looks okay to me.
Mandy
On 7/3/14 12:44 PM, Joe Darcy wrote:
Hello,
In the course of fixing
JDK-8043550: Fix raw and unchecked lint warnings in javax.swing.*
http://cr.openjdk.java.net/~darcy/8043550.1/
I encountered a build failure in jconsole
On 7/4/14 11:04 AM, Alan Bateman wrote:
On 25/06/2014 21:21, Mandy Chung wrote:
This patch is also intended to target for 8u40 backport. It fixes
the following issues:
JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK
internal API
JDK-8039007 jdeps incorrectly reports
observe the performance difference comparing
the rewritten bytecode vs the java.util.logging using the new API.
Mandy
Jeremy
On Sun, Mar 30, 2014 at 4:02 PM, Mandy Chung mandy.ch...@oracle.com
mailto:mandy.ch...@oracle.com wrote:
Below is a draft JEP we are considering submitting
, Mandy Chung wrote:
This patch is also intended to target for 8u40 backport. It fixes
the following issues:
JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK
internal API
JDK-8039007 jdeps incorrectly reports javax.jnlp as JDK internal APIs
JDK-8031092 jdeps does not recognize
Thanks Daniel.
Mandy
On 7/8/14 8:21 AM, Daniel Fuchs wrote:
Hi Mandy,
On 7/8/14 4:59 PM, Mandy Chung wrote:
I took out the special case for javax.jnlp and follow up the change in
deploy to use @jdk.Exported to indicate its supportedness. I also added
a new test case to check the dot file
Looks okay.
Mandy
On 7/8/14 12:15 PM, Brent Christian wrote:
Please review the fix for JDK-8049373. It applies only to 8u.
The JBS issue is not public, but the general problem is that some
closed changes related to JDK-8044473 incorrectly ended up being added
to the compact 1 profile. The
On 7/8/2014 5:58 AM, Daniel Fuchs wrote:
Hi,
Please find below a fix for
8048913: java/util/logging/LoggingDeadlock2.java times out
http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/
My suggestion is thus simply to remove the /timeout=15 from the
@run command line, relying
On 7/9/2014 2:32 AM, Daniel Fuchs wrote:
On 7/9/14 5:46 AM, Mandy Chung wrote:
Do you know if the test was run with -timeoutFactor? Or does it use
the default timeout? Are you able to run the test with the same
configuration (on same test machine) to see how long it takes?
...
What I
jdeps -jdkinternals flags use of JDK internal APIs. We have created a
wiki page to keep track of the JDK internal APIs and its replacement:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
While this page will be updated when we identify any new ones
worthnoting, it'd
' so that you could use things like
| grep 'rt.jar' on the output.
best regards,
-- daniel
On 7/16/14 1:35 AM, Mandy Chung wrote:
jdeps -jdkinternals flags use of JDK internal APIs. We have created a
wiki page to keep track of the JDK internal APIs and its replacement:
https
On 7/16/14 8:59 AM, Chris Hegarty wrote:
This looks like a reasonable reversal of 6898747 [1], so good for me.
Yes this dependency is no longer an issue. It looks okay to keep the
static reference.
Mandy
-Chris.
[1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/a368ebcfeeb6
On
Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.01/
I plan to backport this to 8u40.
Mandy
On 7/16/14 8:09 AM, Mandy Chung wrote:
My first version prints a separate table of the replacements following
the new warning message at the end of the jdeps output. I
Looks good.
Mandy
On 7/16/2014 5:24 PM, Joe Darcy wrote:
Hello,
Please review the patch below for
JDK-8050798: New unchecked warning introduced in
com.sun.jndi.ldap.Connection
which addresses a newly-introduced unchecked warning in core libs.
Thanks,
-Joe
diff -r e4a6f3779797
On 07/09/2014 01:04 PM, Xueming Shen wrote:
Hi,
Please help review the change for JDK-8042589.
Issue:https://bugs.openjdk.java.net/browse/JDK-8042589
webrev: http://cr.openjdk.java.net/~sherman/8042589/webrev/
This is a regression caused by the following change for #JDK-8032012,
issue:
regards,
-- daniel
On 7/17/14 12:38 AM, Mandy Chung wrote:
Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.01/
I plan to backport this to 8u40.
Mandy
On 7/16/14 8:09 AM, Mandy Chung wrote:
My first version prints a separate table of the replacements following
the new
.
Mandy
This is first part of changes - after this also jdk build will have to
be changed.
Changeset has been already discussed during testing phase with Sean
Mullan and Mandy Chung.
Thanks
Miran
This is a regression caused by JDK-8038177 that changed
sun.nio.cs.ext.ExtendedCharsets to use lambda. It turns out that
ExtendedCharsets is loaded during the initialization of the extension
class loader when opening jre/lib/ext/meta-index on windows with system
locale loading extended charsets
(es) in XMLStreamWriterFactory.
Thanks
Miran
On 17/07/14 18:02, Mandy Chung wrote:
On 7/17/2014 8:12 AM, Miroslav Kos wrote:
Hi everybody,
here is a request for review for
8038970: Deprivilege JAX-WS/JAF code
JBS: https://bugs.openjdk.java.net/browse/JDK-8038970
webrev: http
On 8/11/14 12:48 PM, Pavel Rappo wrote:
Hi everyone,
Could you please review my change for JDK-8054857?
http://cr.openjdk.java.net/~prappo/8054857/webrev.00/
It's just a bunch of misspellings and typos in comments and javadoc.
Thanks for fixing those. Looks okay to me.
Mandy
On 8/11/14 2:15 PM, Ioi Lam wrote:
http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v3/
I would like to avoid adding private methods for VM to call
as fewer as possible.
SecureClassLoader.getProtectionDomain(URL)
Can you use the existing private getProtectionDomain(CodeSource)
On 8/11/2014 11:23 PM, David Holmes wrote:
Hi Mandy,
On 12/08/2014 9:01 AM, Mandy Chung wrote:
On 8/11/14 2:15 PM, Ioi Lam wrote:
http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v3/
I would like to avoid adding private methods for VM to call
as fewer as possible
Looks good. Nit: adding a space between catch and ( would be good.
Mandy
On 8/13/2014 5:43 AM, Daniel Fuchs wrote:
Please find below a fix for
8052403: java/util/logging/CheckZombieLockTest.java fails
with NoSuchFileException
https://bugs.openjdk.java.net/browse/JDK-8052403
The
On 8/18/14 12:08 AM, Amy Lu wrote:
There are two tests under jdk/test/java/util/Base64 that have
dependency on internal API sun.misc.BASE64Encoder sun.misc.BASE64Decoder
java/util/Base64/TestBase64Golden.java
java/util/Base64/TestBase64.java
This fix is to remove the internal API dependency
On 8/18/14 12:49 AM, Amy Lu wrote:
There are jdk tests that have dependency on sun.misc.DoubleConsts and
sun.misc.FloatConsts.
This fix is to remove above internal API dependency from the tests.
bug: https://bugs.openjdk.java.net/browse/JDK-8042003
webrev:
Pushed. Thanks for the contribution.
Mandy
On 8/19/14 6:40 AM, Amy Lu wrote:
Thank you Mandy and Sherman for your review.
I'll need your help to push this.
Thanks,
Amy
On 8/19/14, 1:31 AM, Mandy Chung wrote:
On 8/18/14 12:08 AM, Amy Lu wrote:
There are two tests under jdk/test/java/util
On 8/20/2014 2:03 AM, Evgeniya Stepanova wrote:
Update review request with links:
bug: https://bugs.openjdk.java.net/browse/JDK-8055393
webrev:http://cr.openjdk.java.net/~avstepan/eistepan/8055393/webrev.00/ http://cr.openjdk.java.net/%7Eavstepan/eistepan/8055393/webrev.00/
Looks okay to
On 8/20/2014 6:26 AM, Amy Lu wrote:
Patch updated:
http://cr.openjdk.java.net/~ewang/amylu/JDK-8042003/webrev.02/
test/java/lang/Double/ParseHexFloatingPoint.java
test/java/lang/Double/ToHexString.java
- they don't depend on DoubleConsts, do they?
Otherwise, looks good.
Mandy
On 8/20/2014 6:39 PM, Amy Lu wrote:
On 8/21/14, 8:54 AM, Mandy Chung wrote:
On 8/20/2014 6:26 AM, Amy Lu wrote:
Patch updated:
http://cr.openjdk.java.net/~ewang/amylu/JDK-8042003/webrev.02/
test/java/lang/Double/ParseHexFloatingPoint.java
No dependency on the new DoubleConsts.
Previous
Amy,
I have pushed your patch.
Mandy
On 8/22/14 2:54 PM, Joe Darcy wrote:
Hello,
Catching up on email; the .02 version looks good.
Thanks,
-Joe
On 08/21/2014 07:38 AM, Amy Lu wrote:
On 8/21/14, 9:56 AM, Mandy Chung wrote:
On 8/20/2014 6:39 PM, Amy Lu wrote:
On 8/21/14, 8:54 AM, Mandy
JDK-8055856: checkdeps build target doesn't work for cross-compilation builds
JDK-8056113: [build] tools.jar missing modules.xml
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055856/
This patch fixes a few things about modules.xml
1. jdeps is invoked at build time to verify
Erik, Magnus,
This is much easier than I have thought. I really like this new build.
I have separated out Gendata-jdk.dev.gmk and removed the modules-xml
target completely.
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055856/webrev.01/
Mandy
101 - 200 of 3165 matches
Mail list logo
