JDK 9 RFR of JDK-8039038: Fix serial lint warnings in com.sun.jmx.snmp
Hello,
*fingers crossed* The patch below should be the last change needed to
fully clear the JDK 9 jdk repo of serialization warnings.
Thanks,
-Joe
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/Enumerated.java
--- a/src/share/classes/com/sun/jmx/snmp/Enumerated.javaTue Apr 01
09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/Enumerated.javaTue Apr 01
23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1999, 2012, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -45,7 +45,7 @@
* pbThis API is a Sun Microsystems internal API and is subject
* to change without notice./b/p
*/
-
+@SuppressWarnings(serial) // JDK implementation class
abstract public class Enumerated implements Serializable {
/**
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java
--- a/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.javaTue Apr 01
09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.javaTue Apr 01
23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -44,6 +44,7 @@
* The class defines an abstract representation of a host.
*
*/
+@SuppressWarnings(serial) // JDK implementation class
abstract class Host extends SimpleNode implements Serializable {
public Host(int id) {
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpPdu.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpPdu.javaTue Apr 01
09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpPdu.javaTue Apr 01
23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -45,6 +45,7 @@
*
* @since 1.5
*/
+@SuppressWarnings(serial) // JDK implementation class
public abstract class SnmpPdu implements SnmpDefinitions, Serializable {
/**
diff -r b6997dd0667e
src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue
Apr 01 09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue
Apr 01 23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -47,6 +47,7 @@
*
* @since 1.5
*/
+@SuppressWarnings(serial) // JDK implementation class
public abstract class SnmpScopedPduPacket extends SnmpPdu
implements Serializable {
/**
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.javaTue Apr
01 09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.javaTue Apr
01 23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -34,7 +34,7 @@
* pbThis API is a Sun Microsystems internal API and is subject
* to change without notice./b/p
*/
-
+@SuppressWarnings(serial) // JDK implementation class
public abstract class SnmpUnsignedInt extends SnmpInt {
/**
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpValue.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpValue.javaTue Apr 01
09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpValue.javaTue Apr 01
23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -38,7 +38,7 @@
* pbThis API is a Sun Microsystems internal API and is subject
* to change without notice./b/p
*/
-
+@SuppressWarnings(serial) // JDK implementation class
public abstract class
Re: JDK 9 RFR of 8039022: Fix serial lint warnings in sun.tools.java
On 02/04/2014 00:20, Joe Darcy wrote: Hello, The plague of serial warnings in the jdk repo is nearly eradicated. Please review the fix below if address to a few of the holdouts. This looks okay, assuming of course that none of these types leak into the serialized form by some other means. -Alan.
Re: JDK 9 RFR of 8039027: Fix serial lint warnings in jconsole and jstat
On 02/04/2014 02:20, Joe Darcy wrote: Hello, With the serial warnings cleanup of the JDK drawing to completion, please review the patch below which addresses some lingering issues in jconsole and jstat. This looks okay too. -Alan
Re: JDK 9 RFR of JDK-8039038: Fix serial lint warnings in com.sun.jmx.snmp
On 02/04/2014 07:39, Joe Darcy wrote: Hello, *fingers crossed* The patch below should be the last change needed to fully clear the JDK 9 jdk repo of serialization warnings. Thanks, -Joe This looks okay too. -Alan
Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd UNIXProcess.java.linux ( .solaris .aix)
On 01/04/2014 23:40, Martin Buchholz wrote: So I rather like having different LaunchMechanisms available on different platforms - just the default would be different. fork should work everywhere. I agree that is important to keep the ability to configure this, it was particularly useful with the transition from fork1 to posix_spawn on OS X and Solaris where it needed time to be completely confident that there aren't side effects or subtle behavior differences. -Alan.
Re: JDK 9 RFR of JDK-8039038: Fix serial lint warnings in com.sun.jmx.snmp
On 4/2/14 8:39 AM, Joe Darcy wrote:
Hello,
*fingers crossed* The patch below should be the last change needed to
fully clear the JDK 9 jdk repo of serialization warnings.
Looks good Joe!
best regards,
-- daniel
Thanks,
-Joe
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/Enumerated.java
--- a/src/share/classes/com/sun/jmx/snmp/Enumerated.javaTue Apr 01
09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/Enumerated.javaTue Apr 01
23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1999, 2012, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -45,7 +45,7 @@
* pbThis API is a Sun Microsystems internal API and is subject
* to change without notice./b/p
*/
-
+@SuppressWarnings(serial) // JDK implementation class
abstract public class Enumerated implements Serializable {
/**
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java
--- a/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.javaTue Apr 01
09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.javaTue Apr 01
23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -44,6 +44,7 @@
* The class defines an abstract representation of a host.
*
*/
+@SuppressWarnings(serial) // JDK implementation class
abstract class Host extends SimpleNode implements Serializable {
public Host(int id) {
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpPdu.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpPdu.javaTue Apr 01
09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpPdu.javaTue Apr 01
23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -45,6 +45,7 @@
*
* @since 1.5
*/
+@SuppressWarnings(serial) // JDK implementation class
public abstract class SnmpPdu implements SnmpDefinitions, Serializable {
/**
diff -r b6997dd0667e
src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue
Apr 01 09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue
Apr 01 23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -47,6 +47,7 @@
*
* @since 1.5
*/
+@SuppressWarnings(serial) // JDK implementation class
public abstract class SnmpScopedPduPacket extends SnmpPdu
implements Serializable {
/**
diff -r b6997dd0667e
src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.javaTue Apr
01 09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.javaTue Apr
01 23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -34,7 +34,7 @@
* pbThis API is a Sun Microsystems internal API and is subject
* to change without notice./b/p
*/
-
+@SuppressWarnings(serial) // JDK implementation class
public abstract class SnmpUnsignedInt extends SnmpInt {
/**
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpValue.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpValue.javaTue Apr 01
09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpValue.javaTue Apr 01
23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -38,7 +38,7 @@
* pbThis API is a Sun Microsystems internal API and is subject
* to change without
Re: Implicit 'this' return for void methods
On 04/01/2014 10:20 PM, Eirik Lygre wrote: What is the relationship between this naked dot proposal and the chaining of void methods proposal? The reason for asking is not to be negative, but rather to find out if these issues are best dealt with together, or as independent proposals. I think that if either of these are going to happen, then they must be specified with the appropriate level of isolation: That which belongs together must be processed together; that which belongs apart must be processed apart. Point taken, but Project Coin (small language changes) worked well. Andrew.
RFR: 8035618 : Four api/org_omg/CORBA TCK tests fail under plugin only
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 the boot strap JDK for CORBA. Direct access to the sun.awt.AppContect class has been removed. bug : https://bugs.openjdk.java.net/browse/JDK-8035618 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8035618.jdk9.v3/webrev/ Regards, Sean.
Re: JDK 9 RFR of JDK-8039038: Fix serial lint warnings in com.sun.jmx.snmp
+1
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPad
On Apr 2, 2014, at 2:39 AM, Joe Darcy joe.da...@oracle.com wrote:
Hello,
*fingers crossed* The patch below should be the last change needed to fully
clear the JDK 9 jdk repo of serialization warnings.
Thanks,
-Joe
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/Enumerated.java
--- a/src/share/classes/com/sun/jmx/snmp/Enumerated.javaTue Apr 01
09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/Enumerated.javaTue Apr 01
23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1999, 2012, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -45,7 +45,7 @@
* pbThis API is a Sun Microsystems internal API and is subject
* to change without notice./b/p
*/
-
+@SuppressWarnings(serial) // JDK implementation class
abstract public class Enumerated implements Serializable {
/**
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java
--- a/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.javaTue Apr 01
09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.javaTue Apr 01
23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -44,6 +44,7 @@
* The class defines an abstract representation of a host.
*
*/
+@SuppressWarnings(serial) // JDK implementation class
abstract class Host extends SimpleNode implements Serializable {
public Host(int id) {
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpPdu.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpPdu.javaTue Apr 01 09:12:51
2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpPdu.javaTue Apr 01 23:36:42
2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -45,6 +45,7 @@
*
* @since 1.5
*/
+@SuppressWarnings(serial) // JDK implementation class
public abstract class SnmpPdu implements SnmpDefinitions, Serializable {
/**
diff -r b6997dd0667e
src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue Apr 01
09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue Apr 01
23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -47,6 +47,7 @@
*
* @since 1.5
*/
+@SuppressWarnings(serial) // JDK implementation class
public abstract class SnmpScopedPduPacket extends SnmpPdu
implements Serializable {
/**
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.javaTue Apr 01
09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.javaTue Apr 01
23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -34,7 +34,7 @@
* pbThis API is a Sun Microsystems internal API and is subject
* to change without notice./b/p
*/
-
+@SuppressWarnings(serial) // JDK implementation class
public abstract class SnmpUnsignedInt extends SnmpInt {
/**
diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpValue.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpValue.javaTue Apr 01
09:12:51 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpValue.javaTue Apr 01
23:36:42 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR
Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd UNIXProcess.java.linux ( .solaris .aix)
On 04/01/2014 09:47 PM, roger riggs wrote: Hi, A minor point, but the Enum for LaunchMechanism can be simpler; the defined enum values (1,2,3) are never used and can be removed along with the extra constructor. They are used for the mode parameter of forkAndExec() native method. With the refactoring so f0ar, this seems more complex and harder to understand. Are you comparing webrev.03 with webrev.04 or original code with webrev.0[34] ? I agree that one individual original source is simpler than merged single source, but there are 4 of them to be kept in-sync and still be different in places. I find it more convenient to see the differences in one place without using a diff tool pair-wisely. It's also friendlier to IDEs if they understand the code instead of just treating those 4 files as texts. Some of the IDEs can be teached to understand the various (.java.bsd, .java.linux, .java.solaris, .java.aix) extensions as Java sources, but then they get confused because they see 4 sources for the same class... At least in the non-merged version all (and only) the code for a platform was in a single class. The static UNIXProcess subclasses for the various platforms are always kept around. We could bring them to the upper level as package-private subclasses and arrange in makefile to just include the ones that are needed. But then this knowledge of mapping is in two places: the makefiles and the code. Other alternatives would have been to factor the common code (Streams handling) into a utilities class or ProcessImpl and retain the 1st class subclasses (with different names) for each platform or merge more up into ProcessImpl. Maybe it will be clearer with additional refactoring. As I said, I believe the consolidation of various Input/OutputStream wrappers could bring the class files number and size further down. $.02, Roger If you're concerned about class files included in the distributable, but not used, we can compensate this a bit by reducing the number of anonymous inner classes generated by javac just by replacing them with lambdas. Here's new webrev that does that too: http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.05/ If UNIXProcess.java in above webrev is compiled, the following class files are produced: -rw-rw-r--. 1 peter peter 772 Apr 2 12:33 UNIXProcess$1.class// SwitchMap for Platform enum -rw-rw-r--. 1 peter peter 2706 Apr 2 12:33 UNIXProcess$AixProcess.class -rw-rw-r--. 1 peter peter 2155 Apr 2 12:33 UNIXProcess$DeferredCloseInputStream.class -rw-rw-r--. 1 peter peter 2930 Apr 2 12:33 UNIXProcess$DeferredCloseProcessPipeInputStream.class -rw-rw-r--. 1 peter peter 1166 Apr 2 12:33 UNIXProcess$LaunchMechanism.class -rw-rw-r--. 1 peter peter 2701 Apr 2 12:33 UNIXProcess$LinuxOrBsdProcess.class -rw-rw-r--. 1 peter peter 4762 Apr 2 12:33 UNIXProcess$Platform.class -rw-rw-r--. 1 peter peter 1711 Apr 2 12:33 UNIXProcess$ProcessPipeInputStream.class -rw-rw-r--. 1 peter peter 949 Apr 2 12:33 UNIXProcess$ProcessPipeOutputStream.class -rw-rw-r--. 1 peter peter 1902 Apr 2 12:33 UNIXProcess$ProcessReaperThreadFactory.class -rw-rw-r--. 1 peter peter 2935 Apr 2 12:33 UNIXProcess$SolarisProcess.class -rw-rw-r--. 1 peter peter 6260 Apr 2 12:33 UNIXProcess.class ...12 class files totaling 30.2 KiB. If original UNIXProcess.java.linux is compiled, for example, the following files are produced: -rw-rw-r--. 1 peter peter 1648 Apr 2 12:25 UNIXProcess$1.class -rw-rw-r--. 1 peter peter 926 Apr 2 12:25 UNIXProcess$2.class -rw-rw-r--. 1 peter peter 865 Apr 2 12:25 UNIXProcess$3.class -rw-rw-r--. 1 peter peter 648 Apr 2 12:25 UNIXProcess$4.class -rw-rw-r--. 1 peter peter 1200 Apr 2 12:25 UNIXProcess$LaunchMechanism.class -rw-rw-r--. 1 peter peter 1711 Apr 2 12:25 UNIXProcess$ProcessPipeInputStream.class -rw-rw-r--. 1 peter peter 949 Apr 2 12:25 UNIXProcess$ProcessPipeOutputStream.class -rw-rw-r--. 1 peter peter 939 Apr 2 12:25 UNIXProcess$ProcessReaperThreadFactory$1.class -rw-rw-r--. 1 peter peter 1233 Apr 2 12:25 UNIXProcess$ProcessReaperThreadFactory.class -rw-rw-r--. 1 peter peter 5626 Apr 2 12:25 UNIXProcess.class ...10 class files totaling 15,4 KiB So it's ~15 KiB that we are talking about at this moment. Regards, Peter On 4/1/2014 1:04 PM, Peter Levart wrote: On 04/01/2014 05:43 PM, Peter Levart wrote: On 04/01/2014 03:49 PM, roger riggs wrote: Hi Peter, The design using enum for the os dependencies does not make it possible to include only the support needed for a particular platform at build time. Every implementation will be carrying around the support for all the other platforms. A build time binding would be more efficient. Roger That's true. A trade-off between maintainability and efficiency. The efficiency has two categories here. One is the size of the distributable and the other is run-time efficiency. I've been thinking to improve both efficiencies (the run-time
RFR: 8038306: (tz) Support tzdata2014b
Hello, Can I have a review for the latest (2014b) TZ data integration to JDK9. The webrev can be located here [1]. The following set of tests were executed without failures: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter test/closed/java/util/Calendar\ test/closed/java/util/TimeZone Thank you, Aleksej [1] Webrev: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.00/ [2] BUG: https://bugs.openjdk.java.net/browse/JDK-8038306
Re: Implicit 'this' return for void methods
Hi, Am 02.04.2014 11:08, schrieb Andrew Haley: On 04/01/2014 10:20 PM, Eirik Lygre wrote: What is the relationship between this naked dot proposal and the chaining of void methods proposal? The reason for asking is not to be negative, but rather to find out if these issues are best dealt with together, or as independent proposals. I think that if either of these are going to happen, then they must be specified with the appropriate level of isolation: That which belongs together must be processed together; that which belongs apart must be processed apart. Point taken, but Project Coin (small language changes) worked well. Andrew. If that would help to make things happen, I support the idea to separate both steps to different proposals. -Ulf
Re: Implicit 'this' return for void methods
On 04/02/2014 11:58 AM, Ulf Zibis wrote: Hi, Am 02.04.2014 11:08, schrieb Andrew Haley: On 04/01/2014 10:20 PM, Eirik Lygre wrote: What is the relationship between this naked dot proposal and the chaining of void methods proposal? The reason for asking is not to be negative, but rather to find out if these issues are best dealt with together, or as independent proposals. I think that if either of these are going to happen, then they must be specified with the appropriate level of isolation: That which belongs together must be processed together; that which belongs apart must be processed apart. Point taken, but Project Coin (small language changes) worked well. If that would help to make things happen, I support the idea to separate both steps to different proposals. Here's how it works: Start a project to do small language changes, or join an existing one. Form an EG for the JSR. It may be be that there is already a suitable JSR in progress. Discuss. Make spec changes, make an implementation, make TCK changes. Propose the change to the umbrella Java SE EG for inclusion in JDK N. If this sounds like a lot of work, that's because it is. Andrew.
Re: i18n dev RFR: 8038306: (tz) Support tzdata2014b
Looks fine to me. regards, Sean. On 02/04/14 11:55, Aleksej Efimov wrote: Hello, Can I have a review for the latest (2014b) TZ data integration to JDK9. The webrev can be located here [1]. The following set of tests were executed without failures: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter test/closed/java/util/Calendar\ test/closed/java/util/TimeZone Thank you, Aleksej [1] Webrev: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.00/ [2] BUG: https://bugs.openjdk.java.net/browse/JDK-8038306
Re: Implicit 'this' return for void methods
In my opinion Project Coin was meant only to push some earlier chosen changes into language. Naked dot in language where long name are preferred is pure evil: I would have to look pairing ; for every dot ? someVeryLongName()/* explanation*/.otherLongNameMethod(); someVeryLongName();/* explanation*/.otherLongNameMethod(); When dot would be first sign i would have to: check end of previous line, or check last sign before comment, some time i would have to use scroll for each line (like when comparing code while commit). someVeryLongName().call().call().call().call().call().call().call().call().call().call().call(); // comment .otherLongNameMethod(); someVeryLongName().call().call().call().call().call().call().call().call().call().call().call() // comment .otherLongNameMethod(); The things go even worse if code have to be compared without without syntax highlighting. It's really hard to find anything good about this proposal. The most scary is fact that .. or ... would be consumed to support such change. because i hope for anything near: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000680.html 2014-04-02 11:08 GMT+02:00 Andrew Haley a...@redhat.com: On 04/01/2014 10:20 PM, Eirik Lygre wrote: What is the relationship between this naked dot proposal and the chaining of void methods proposal? The reason for asking is not to be negative, but rather to find out if these issues are best dealt with together, or as independent proposals. I think that if either of these are going to happen, then they must be specified with the appropriate level of isolation: That which belongs together must be processed together; that which belongs apart must be processed apart. Point taken, but Project Coin (small language changes) worked well. Andrew. -- Pozdrawiam Marek Kozieł ( Lasu ) http://na-chlodno.blogspot.com/ http://lasu2string.blogspot.com/
Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd UNIXProcess.java.linux ( .solaris .aix)
Hi, On 4/2/2014 6:49 AM, Peter Levart wrote: On 04/01/2014 09:47 PM, roger riggs wrote: Hi, A minor point, but the Enum for LaunchMechanism can be simpler; the defined enum values (1,2,3) are never used and can be removed along with the extra constructor. They are used for the mode parameter of forkAndExec() native method. yes, and could just as easily use the default ordinals (0,1,2). With the refactoring so far, this seems more complex and harder to understand. ... Other alternatives would have been to factor the common code (Streams handling) into a utilities class or ProcessImpl and retain the 1st class subclasses (with different names) for each platform or merge more up into ProcessImpl. Maybe it will be clearer with additional refactoring. As I said, I believe the consolidation of various Input/OutputStream wrappers could bring the class files number and size further down. yes, we can't stop yet. The only difference between the inner classes per platform is the choice of initializing the streams which could be handled with a switch instead of a subclass. Please continue, Roger $.02, Roger If you're concerned about class files included in the distributable, but not used, we can compensate this a bit by reducing the number of anonymous inner classes generated by javac just by replacing them with lambdas. Here's new webrev that does that too: http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.05/ If UNIXProcess.java in above webrev is compiled, the following class files are produced: -rw-rw-r--. 1 peter peter 772 Apr 2 12:33 UNIXProcess$1.class// SwitchMap for Platform enum I would have hoped that the extra class would not be needed for the private static enum, but then private isn't private when it is visible to inner classes! It is needed for separate compilation. -rw-rw-r--. 1 peter peter 2706 Apr 2 12:33 UNIXProcess$AixProcess.class -rw-rw-r--. 1 peter peter 2155 Apr 2 12:33 UNIXProcess$DeferredCloseInputStream.class -rw-rw-r--. 1 peter peter 2930 Apr 2 12:33 UNIXProcess$DeferredCloseProcessPipeInputStream.class -rw-rw-r--. 1 peter peter 1166 Apr 2 12:33 UNIXProcess$LaunchMechanism.class -rw-rw-r--. 1 peter peter 2701 Apr 2 12:33 UNIXProcess$LinuxOrBsdProcess.class -rw-rw-r--. 1 peter peter 4762 Apr 2 12:33 UNIXProcess$Platform.class -rw-rw-r--. 1 peter peter 1711 Apr 2 12:33 UNIXProcess$ProcessPipeInputStream.class -rw-rw-r--. 1 peter peter 949 Apr 2 12:33 UNIXProcess$ProcessPipeOutputStream.class -rw-rw-r--. 1 peter peter 1902 Apr 2 12:33 UNIXProcess$ProcessReaperThreadFactory.class -rw-rw-r--. 1 peter peter 2935 Apr 2 12:33 UNIXProcess$SolarisProcess.class -rw-rw-r--. 1 peter peter 6260 Apr 2 12:33 UNIXProcess.class ...12 class files totaling 30.2 KiB. If original UNIXProcess.java.linux is compiled, for example, the following files are produced: -rw-rw-r--. 1 peter peter 1648 Apr 2 12:25 UNIXProcess$1.class -rw-rw-r--. 1 peter peter 926 Apr 2 12:25 UNIXProcess$2.class -rw-rw-r--. 1 peter peter 865 Apr 2 12:25 UNIXProcess$3.class -rw-rw-r--. 1 peter peter 648 Apr 2 12:25 UNIXProcess$4.class -rw-rw-r--. 1 peter peter 1200 Apr 2 12:25 UNIXProcess$LaunchMechanism.class -rw-rw-r--. 1 peter peter 1711 Apr 2 12:25 UNIXProcess$ProcessPipeInputStream.class -rw-rw-r--. 1 peter peter 949 Apr 2 12:25 UNIXProcess$ProcessPipeOutputStream.class -rw-rw-r--. 1 peter peter 939 Apr 2 12:25 UNIXProcess$ProcessReaperThreadFactory$1.class -rw-rw-r--. 1 peter peter 1233 Apr 2 12:25 UNIXProcess$ProcessReaperThreadFactory.class -rw-rw-r--. 1 peter peter 5626 Apr 2 12:25 UNIXProcess.class ...10 class files totaling 15,4 KiB So it's ~15 KiB that we are talking about at this moment. Regards, Peter On 4/1/2014 1:04 PM, Peter Levart wrote: On 04/01/2014 05:43 PM, Peter Levart wrote: On 04/01/2014 03:49 PM, roger riggs wrote: Hi Peter, The design using enum for the os dependencies does not make it possible to include only the support needed for a particular platform at build time. Every implementation will be carrying around the support for all the other platforms. A build time binding would be more efficient. Roger That's true. A trade-off between maintainability and efficiency. The efficiency has two categories here. One is the size of the distributable and the other is run-time efficiency. I've been thinking to improve both efficiencies (the run-time in particular) with a little re-design. Since nearly each OS platform requires a sub-class of UNIXProcess to implement the differences, I can move the implementations of various methods now in Os enum to the UNIXProcess subclasses and get rid of Os enum per-instance subclasses. Let me try this and see what comes out. Hi Roger, Well, it turns out the methods would like to stay in Os (renamed to Platform), but there is no need for per-enum-instance subclasses. Using enum constructor parameters and switch statements makes code
Re: RFR: tests for JDK-8032884
In the test, I need to do following steps: 1. compile schema file using xjc tool 2. compile generated sources 3. load generated class and via reflection API verify generated methods Although I know how to run tool directly from the test, it seems to me not very elegant to run compiler directly from the test - or is there other way how to compile generated sources from the test? Regrading moving test - no problem, but I would suggest javax/xml/bind/xjc in this case - xjc is JAXB tool, not JAX-WS. Do you agree? Thanks Miran On 01/04/14 18:50, Chris Hegarty wrote: The tests looks fine to me. Trivially, you could eliminate the shell script and run xic from ProcessBuilder? Also, does it make sense to move the test to jdk/test/javax/xml/ws/xjc? With the other jaxws tests, or is xjc different. -Chris,. On 1 Apr 2014, at 16:21, Miroslav Kos miroslav@oracle.com wrote: Hi everybody, I'd like to ask for review of following tests: http://cr.openjdk.java.net/~mkos/8032884/jdk.01/ Original bug (already fixed): Bug: https://bugs.openjdk.java.net/browse/JDK-8032884 Issue fixing the bug (bulk update): https://bugs.openjdk.java.net/browse/JDK-8036030 The test verifies the source code generated by xjc tool. Thanks Miran
Re: RFR: tests for JDK-8032884
On 02/04/14 14:32, Miroslav Kos wrote: In the test, I need to do following steps: 1. compile schema file using xjc tool 2. compile generated sources 3. load generated class and via reflection API verify generated methods In which case, what you have is fine then. Although I know how to run tool directly from the test, it seems to me not very elegant to run compiler directly from the test - or is there other way how to compile generated sources from the test? Regrading moving test - no problem, but I would suggest javax/xml/bind/xjc in this case - xjc is JAXB tool, not JAX-WS. Do you agree? Agreed. -Chris. Thanks Miran On 01/04/14 18:50, Chris Hegarty wrote: The tests looks fine to me. Trivially, you could eliminate the shell script and run xic from ProcessBuilder? Also, does it make sense to move the test to jdk/test/javax/xml/ws/xjc? With the other jaxws tests, or is xjc different. -Chris,. On 1 Apr 2014, at 16:21, Miroslav Kos miroslav@oracle.com wrote: Hi everybody, I'd like to ask for review of following tests: http://cr.openjdk.java.net/~mkos/8032884/jdk.01/ Original bug (already fixed): Bug: https://bugs.openjdk.java.net/browse/JDK-8032884 Issue fixing the bug (bulk update): https://bugs.openjdk.java.net/browse/JDK-8036030 The test verifies the source code generated by xjc tool. Thanks Miran
Re: Implicit 'this' return for void methods
Hi, Just adding some perspective after following these language-feature discussions for several years now. In my opinion Project Coin was meant only to push some earlier chosen changes into language. The initial Project Coin process actually invited proposals from the community. There were many, and the majority were rejected (following varying amounts of analysis and discussion). IIRC, the underscore in number literals was one that had not been on the table before, but for which a sound proposal, use-cases, specification, and code were provided by a community member. Bob Lee also submitted a proposal related to generics that made it in, IIRC. That said, the Oracle Java team has made it clear that there are many, many more feature requests than there are time or resources to implement them, even if you could decide which were really worth it. That's been true for many years now, basically since the 90s. Brian Goetz (among others) has addressed this topic - of language changes - to death in various mailing lists over the last few years. His email from 2011 on how the language changes may be handled in the future is probably useful to re-read http://mail.openjdk.java.net/pipermail/coin-dev/2011-October/003373.html IMO, the chances are low that a loose agreement from a handful of people on this mailing thread will incite the kind folks at Oracle to take action. At this point, someone, perhaps Ulf, could summarize and formalize the proposal in a draft JEP. That said, as far as I know, there has been no open call for proposed changes to the language in Java 9. There might be a better outlet for these discussions than the core-libs mailing list. Perhaps a new group on Stack Exchange could be used to flesh proposals out first. Each of our emails here, including this one, takes time away from the members of the core-libs team. My 0.02, Patrick
Re: RFR: 8035618 : Four api/org_omg/CORBA TCK tests fail under plugin only
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 the boot strap JDK for CORBA. Direct access to the sun.awt.AppContect class has been removed. bug : https://bugs.openjdk.java.net/browse/JDK-8035618 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8035618.jdk9.v3/webrev/ This mostly looks okay to me except that pmContexts should be final. It looks like this code is also a candidate to use computeIfAbsent so you could replace L251-254 with one statement. -Alan.
Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms
On Apr 1, 2014, at 6:21 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: On 4/1/14 7:29 PM, Paul Sandoz wrote: On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: Paul, Unfortunately, additional profiling doesn't work for Accessor.checkCast case. The problem is Accessor.checkCast is called from multiple places, so type profile is very likely to be polluted. And it kills the benefits. Though... i wonder why the accessor cast is any more or less unique than casts performed for lambda form. So is there any point in doing such a cast in this case? The type performing the cast is the field type declared as a parameter in the MethodType of the MethodHandle and also held by the Accessor. IIUC the Invokers.checkExactType should ensure no unsavoury instances of the wrong type gets through? (the holder instance is only checked for null, via checkBase). I don't see any point in doing profiling for this particular case. Such shape should be well optimized by JIT if it sees that an instance of Accessor is a constant. As I understand, it should be the case for most of the usage scenarios. Perhaps conservatively we could retain the existing casts if PROFILE 0. I can provide a patch if that helps? Also, just double checking, i would presume the same would be applicable for MH setter/getters to arrays as per your patch improving those? Regarding redundant null check, do you have a test case so I can play with it myself? I will send something to you later today or tomorrow. Still plan to send you something today :-) but later on... Paul.
Re: Implicit 'this' return for void methods
On 04/02/2014 12:05 PM, Andrew Haley wrote: On 04/02/2014 11:58 AM, Ulf Zibis wrote: Hi, Am 02.04.2014 11:08, schrieb Andrew Haley: On 04/01/2014 10:20 PM, Eirik Lygre wrote: What is the relationship between this naked dot proposal and the chaining of void methods proposal? The reason for asking is not to be negative, but rather to find out if these issues are best dealt with together, or as independent proposals. I think that if either of these are going to happen, then they must be specified with the appropriate level of isolation: That which belongs together must be processed together; that which belongs apart must be processed apart. Point taken, but Project Coin (small language changes) worked well. If that would help to make things happen, I support the idea to separate both steps to different proposals. Here's how it works: Start a project to do small language changes, or join an existing one. Form an EG for the JSR. It may be be that there is already a suitable JSR in progress. Discuss. Make spec changes, make an implementation, make TCK changes. Propose the change to the umbrella Java SE EG for inclusion in JDK N. As Patrick Wright has pointed out, this would be a JEP. See http://openjdk.java.net/jeps/1 Andrew.
Re: RFR: 8035618 : Four api/org_omg/CORBA TCK tests fail under plugin only
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 the boot strap JDK for CORBA. Direct access to the sun.awt.AppContect class has been removed. bug : https://bugs.openjdk.java.net/browse/JDK-8035618 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8035618.jdk9.v3/webrev/ This mostly looks okay to me except that pmContexts should be final. It looks like this code is also a candidate to use computeIfAbsent so you could replace L251-254 with one statement. I'll make pmContexts final before pushing. Thanks for the lambda tip. As per trial though, it looks like CORBA code is still compiled with -source 1.7, we can revisit after this changes. regards, Sean. -Alan.
RFR 8039088: Fix broken URLs in package.html
Good morning, Here is another trivial change to address some broken links Best Lance ljanders-mac:sql ljanders$ hg diff diff -r 31541b9a5a4a src/share/classes/java/sql/package.html --- a/src/share/classes/java/sql/package.html Wed Apr 02 10:20:14 2014 -0400 +++ b/src/share/classes/java/sql/package.html Wed Apr 02 10:50:21 2014 -0400 @@ -316,24 +316,18 @@ h2Package Specification/h2 ul - lia href=http://java.sun.com/products/jdbc/download.html;Specification - of the JDBC 4.0 API/a + lia href=https://jcp.org/en/jsr/detail?id=221;JDBC 4.2 Specification/a /ul h2Related Documentation/h2 ul - lia href=../../../technotes/guides/jdbc/getstart/GettingStartedTOC.fm.htmlGetting Started/a--overviews of the major interfaces + lia href=http://docs.oracle.com/javase/tutorial/jdbc/basics/index.html; + Lesson:JDBC Basics(The Javaxx Tutorials gt; JDBC(#0153;) Database Access)/a - lia href=http://java.sun.com/docs/books/tutorial/jdbc;Chapters on the JDBC - API/a--from the online version of iThe Java Tutorial Continued/i - - lia href=http://java.sun.com/docs/books/jdbc; -iJDBCsupfont size=-2TM/font/supAPI Tutorial and Reference, -Third Edition/i/a-- -a complete reference and tutorial for the JDBC 3.0 API + lia href=http://www.oracle.com/technetwork/java/index-142838.html; + iJDBC#0153;API Tutorial and Reference, Third Edition/i/a /ul -@since 1.1 /body /html diff -r 31541b9a5a4a src/share/classes/javax/sql/package.html --- a/src/share/classes/javax/sql/package.html Wed Apr 02 10:20:14 2014 -0400 +++ b/src/share/classes/javax/sql/package.html Wed Apr 02 10:50:21 2014 -0400 @@ -296,8 +296,7 @@ h2Package Specification/h2 ul - lia href=http://java.sun.com/products/jdbc/download.html;Specification of the - JDBC 4.0 API/a + lia href=https://jcp.org/en/jsr/detail?id=221;JDBC 4.2 Specification/a /ul h2Related Documentation/h2 @@ -307,10 +306,8 @@ package: ul - lia href=http://java.sun.com/docs/books/jdbc;iJDBCsupfont size=-2TM/font/sup - API Tutorial and Reference, Third Edition:/i/a + lia href=http://www.oracle.com/technetwork/java/index-142838.html; + iJDBC#0153;API Tutorial and Reference, Third Edition/i/a /ul -P -@since 1.4 /body /html ljanders-mac:sql ljanders$ 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: RFR 8039088: Fix broken URLs in package.html
Looks ok to me Lance. -Chris. On 02/04/14 15:53, Lance Andersen wrote: Good morning, Here is another trivial change to address some broken links Best Lance ljanders-mac:sql ljanders$ hg diff diff -r 31541b9a5a4a src/share/classes/java/sql/package.html --- a/src/share/classes/java/sql/package.html Wed Apr 02 10:20:14 2014 -0400 +++ b/src/share/classes/java/sql/package.html Wed Apr 02 10:50:21 2014 -0400 @@ -316,24 +316,18 @@ h2Package Specification/h2 ul - lia href=http://java.sun.com/products/jdbc/download.html;Specification - of the JDBC 4.0 API/a + lia href=https://jcp.org/en/jsr/detail?id=221;JDBC 4.2 Specification/a /ul h2Related Documentation/h2 ul - lia href=../../../technotes/guides/jdbc/getstart/GettingStartedTOC.fm.htmlGetting Started/a--overviews of the major interfaces + lia href=http://docs.oracle.com/javase/tutorial/jdbc/basics/index.html; + Lesson:JDBC Basics(The Javaxx Tutorials gt; JDBC(#0153;) Database Access)/a - lia href=http://java.sun.com/docs/books/tutorial/jdbc;Chapters on the JDBC - API/a--from the online version of iThe Java Tutorial Continued/i - - lia href=http://java.sun.com/docs/books/jdbc; -iJDBCsupfont size=-2TM/font/supAPI Tutorial and Reference, -Third Edition/i/a-- -a complete reference and tutorial for the JDBC 3.0 API + lia href=http://www.oracle.com/technetwork/java/index-142838.html; + iJDBC#0153;API Tutorial and Reference, Third Edition/i/a /ul -@since 1.1 /body /html diff -r 31541b9a5a4a src/share/classes/javax/sql/package.html --- a/src/share/classes/javax/sql/package.html Wed Apr 02 10:20:14 2014 -0400 +++ b/src/share/classes/javax/sql/package.html Wed Apr 02 10:50:21 2014 -0400 @@ -296,8 +296,7 @@ h2Package Specification/h2 ul - lia href=http://java.sun.com/products/jdbc/download.html;Specification of the - JDBC 4.0 API/a + lia href=https://jcp.org/en/jsr/detail?id=221;JDBC 4.2 Specification/a /ul h2Related Documentation/h2 @@ -307,10 +306,8 @@ package: ul - lia href=http://java.sun.com/docs/books/jdbc;iJDBCsupfont size=-2TM/font/sup - API Tutorial and Reference, Third Edition:/i/a + lia href=http://www.oracle.com/technetwork/java/index-142838.html; + iJDBC#0153;API Tutorial and Reference, Third Edition/i/a /ul -P -@since 1.4 /body /html ljanders-mac:sql ljanders$ 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: Improve timezone mapping for AIX platform
Hi Jonathan,
thanks for updating the change. Please find my comments inline:
On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu luc...@linux.vnet.ibm.com wrote:
Hi Volker, Masayoshi,
Thanks a lot for your review, here's the updated patch, could you pls take a
look?
http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/
On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis volker.simo...@gmail.com
wrote:
Hi Jonathan,
thanks for doing this change. Please find some comments below:
1. please update the copyright year to 2014 in every file you touch
Updated in new patch.
2. in CopyFiles.gmk you can simplify the change by joining the windows
and aix cases because on Windows OPENJDK_TARGET_OS is the same like
OPENJDK_TARGET_OS_API_DIR. So you can write:
ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), )
TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib
$(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings
$(call install-file)
COPY_FILES += $(LIBDIR)/tzmappings
endif
I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris'
as I observed on my AIX box,
solaris/lib is not the directory where tzmappings was stored for AIX.
So I'm keeping this change, please fix me if I was wrong about the config.
Yes, but my point was to actually use OPENJDK_TARGET_OS for the
construction of TZMAPPINGS_SRC as shown in the code snippet above.
OPENJDK_TARGET_OS is windows on Windows platforms and aix on AIX
and that should be just enough here.
3. regarding the changes proposed by Masayoshi: I agree that we should
put the AIX timezone mapping code in its own function, but I don't
think that getPlatformTimeZoneID() would be the right place. As far as
I understand, getPlatformTimeZoneID() is used to get a platform time
zone id if the environment variable TZ is not set. I don't know a
way how this could be done on AIX (@Jonathan: maybe you know?). If
there would be a way to get the time zone from some system files or
so, then we should put this code into the AIX version of
getPlatformTimeZoneID().
I guess we may try to use /etc/envrionment file, which is basic setting for
all processes,
see
http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm
The implementation of getPlatformTimeZoneID() has been updated.
That's good!
But the current AIX code contributed by Jonathan, actually uses the
time zone id from the TZ environment variable and just maps it to a
Java compatible time zone id. So I'd suggest to refactor this code
into a function like for example static const char*
mapPlatformToJavaTimzone(const char* tz) and call that from
findJavaTZ_md(). I think that would make the code easier to
understand.
Agree, and have split the code into a separate static method to do the
mapping work.
Good. But there's still one error in findJavaTZ_md():
706 #ifdef _AIX
707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz);
708 #endif
This should read:
706 #ifdef _AIX
707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz);
708 #endif
because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came
from getPlatformTimeZoneID().
With the above fixed I'll push this one we get one more review from a
reviewer (I'm currently not an official reviewer).
Regards,
Volker
@Masayoshi: what do you think, would you agree with such a solution.
4. I agree with Masayoshi that you should use the existing
getGMTOffsetID()
Updated in new patch to eliminate duplication.
5. Please notice that your change breaks all Unix builds except AIX
because of:
759 }
760 tzerr:
761 if (javatz == NULL) {
762 time_t offset;
...
782 }
783 #endif
I think that should read:
759
760 tzerr:
761 if (javatz == NULL) {
762 time_t offset;
...
782 }
783 #endif
784 }
Refactoring the code in an extra function will make that error more
evident anyway.
But please always build at least on one different platform (i.e.
Linux) to prevent such errors in the future.
My fault, sorry for the failure, should take no chance after any manual
alteration.
Regards,
Volker
On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu
masayoshi.oku...@oracle.com wrote:
Hi Jonathan,
The AIX specific code looks OK to me. But I'd suggest the code be moved
to
getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also
there's a function for producing a fallback ID in GMT±hh:mm,
getGMTOffsetID() which can be called in tzerr.
Thanks,
Masayoshi
On 3/26/2014 3:47 PM, Jonathan Lu wrote:
Hi ppc-aix-port-dev, core-libs-dev,
Here's a patch for JDK-8034220,
http://cr.openjdk.java.net/~luchsh/JDK-8034220/
It is trying to add the a more complete timezone mapping mechanism for
AIX
platform.
the changes are primarily based on IBM's commercial JDK
Re: RFR: 8038306: (tz) Support tzdata2014b
looks fine. On 4/2/14 3:55 AM, Aleksej Efimov wrote: Hello, Can I have a review for the latest (2014b) TZ data integration to JDK9. The webrev can be located here [1]. The following set of tests were executed without failures: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter test/closed/java/util/Calendar\ test/closed/java/util/TimeZone Thank you, Aleksej [1] Webrev: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.00/ [2] BUG: https://bugs.openjdk.java.net/browse/JDK-8038306
Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd UNIXProcess.java.linux ( .solaris .aix)
On 01/04/2014 18:04, Peter Levart wrote: Hi Roger, Well, it turns out the methods would like to stay in Os (renamed to Platform), but there is no need for per-enum-instance subclasses. Using enum constructor parameters and switch statements makes code even more compact and easy to follow... http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.04/ I belive there is still room for consolidating logic in various Input/OutputStream wrappers used in UNIXProcess variants. But in the first round I tried to preserve the exact behaviour. If the wrapping of streams could be made more-or-less equal in all UNIX platforms, then the need for UNIXProcess subclasses and/or overhead of support classes included but not used goes away... I went through webrev.05 and the new Platform enum looks reasonable to me (and thanks for the rename too). I checked the os.name mapping and it looks right. Whether it's Error or InternalError for an unrecognized platform probably doesn't matter here. If Roger is okay with this version then I think we should get this merge done and look at other refactoring with a later change. Also if src/solaris is renamed (and I know many of want do this) then it's another opportunity to come back to the topic too. -Alan.
Re: RFR: 8035618 : Four api/org_omg/CORBA TCK tests fail under plugin only
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 the boot strap JDK for CORBA. Direct access to the sun.awt.AppContect class has been removed. bug : https://bugs.openjdk.java.net/browse/JDK-8035618 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8035618.jdk9.v3/webrev/ This mostly looks okay to me except that pmContexts should be final. It looks like this code is also a candidate to use computeIfAbsent so you could replace L251-254 with one statement. I'll make pmContexts final before pushing. Thanks for the lambda tip. As per trial though, it looks like CORBA code is still compiled with -source 1.7, we can revisit after this changes. Looks good to me too.Corba's use of lambda would need to wait until the boot jdk for jdk9 will be updated to jdk8? Mandy
Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd UNIXProcess.java.linux ( .solaris .aix)
On 04/02/2014 03:17 PM, roger riggs wrote: Hi, On 4/2/2014 6:49 AM, Peter Levart wrote: On 04/01/2014 09:47 PM, roger riggs wrote: Hi, A minor point, but the Enum for LaunchMechanism can be simpler; the defined enum values (1,2,3) are never used and can be removed along with the extra constructor. They are used for the mode parameter of forkAndExec() native method. yes, and could just as easily use the default ordinals (0,1,2). With the refactoring so far, this seems more complex and harder to understand. ... Other alternatives would have been to factor the common code (Streams handling) into a utilities class or ProcessImpl and retain the 1st class subclasses (with different names) for each platform or merge more up into ProcessImpl. Maybe it will be clearer with additional refactoring. As I said, I believe the consolidation of various Input/OutputStream wrappers could bring the class files number and size further down. yes, we can't stop yet. The only difference between the inner classes per platform is the choice of initializing the streams which could be handled with a switch instead of a subclass. Please continue, Roger Right, Here it is: http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.06/ This one does away with UNIXProcess subclasses. This allowed me to restore private modifier on all fields and methods that were previously accessed from subclasses and were changed to package-private to avoid compiler generating access methods. I also replaced process reaper thread factory with a lambda. Class files produced by compiling now are: -rw-rw-r--. 1 peter peter 772 Apr 2 17:45 UNIXProcess$1.class -rw-rw-r--. 1 peter peter 2155 Apr 2 17:45 UNIXProcess$DeferredCloseInputStream.class -rw-rw-r--. 1 peter peter 2930 Apr 2 17:45 UNIXProcess$DeferredCloseProcessPipeInputStream.class -rw-rw-r--. 1 peter peter 1082 Apr 2 17:45 UNIXProcess$LaunchMechanism.class -rw-rw-r--. 1 peter peter 4762 Apr 2 17:45 UNIXProcess$Platform.class -rw-rw-r--. 1 peter peter 1711 Apr 2 17:45 UNIXProcess$ProcessPipeInputStream.class -rw-rw-r--. 1 peter peter 949 Apr 2 17:45 UNIXProcess$ProcessPipeOutputStream.class -rw-rw-r--. 1 peter peter 9401 Apr 2 17:45 UNIXProcess.class ...8 class files totaling 23.2 KiB. Getting close to original code. Regards, Peter
Re: Improve timezone mapping for AIX platform
Hi Volker,
On 2014年04月02日 23:07, Volker Simonis wrote:
Hi Jonathan,
thanks for updating the change. Please find my comments inline:
On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu
luc...@linux.vnet.ibm.com luc...@linux.vnet.ibm.com wrote:
Hi Volker, Masayoshi,
Thanks a lot for your review, here's the updated patch, could you pls take a
look?
http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/
On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis
volker.simo...@gmail.com volker.simo...@gmail.com
wrote:
Hi Jonathan,
thanks for doing this change. Please find some comments below:
1. please update the copyright year to 2014 in every file you touch
Updated in new patch.
2. in CopyFiles.gmk you can simplify the change by joining the windows
and aix cases because on Windows OPENJDK_TARGET_OS is the same like
OPENJDK_TARGET_OS_API_DIR. So you can write:
ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), )
TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib
$(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings
$(call install-file)
COPY_FILES += $(LIBDIR)/tzmappings
endif
I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris'
as I observed on my AIX box,
solaris/lib is not the directory where tzmappings was stored for AIX.
So I'm keeping this change, please fix me if I was wrong about the config.
Yes, but my point was to actually use OPENJDK_TARGET_OS for the
construction of TZMAPPINGS_SRC as shown in the code snippet above.
OPENJDK_TARGET_OS is windows on Windows platforms and aix on AIX
and that should be just enough here.
That's right, let me try that and also build/test on Windows platform.
3. regarding the changes proposed by Masayoshi: I agree that we should
put the AIX timezone mapping code in its own function, but I don't
think that getPlatformTimeZoneID() would be the right place. As far as
I understand, getPlatformTimeZoneID() is used to get a platform time
zone id if the environment variable TZ is not set. I don't know a
way how this could be done on AIX (@Jonathan: maybe you know?). If
there would be a way to get the time zone from some system files or
so, then we should put this code into the AIX version of
getPlatformTimeZoneID().
I guess we may try to use /etc/envrionment file, which is basic setting for
all processes,
seehttp://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm
The implementation of getPlatformTimeZoneID() has been updated.
That's good!
But the current AIX code contributed by Jonathan, actually uses the
time zone id from the TZ environment variable and just maps it to a
Java compatible time zone id. So I'd suggest to refactor this code
into a function like for example static const char*
mapPlatformToJavaTimzone(const char* tz) and call that from
findJavaTZ_md(). I think that would make the code easier to
understand.
Agree, and have split the code into a separate static method to do the
mapping work.
Good. But there's still one error in findJavaTZ_md():
706 #ifdef _AIX
707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz);
708 #endif
This should read:
706 #ifdef _AIX
707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz);
708 #endif
because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came
from getPlatformTimeZoneID().
Right, but with the second approach, there may be a minor memory leak here,
as javatz was not freed before being overwritten on AIX. will post another
patch on this soon.
With the above fixed I'll push this one we get one more review from a
reviewer (I'm currently not an official reviewer).
Regards,
Volker
@Masayoshi: what do you think, would you agree with such a solution.
4. I agree with Masayoshi that you should use the existing
getGMTOffsetID()
Updated in new patch to eliminate duplication.
5. Please notice that your change breaks all Unix builds except AIX
because of:
759 }
760 tzerr:
761 if (javatz == NULL) {
762 time_t offset;
...
782 }
783 #endif
I think that should read:
759
760 tzerr:
761 if (javatz == NULL) {
762 time_t offset;
...
782 }
783 #endif
784 }
Refactoring the code in an extra function will make that error more
evident anyway.
But please always build at least on one different platform (i.e.
Linux) to prevent such errors in the future.
My fault, sorry for the failure, should take no chance after any manual
alteration.
Regards,
Volker
On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi
Okutsumasayoshi.oku...@oracle.com masayoshi.oku...@oracle.com
wrote:
Hi Jonathan,
The AIX specific code looks OK to me. But I'd suggest the code be moved
to
getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also
there's a function for producing a fallback ID in GMT±hh:mm,
getGMTOffsetID() which can be called in tzerr.
Thanks,
Masayoshi
On 3/26/2014 3:47 PM, Jonathan Lu
Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms
On Apr 2, 2014, at 4:16 PM, Paul Sandoz paul.san...@oracle.com wrote:
Regarding redundant null check, do you have a test case so I can play with
it myself?
I will send something to you later today or tomorrow.
Still plan to send you something today :-) but later on...
See below for an inline trace, the assembler and the class that was executed
with -XX:-TieredCompilation using Java 8.
Paul.
Inlining _isInstance on constant Class java/lang/String
!@ 9 MHFieldTest::testLoopOne (25 bytes) inline
(hot)
@ 8
java.lang.invoke.LambdaForm$MH/617901222::invokeExact_MT (15 bytes) inline
(hot)
@ 2 java.lang.invoke.Invokers::checkExactType
(30 bytes) inline (hot)
@ 11 java.lang.invoke.MethodHandle::type (5
bytes) accessor
@ 11
java.lang.invoke.LambdaForm$MH/523429237::putObjectFieldCast (32 bytes)
inline (hot)
@ 1
java.lang.invoke.DirectMethodHandle::fieldOffset (9 bytes) inline (hot)
@ 6
java.lang.invoke.DirectMethodHandle::checkBase (7 bytes) inline (hot)
@ 1 java.lang.Object::getClass (0 bytes)
(intrinsic)
@ 13
java.lang.invoke.DirectMethodHandle::checkCast (9 bytes) inline (hot)
@ 5
java.lang.invoke.DirectMethodHandle$Accessor::checkCast (9 bytes) inline (hot)
@ 5 java.lang.Class::cast (27 bytes)
inline (hot)
@ 6 java.lang.Class::isInstance (0
bytes) (intrinsic)
@ 28 sun.misc.Unsafe::putObject (0 bytes)
(intrinsic)
[Verified Entry Point]
0x00010ccf0da0: mov%eax,-0x14000(%rsp)
0x00010ccf0da7: push %rbp
0x00010ccf0da8: sub$0x20,%rsp ;*synchronization entry
; - MHFieldTest::testLoopOne@-1
(line 57)
0x00010ccf0dac: mov0xc(%rsi),%r10d;*getfield a
; - MHFieldTest::testLoopOne@5
(line 57)
0x00010ccf0db0: test %r10d,%r10d
0x00010ccf0db3: je 0x00010ccf0ddd ;*ifnull
; - java.lang.Class::cast@1
(line 3257)
; -
java.lang.invoke.DirectMethodHandle$Accessor::checkCast@5 (line 441)
; -
java.lang.invoke.DirectMethodHandle::checkCast@5 (line 510)
; -
java.lang.invoke.LambdaForm$MH/640070680::putObjectFieldCast@13
; -
java.lang.invoke.LambdaForm$MH/789451787::invokeExact_MT@11
; - MHFieldTest::testLoopOne@8
(line 57)
0x00010ccf0db5: add$0x10,%rsi
0x00010ccf0db9: mov%r10d,(%rsi)
0x00010ccf0dbc: mov%rsi,%r10
0x00010ccf0dbf: shr$0x9,%r10
0x00010ccf0dc3: mov$0x18f78,%r11
0x00010ccf0dcd: mov%r12b,(%r11,%r10,1) ;*getfield a
; - MHFieldTest::testLoopOne@5
(line 57)
0x00010ccf0dd1: add$0x20,%rsp
0x00010ccf0dd5: pop%rbp
0x00010ccf0dd6: test %eax,-0x113ddc(%rip)# 0x00010cbdd000
; {poll_return}
0x00010ccf0ddc: retq
0x00010ccf0ddd: mov%rsi,%rbp
0x00010ccf0de0: mov%r10d,0x4(%rsp)
0x00010ccf0de5: mov$0xffad,%esi
0x00010ccf0dea: nop
0x00010ccf0deb: callq 0x00010ccbc120 ; OopMap{rbp=Oop [4]=NarrowOop
off=112}
;*ifnull
; - java.lang.Class::cast@1
(line 3257)
; -
java.lang.invoke.DirectMethodHandle$Accessor::checkCast@5 (line 441)
; -
java.lang.invoke.DirectMethodHandle::checkCast@5 (line 510)
; -
java.lang.invoke.LambdaForm$MH/640070680::putObjectFieldCast@13
; -
java.lang.invoke.LambdaForm$MH/789451787::invokeExact_MT@11
; - MHFieldTest::testLoopOne@8
(line 57)
; {runtime_call}
0x00010ccf0df0: callq 0x00010c07ace4 ;*ifnull
; - java.lang.Class::cast@1
(line 3257)
; -
java.lang.invoke.DirectMethodHandle$Accessor::checkCast@5 (line 441)
; -
Re: Implicit 'this' return for void methods
On 04/01/2014 11:28 AM, Bruce Chapman wrote: Slightly preceding Ulf's coin proposal by a few hours was http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html Where I suggested the naked dot notation (coined in http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.html) has better value as .. a syntax for referring to the receiver of a method inside arguments to the method. More formally, the naked dot (at the start of an expression, not following an invocation to a void method) would refer to the receiver of the innermost surrounding invocation expression. A: What is the receiver of the invocation of a static method? B: What is the receiver of the invocation of a constructor? Regards, Peter and so to answer Guy's question below in terms of my original intention rather than Ulf's proposal, .indexof(Q) would use myVeryLongNamedString as its receiver. I see particular value for these naked dot expressions in creating fluent APIs such as builder patterns. As suggested in my coin post, there is also value for passing enums or named constants to methods when (as is often the case) these named constants are defined in the same class as the method being invoked. In a highly informal sense, the naked dot enables on demand changing of the scope to be that of the invocation expression's receiver, I think with this interpretation of the meaning of naked or leading dot, Guy's compromise restriction below is not required. Bruce On 27/03/2014 4:51 a.m., Guy Steele wrote: I am a bit more skeptical about expressions that begin with a dot because of potential confusion about which expression is referred to: myVeryLongNamedString.subString(.indexOf(C”), .indexOf(Q”)) seems clear enough, but what about: myVeryLongNamedString.subString(.indexOf(C”) + otherString.length(), .indexOf(Q”)) Does the second occurrence of .indexOf use myVeryLongNamedString or otherString? A compromise would be to allow leading-dot expressions to occur only within the arguments of the method call whose target is the object which the leading-dot expressions are expected to use as their target, and if there are such leading-dot expressions within the arguments then the arguments must not contain any non-leading-dot field references or method calls. Just a thought for discussion. This would be considered a separate mechanism from the chaining-of-void-methods mechanism (it was a very clever idea to try to unify them in Ulf's original proposal, though). —Guy --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
