Re: 8029805/8029806: Remove XXX addPropertyChangeListener and removePropertyChangeListener methods
On 2013-12-10 12:06, Alan Bateman wrote:
(This one is for the jdk9-dev forest once it is created)
The addPropertyChangeListener and removePropertyChangeListener methods
defined by Pack200.{Packer,Unpacker} and LogManager methods are
deprecated and flagged with a warning that they will be removed in a
future release. This is highlighted in the EDR and Public Review of
JSR 337 and also flagged in JEP 162.
I'd like to swing the axe early in JDK 9 so as to give every
opportunity for anything that might have a dependency. There are a few
other modularity related changes that need to go in early too but this
is the only one that involves the removal of methods.
The webrev with the changes is here:
http://cr.openjdk.java.net/~alanb/8029805%2b8029806/webrev/
I'm glad to see this hackish stuff go away!
The build changes are mostly fine, however you remove the definition of
BEANLESS_CLASSES_TARGETS but do not remove it everywhere. While it will
work (expands to empty), it would be better if you fixed this line as well:
$(IMAGES_OUTPUTDIR)/lib$(PROFILE)/rt.jar:
$(IMAGES_OUTPUTDIR)/lib$(PROFILE)/_the.rt.jar.contents
$(RT_JAR_MANIFEST_FILE) $(PROFILE_VERSION_CLASS_TARGETS)
$(BEANLESS_CLASSES_TARGETS)
/Magnus
Re: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access order. (was Why doesn't new Map methods generate entry accesses on LinkedHashMap?)
On Dec 11, 2013, at 1:27 AM, Mike Duigou mike.dui...@oracle.com wrote:
I have added tests and documentation for the other methods.
http://cr.openjdk.java.net/~mduigou/JDK-8029795/1/webrev/
The documentation for some of the methods is ambiguous about how many access
events are generated. For LRU cache is OK but other cases (counting based
eviction) may care about the total number of accesses.
+ * invocation completes). Invoking the {@code replace}, {@code merge},
+ * {@code compute} or {@code computeIfPresent} methods results in one or more
+ * accesses of the corresponding entry. The {@code putAll} method generates one
If i look at the code for say replace it generates *at most one access* in
terms of affecting last access order, if the entry exists and if the old/new
value constraint holds:
@Override
public boolean replace(K key, V oldValue, V newValue) {
NodeK,V e; V v;
if ((e = getNode(hash(key), key)) != null
((v = e.value) == oldValue || (v != null v.equals(oldValue {
e.value = newValue;
afterNodeAccess(e);
return true;
}
return false;
}
I have attempted to categorise the access behaviour of each method:
get:
access to entry, if it exists
put:
access to new entry
putIfAbsent
access to entry, if it exists
otherwise access to new entry
replace(K key, V value)
access to entry, if it exists
replace(K key, V oldValue, V newValue)
access to entry, if it exists and it's value is updated
computeIfAbsent:
access to entry, if it exists and it's value is non-null, or
access to entry, if it exists and it's null value is updated to a non-null
value [*],
otherwise access to new entry, if created
computeIfPresent
access to entry, if it exists and it's non-null value is updated to a
non-null value
compute
access to entry, if it exists and it's value is updated to a non-null value,
otherwise access to new entry, if created
merge
access to entry, if it exists and it's value is updated to a non-null value,
otherwise access to new entry, if created
Patterns, to help group for documentation:
get/put/putIfAbsent/replace(K key, V value): access to entry associated with
the key, if entry exists after invocation completes
replace(K key, V oldValue, V newValue): access to entry associated with the
key, if returns true
computeIfAbsent/computeIfPresent/compute/merge: access to entry associated with
the key, if returns a non-null value.
--
[*] There is some ambiguity with computeIfAbsent. When the entry exists, it's
value is null, and the value returned from the mapping function is null then,
an access to that entry occurs:
V v = mappingFunction.apply(key);
if (old != null) {
old.value = v;
afterNodeAccess(old);
return v;
}
else if (v == null)
return null;
Is that a bug? I would have expected the returning of null from the mapping
function to signal no-action to be taken. Thus computeIfPresent and
computeIfAbsent have no side-effects for an existing entry whose value is null
when the function returns null (same applies to merge, if the value parameter
is null or the remapping function returns null, and to compute, if the
remapping function returns null).
So perhaps that code should be:
V v = mappingFunction.apply(key);
if (v == null)
return null;
else if (old != null) {
old.value = v;
afterNodeAccess(old);
return v;
}
Paul.
Re: 8029805/8029806: Remove XXX addPropertyChangeListener and removePropertyChangeListener methods
On 11/12/2013 10:03, Magnus Ihse Bursie wrote: I'm glad to see this hackish stuff go away! The build changes are mostly fine, however you remove the definition of BEANLESS_CLASSES_TARGETS but do not remove it everywhere. While it will work (expands to empty), it would be better if you fixed this line as well: $(IMAGES_OUTPUTDIR)/lib$(PROFILE)/rt.jar: $(IMAGES_OUTPUTDIR)/lib$(PROFILE)/_the.rt.jar.contents $(RT_JAR_MANIFEST_FILE) $(PROFILE_VERSION_CLASS_TARGETS) $(BEANLESS_CLASSES_TARGETS) Thanks, I noticed this later too and will make sure to remove all vestiges before pushing. -Alan
Re: 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
On 10/12/2013 18:37, Mandy Chung wrote: Alan, The change looks good. A minor one - in the class description of java.lang.SecurityManager, I suggest to remove the references to java.awt.AWTPermission line 143 and 214. Thanks Mandy. I left in these links as it's just a sample list of permissions but I don't have a strong opinion and I'm happy to remove them too. -Alan
Re: AWT Dev 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
Hi, Alan, the changes look fine to me. A short quick question: what is the reason to introduce a new AWTPermissions class as a holder for various AWTPermission constants? We can have the same fields directly in AWTPermission. The only difference is that AWTPermission is in java.awt, while the new class is in sun.awt, but such a change seem to require a CCC request anyway... Thanks, Artem On 12/10/2013 5:51 PM, Alan Bateman wrote: In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods checkTopLevelWindow, checkSystemClipboard and checkAccessAwtEventQueueAccess with a warning that they would be changed in a future release to check AllPermission. At the same time we changed the java.awt.Window and Toolkit methods to use checkPermission directly so that the legacy methods aren't used. The motive for all this is modules of course and the strong desire to remove the dependency on java.awt.AWTPermission. I'd like to get the second phase of this work into JDK 9 early to give every opportunity to find any potential issues. The second phase of this work changes the SecurityManager methods to check AllPermission and updates the implementation to remove the reflection hackery that was used to allow this code work without AWT being present (something that was needed for the profiles build). The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8029886/webrev/ The main thing that I'd like to get agreement on is the wording for the updated methods and also agreement from the AWT group to move the permission constants to a new class sun.awt.AWTPermissions. -Alan.
Re: AWT Dev 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
On 11/12/2013 13:17, Artem Ananiev wrote: Hi, Alan, the changes look fine to me. A short quick question: what is the reason to introduce a new AWTPermissions class as a holder for various AWTPermission constants? We can have the same fields directly in AWTPermission. The only difference is that AWTPermission is in java.awt, while the new class is in sun.awt, but such a change seem to require a CCC request anyway... Thanks Artem. Adding them to AWTPermission would bring them into Java SE / public API and that doesn't seem to be worth it. The main thing is that we move them out of sun.security.util.SecurityConstants so that we can finally eliminate the execution-time dependency (what we have in the jdk8 forest is okay for profiles but we need to do better with modules). -Alan.
Re: 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
On 12/10/2013 08:51 AM, Alan Bateman wrote: In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods checkTopLevelWindow, checkSystemClipboard and checkAccessAwtEventQueueAccess with a warning that they would be changed in a future release to check AllPermission. At the same time we changed the java.awt.Window and Toolkit methods to use checkPermission directly so that the legacy methods aren't used. The motive for all this is modules of course and the strong desire to remove the dependency on java.awt.AWTPermission. I'd like to get the second phase of this work into JDK 9 early to give every opportunity to find any potential issues. The second phase of this work changes the SecurityManager methods to check AllPermission and updates the implementation to remove the reflection hackery that was used to allow this code work without AWT being present (something that was needed for the profiles build). The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8029886/webrev/ The main thing that I'd like to get agreement on is the wording for the updated methods and also agreement from the AWT group to move the permission constants to a new class sun.awt.AWTPermissions. The code changes and suggested wording for the updated methods look fine to me. Please add a release-note=yes label to the issue. The permissions security guide will also need to be updated with the new behavior of these methods: http://download.java.net/jdk8/docs/technotes/guides/security/permissions.html#PermsAndMethods -- I suggest adding a comment indicating that so we remember to update the docs as part of writing the release notes task. --Sean
Re: 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
On 11/12/2013 16:16, Sean Mullan wrote: The code changes and suggested wording for the updated methods look fine to me. Please add a release-note=yes label to the issue. The permissions security guide will also need to be updated with the new behavior of these methods: http://download.java.net/jdk8/docs/technotes/guides/security/permissions.html#PermsAndMethods -- I suggest adding a comment indicating that so we remember to update the docs as part of writing the release notes task. Thanks for the pointer to that guide, I wasn't aware for it (and now that I read it then I see that it is out of date, the changes that are you suggesting we need to remember are required now because those methods had their spec changes in 8 to use checkPermission directly). -Alan
RFR (JAXP) 8029895 : XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification
Hi, This is a quick documentation change to fix an error in javax.xml.stream.XMLOutputFactory: http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/ Thanks, Joe
RFR: JDK 9: 8024033: [launcher] remove solaris dual mode support
Hello Joe, Martin, et. al., In JDK8, solaris 32-bit support was removed entirely, this is the only platform that required dual-mode support, ie. 32-bit and 64-bit binaries co-located in the same binary hierarchy on the disk. In JDK 8 the DUAL_MODE support was disabled in the launcher, using compile time conditionals, however in JDK9 we wish to remove the logic entirely, this is messy and makes the launcher cleaner and easier to maintain. Webrev: http://cr.openjdk.java.net/~ksrini/8024033/webrev.0/ Thanks Kumar
Re: RFR (JAXP) 8029895 : XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification
On 12/11/13 8:52 PM, huizhe wang wrote: Hi, This is a quick documentation change to fix an error in javax.xml.stream.XMLOutputFactory: http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/ Thanks, Joe Hi Joe, Looks good to me - but I'm not a native English speaker :-) -- daniel
Re: RFR (JAXP) 8029895 : XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification
On 11/12/2013 19:52, huizhe wang wrote: Hi, This is a quick documentation change to fix an error in javax.xml.stream.XMLOutputFactory: http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/ Thanks, Joe It looks okay although I think it could be reduced to something like The original method was incorrectly defined to return XMLInputFactory. -Alan.
hg: jdk8/tl/langtools: 8029558: java.lang.VerifyError: Bad return type when lambda's body is in parentheses
Changeset: 847cc0cccfa1 Author:rfield Date: 2013-12-11 11:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/847cc0cccfa1 8029558: java.lang.VerifyError: Bad return type when lambda's body is in parentheses Summary: properly type convert the body of a lambda expression Reviewed-by: vromero ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/lambda/LambdaParenGeneric.java + test/tools/javac/lambda/LambdaParenGenericOrig.java
Re: RFR (JAXP) 8029895 : XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification
On 12/11/2013 12:21 PM, Alan Bateman wrote: On 11/12/2013 19:52, huizhe wang wrote: Hi, This is a quick documentation change to fix an error in javax.xml.stream.XMLOutputFactory: http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/ Thanks, Joe It looks okay although I think it could be reduced to something like The original method was incorrectly defined to return XMLInputFactory. Updated to use your statement: http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/ -Joe -Alan.
Re: RFR: JDK 9: 8024033: [launcher] remove solaris dual mode support
On 12/11/2013 12:25 PM, Martin Buchholz wrote: Although I have a small emotional attachment to the idea of fat binaries, there doesn't seem to be too much support for this in the larger java community, and probably the larger unix community will be 64-bit only relatively soon. So ... OK. There's one remaining mention of LD_LIBRARY_PATH_32. Maybe you want to scrub that as well? 589 (void)UnsetEnv((wanted == 32) ? LD_LIBRARY_PATH_32 : LD_LIBRARY_PATH_64); Good catch I will scrub that. Thanks Martin. Kumar On Wed, Dec 11, 2013 at 12:08 PM, Kumar Srinivasan kumar.x.sriniva...@oracle.com mailto:kumar.x.sriniva...@oracle.com wrote: Hello Joe, Martin, et. al., In JDK8, solaris 32-bit support was removed entirely, this is the only platform that required dual-mode support, ie. 32-bit and 64-bit binaries co-located in the same binary hierarchy on the disk. In JDK 8 the DUAL_MODE support was disabled in the launcher, using compile time conditionals, however in JDK9 we wish to remove the logic entirely, this is messy and makes the launcher cleaner and easier to maintain. Webrev: http://cr.openjdk.java.net/~ksrini/8024033/webrev.0/ http://cr.openjdk.java.net/%7Eksrini/8024033/webrev.0/ Thanks Kumar
Re: RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests (activation and others)
On 12/10/13 6:10 PM, Tristan Yan wrote: /Hi everyone I am working on bug JDK-7168267 https://bugs.openjdk.java.net/browse/JDK-6963118 . Correct link is https://bugs.openjdk.java.net/browse/JDK-7168267 Root Cause: - Per Stuart's comment, this is a clean up bug. Suggested Fix: - Will use timeout to replace loop. We should probably look at specific cases for this. There are places where the test is waiting for some external service to become ready (e.g., rmiregistry). There's no notification for things like this so wait-with-timeout cannot be used. Pretty much the only thing that can be done is to poll reasonably often until the service is ready, or until the timeout is exceeded. - Also I am fixing two test's performance java/rmi/activation/Activatable/forceLogSnapshot - method waitAllStarted is using sleep to poll 50 restartedObject to be true, we can use modern CountDownLatch to implement blocking-time wait. java/rmi/activation/Activatable/checkAnnotations - We can subclass ByteArrayOutputStream which support notification when data was written. Also use two thread wait output string and error string to be not null. These sound reasonble. Go ahead and file sub-tasks for these and then choose one to work on first. (I think it will get too confusing if we try to work on them all simultaneously.) Either post a detailed description of what you intend to do, or if it's simple enough, just post a webrev. s'marks Please let me know if you have any comments or suggestions. / / Thank you Tristan On 12/05/2013 09:02 AM, Stuart Marks wrote: / /On 12/3/13 11:05 PM, Tristan Yan wrote: / /I am working on https://bugs.openjdk.java.net/browse/JDK-7168267. This bug is asking performance improvement for RMI test. Because this would involve different RMI tests. I’d like to use this cr as an umbrella bug, create sub-cr for different test. Then I can make progress on sub-cr. Please let me know your opinion on this. / / Actually JDK-7168267 is more about various test cleanups, and JDK-8005436 is more about performance. Both bugs, though, make general statements about the RMI tests and don't have much information about specific actions that need to be taken. I've added some notes to JDK-7168267 about some cleanups that could be done. / / If there are specific actions for either of these bugs, then yes, creating Sub-Tasks of these bugs and fixing them individually is the right thing to do. / / s'marks / / /
Re: RFR (JAXP) 8029895 : XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification
looks fine joe On Dec 11, 2013, at 4:10 PM, huizhe wang wrote: On 12/11/2013 12:21 PM, Alan Bateman wrote: On 11/12/2013 19:52, huizhe wang wrote: Hi, This is a quick documentation change to fix an error in javax.xml.stream.XMLOutputFactory: http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/ Thanks, Joe It looks okay although I think it could be reduced to something like The original method was incorrectly defined to return XMLInputFactory. Updated to use your statement: http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/ -Joe -Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: [8] WXP minor fixes for a cleaner compile of c code
I have filed https://bugs.openjdk.java.net/browse/JDK-8030010 to clean
up these warning and I can sponsor it.
Mandy
On 12/10/2013 11:17 PM, Staffan Larsen wrote:
I see you were directed here from the build-dev list. Unfortunately these are
core library fixes, not hotspot fixes. I’ve added core-libs and bcc:d
hotspot-dev.
Thanks,
/Staffan
On 11 dec 2013, at 07:34, Francis ANDRE francis.andre.kampb...@orange.fr
wrote:
Hi
Below are some warnings produced by the build of jdk8.
Z:/JDK/jdk8/jdk/src/share/native/java/lang/Throwable.c(48) : warning C4028:
paramétre formel 3 différent de la déclaration
Z:/JDK/jdk8/jdk/src/windows/native/java/io/WinNTFileSystem_md.c(363) : warning
C4101: 'pathlen': variable locale non référencée
Z:/JDK/jdk8/jdk/src/windows/native/common/jdk_util_md.c(45) : warning C4101:
'ret': variable locale non référencée
Z:/JDK/jdk8/jdk/src/share/bin/java.c(1253) : warning C4101: 'result': variable
locale nonréférencée
Z:/JDK/jdk8/jdk/src/share/bin/parse_manifest.c(196) : warning C4244: 'fonction':
conversion de 'jlong' en 'unsigned int', perte possible de données
And here are the fixes
diff --git a/src/share/bin/java.c b/src/share/bin/java.c
--- a/src/share/bin/java.c
+++ b/src/share/bin/java.c
@@ -1250,7 +1250,6 @@
GetApplicationClass(JNIEnv *env)
{
jmethodID mid;
-jobject result;
jclass cls = GetLauncherHelperClass(env);
NULL_CHECK0(cls);
NULL_CHECK0(mid = (*env)-GetStaticMethodID(env, cls,
diff --git a/src/share/bin/parse_manifest.c b/src/share/bin/parse_manifest.c
--- a/src/share/bin/parse_manifest.c
+++ b/src/share/bin/parse_manifest.c
@@ -193,7 +193,7 @@
return (-1);
if ((buffer = malloc(END_MAXLEN)) == NULL)
return (-1);
-if ((bytes = read(fd, buffer, len)) 0) {
+if ((bytes = read(fd, buffer, (size_t)len)) 0) {
free(buffer);
return (-1);
}
diff --git a/src/share/native/java/lang/Throwable.c
b/src/share/native/java/lang/Throwable.c
--- a/src/share/native/java/lang/Throwable.c
+++ b/src/share/native/java/lang/Throwable.c
@@ -44,7 +44,7 @@
* `this' so you can write 'throw e.fillInStackTrace();'
*/
JNIEXPORT jobject JNICALL
-Java_java_lang_Throwable_fillInStackTrace(JNIEnv *env, jobject throwable, int
dummy)
+Java_java_lang_Throwable_fillInStackTrace(JNIEnv *env, jobject throwable, jint
dummy)
{
JVM_FillInStackTrace(env, throwable);
return throwable;
diff --git a/src/windows/native/common/jdk_util_md.c
b/src/windows/native/common/jdk_util_md.c
--- a/src/windows/native/common/jdk_util_md.c
+++ b/src/windows/native/common/jdk_util_md.c
@@ -42,7 +42,6 @@
JNIEXPORT HMODULE JDK_LoadSystemLibrary(const char* name) {
HMODULE handle = NULL;
char path[MAX_PATH];
-int ret;
if (GetSystemDirectory(path, sizeof(path)) != 0) {
strcat(path, \\);
diff --git a/src/windows/native/java/io/WinNTFileSystem_md.c
b/src/windows/native/java/io/WinNTFileSystem_md.c
--- a/src/windows/native/java/io/WinNTFileSystem_md.c
+++ b/src/windows/native/java/io/WinNTFileSystem_md.c
@@ -360,7 +360,6 @@
jobject file)
{
jint rv = 0;
-jint pathlen;
WCHAR *pathbuf = fileToNTPath(env, file, ids.path);
if (pathbuf == NULL)
RFR: 8027536: rmic: add deprecation warning message
Hi all, Just one more deprecation task for JDK 8 Please review the following change to rmic to add a warning message that's emitted when static stubs are generated: http://cr.openjdk.java.net/~smarks/reviews/8027536/webrev.0/ https://bugs.openjdk.java.net/browse/JDK-8027536 Thanks, s'marks
hg: jdk8/tl/jdk: 8029551: Add value-type notice to java.time classes
Changeset: fe3383582427 Author:rriggs Date: 2013-12-11 16:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe3383582427 8029551: Add value-type notice to java.time classes Summary: Add warning about identity of value types and reference to ValueBased.html Reviewed-by: briangoetz, smarks, scolebourne ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java
Re: RFR: 8027536: rmic: add deprecation warning message
On 12/11/2013 1:53 PM, Stuart Marks wrote: Hi all, Just one more deprecation task for JDK 8 Please review the following change to rmic to add a warning message that's emitted when static stubs are generated: http://cr.openjdk.java.net/~smarks/reviews/8027536/webrev.0/ The change looks okay. The error(...) method is called to print warnings seems to be confusing. Perhaps better to call output(getText()) directly? Mandy https://bugs.openjdk.java.net/browse/JDK-8027536 Thanks, s'marks
Re: RFR: 8027536: rmic: add deprecation warning message
On 12/11/2013 2:25 PM, Mandy Chung wrote: On 12/11/2013 1:53 PM, Stuart Marks wrote: Hi all, Just one more deprecation task for JDK 8 Please review the following change to rmic to add a warning message that's emitted when static stubs are generated: http://cr.openjdk.java.net/~smarks/reviews/8027536/webrev.0/ The change looks okay. The error(...) method is called to print warnings seems to be confusing. Perhaps better to call output(getText()) directly? One other note: AFAIK the last message drop for jdk8 localization was done. It means that the Japanese and Chinese version will not be updated matching your patch. It's okay for the new warning message as it will fall back to the default English version. For the existing -v1.1, -vcompat, -v1.2 options, the Japanese and Chinese version will not have (deprecated) word in it. I suggest to edit the other localized versions to update the modified existing messages. Mandy
RFR: JDK9: 8029388: java.exe consumes argument intended for launched java class
Hello, Please review a fix for Windows launcher where it consumes application args -d32 and -d64, the fix is to stop the scan when it hits the Application sentinel ie. class-name or jar-name. http://cr.openjdk.java.net/~ksrini/8029388/webrev.0/ Thanks Kumar
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 1298e476729c Author:michaelm Date: 2013-12-11 15:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1298e476729c 8029944: Primitive Stream reduce method documentation pseudo code misidentifies apply method Reviewed-by: mduigou Contributed-by: michael.mcma...@oracle.com ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java Changeset: 1970e3c3d202 Author:michaelm Date: 2013-12-11 15:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1970e3c3d202 8029696: Broken doc links to package-summary.html#NonInterference in java.util.stream Reviewed-by: mduigou ! src/share/classes/java/util/stream/StreamSupport.java ! src/share/classes/java/util/stream/package-info.java
Re: RFR: 8027536: rmic: add deprecation warning message
Should this be a warning or error? Darryl On 12/11/2013 01:53 PM, Stuart Marks wrote: Hi all, Just one more deprecation task for JDK 8 Please review the following change to rmic to add a warning message that's emitted when static stubs are generated: http://cr.openjdk.java.net/~smarks/reviews/8027536/webrev.0/ https://bugs.openjdk.java.net/browse/JDK-8027536 Thanks, s'marks
Re: RFR: JDK9: 8029388: java.exe consumes argument intended for launched java class
On 12/11/2013 3:21 PM, Kumar Srinivasan wrote: Hello, Please review a fix for Windows launcher where it consumes application args -d32 and -d64, the fix is to stop the scan when it hits the Application sentinel ie. class-name or jar-name. http://cr.openjdk.java.net/~ksrini/8029388/webrev.0/ Nit: can we start checking from argv[1] and skip argv[0]? line 194 no need to check i 0 then. Nit: line 95 - an extra space before dmodel. A general question - doExec handles the case when the cmd terminates with an exception. I was wondering if the generated Args class should just throw an exception if it doesn't match the expected value (i.e. have Args class to do the verification). I pondered a little bit when reading the verifyOption method before I read the createOptionsJar method. Otherwise, looks good. Mandy
Re: RFR: JDK9: 8029388: java.exe consumes argument intended for launched java class
Mandy, Thanks for the review. On 12/11/2013 3:21 PM, Kumar Srinivasan wrote: Hello, Please review a fix for Windows launcher where it consumes application args -d32 and -d64, the fix is to stop the scan when it hits the Application sentinel ie. class-name or jar-name. http://cr.openjdk.java.net/~ksrini/8029388/webrev.0/ Nit: can we start checking from argv[1] and skip argv[0]? line 194 no need to check i 0 then. Yes, we can start from 1 instead of 0. Nit: line 95 - an extra space before dmodel. A general question - doExec handles the case when the cmd Will fix that. terminates with an exception. I was wondering if the generated Args class should just throw an exception if it doesn't match the expected value (i.e. have Args class to do the verification). I pondered a little bit when reading the verifyOption method before I read the createOptionsJar method. I have tried to keep the generated classes as simple as possible, compilation failures and errors in these are hard to track down. Kumar Otherwise, looks good. Mandy
hg: jdk8/tl/jdk: 8026115: [zh_CN] inproper translation in output of jarsigner command
Changeset: 01b11184bcf9 Author:mfang Date: 2013-12-11 21:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b11184bcf9 8026115: [zh_CN] inproper translation in output of jarsigner command Reviewed-by: naoto, yhuang ! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java
RFR: 8030016: HashMap.computeIfAbsent generates spurious access event
Hello all; In the review for JDK-8029795 Paul Sandoz noted that HashMap.computeIfAbsent would generate a spurious access event for keys mapped to null when the function returned null. This patch corrects that behaviour. http://cr.openjdk.java.net/~mduigou/JDK-8030016/0/webrev/ The actual regression test is LinkedHashMap/ComputeIfAbsentAccessOrder.java whereas the changes to Map/Defaults are improvements to the existing tests suggested by this bug (though they would not detect it). Cheers, Mike
hg: jdk8/tl/nashorn: 3 new changesets
Changeset: 4706897b4dec Author:attila Date: 2013-12-09 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4706897b4dec 8029467: Widening of booleans causes bad results Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8029467.js + test/script/basic/JDK-8029467.js.EXPECTED Changeset: 18edd7a1b166 Author:lagergren Date: 2013-12-11 18:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/18edd7a1b166 8029780: ant externals broke our test harness with the latest version of the octane benchmarks Reviewed-by: attila, sundar ! make/build-benchmark.xml ! test/script/basic/compile-octane-splitter.js.EXPECTED ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js Changeset: e452a3797290 Author:sundar Date: 2013-12-12 09:18 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e452a3797290 Merge
Re: RFR: JDK 9: 8024033: [launcher] remove solaris dual mode support
Hi Kumar, Will be glad to see this feature purged from the sources! I believe the comments on lines 135 to 167 in the new file still need some updating. The comment block on line 261 - 273 may need revising too. Otherwise, looks fine. Thanks, -Joe On 12/11/2013 01:12 PM, Kumar Srinivasan wrote: On 12/11/2013 12:25 PM, Martin Buchholz wrote: Although I have a small emotional attachment to the idea of fat binaries, there doesn't seem to be too much support for this in the larger java community, and probably the larger unix community will be 64-bit only relatively soon. So ... OK. There's one remaining mention of LD_LIBRARY_PATH_32. Maybe you want to scrub that as well? 589 (void)UnsetEnv((wanted == 32) ? LD_LIBRARY_PATH_32 : LD_LIBRARY_PATH_64); Good catch I will scrub that. Thanks Martin. Kumar On Wed, Dec 11, 2013 at 12:08 PM, Kumar Srinivasan kumar.x.sriniva...@oracle.com mailto:kumar.x.sriniva...@oracle.com wrote: Hello Joe, Martin, et. al., In JDK8, solaris 32-bit support was removed entirely, this is the only platform that required dual-mode support, ie. 32-bit and 64-bit binaries co-located in the same binary hierarchy on the disk. In JDK 8 the DUAL_MODE support was disabled in the launcher, using compile time conditionals, however in JDK9 we wish to remove the logic entirely, this is messy and makes the launcher cleaner and easier to maintain. Webrev: http://cr.openjdk.java.net/~ksrini/8024033/webrev.0/ http://cr.openjdk.java.net/%7Eksrini/8024033/webrev.0/ Thanks Kumar
