From joe.darcy at oracle.com Tue Jul 13 19:47:26 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 13 Jul 2010 19:47:26 -0700 Subject: ARM API Support In-Reply-To: <4C22A20C.3080106@oracle.com> References: <4C22A20C.3080106@oracle.com> Message-ID: <4C3D253E.9050005@oracle.com> PS Additional platform classes have been retrofitted for use with ARM (http://hg.openjdk.java.net/jdk7/tl/jdk/rev/425960cef714): Retrofit as AutoCloseable: java.beans.XMLEncoder java.beans.XMLDecoder java.io.ObjectInput java.io.ObjectOutput javax.sound.sampled.Line javax.sound.midi.Receiver javax.sound.midi.Transmitter javax.sound.midi.MidiDevice Retrofit as Closeable: java.util.Scanner Candidates for retrofitting were identified by running an annotation processor over the JDK sources; for details see: "Project Coin: Bringing it to a Close(able)" http://blogs.sun.com/darcy/entry/project_coin_bring_close -Joe Joe Darcy wrote: > Greetings > > The initial API changes to support the Project Coin feature automatic > resource management (ARM) blocks have been pushed into JDK 7 [1] and > will appear in subsequent builds. The corresponding compiler changes > to support the actual language feature remain in progress. > > The initial API work to support ARM was divided into two pieces, > essential API support and retrofitting platform classes. The essential > support includes: > > * A new interface java.lang.AutoCloseable which defines a single method > void close() throws Exception > > * A new enum constant in the language model: > javax.lang.model.element.ElementKind.RESOURCE_VARIABLE > > * Methods on java.lang.Throwable to add and retrieve information about > suppressed exceptions, including printing out suppressed exceptions in > stack traces. > > The retrofitting includes: > > * Having java.io.Closeable extend java.lang.AutoCloseable. (From a > typing perspective, a subtype of AutoCloseable can be declared to > throw fewer exceptions than the supertype. Therefore is is fine for > the close method in AutoCloseable to throw Exception and the close > method in Closeable to throw the more specific IOException. It would > even be fine for the close method in a subtype of AutoCloseable to be > declared to throw no exceptions at all.) > > * Adding a close method to java.nio.channels.FileLock and having > FileLock implement AutoCloseable. > > * Adding Closeable as an interface implemented by > javax.imageio.stream.ImageInputStream. > > Other platform classes may be retrofitted to implement AutoCloseable > or Closable in future builds. > > Compared to the API support in earlier versions of the ARM proposal, > the top-level interface to mark participation in ARM is in package > java.lang rather than its own package and, after consultation with the > JDBC and graphics teams, neither java.sql.* nor java.awt.Graphics were > retrofitted for ARM. > > -Joe > > [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c4d60bcce958 > http://hg.openjdk.java.net/jdk7/tl/langtools/rev/be5cafeb318d > From joe.darcy at oracle.com Thu Jul 15 14:44:34 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 15 Jul 2010 14:44:34 -0700 Subject: Updated ARM Spec Message-ID: <4C3F8142.2030203@oracle.com> Greetings. Starting with Project Coin proposal for Automatic Resource Management (ARM), in consultation with Josh Bloch, Maurizio, Jon, and others, Alex and I have produced a specification for ARM blocks that is much closer to Java Language Specification (JLS) style and rigor. The specification involves changes to the existing JLS section 14.20 "The try statement," and will eventually introduce a new subsection 14.20.3 "Execution of try-with-resources," although the specification below is not partitioned as such. Non-normative comments about the specification text below appear inside "[]". Differences between the new specification and the earlier Project Coin proposal for ARM are discussed after the specification. -=-=-=-=-=-=-=-=-=-=-=-=-=- SYNTAX: The existing set of grammar productions for TryStatement in JLS 14.20 is augmented with: TryStatement: try ResourceSpecification Block Catches_opt Finally_opt Supporting new grammar productions are added: ResourceSpecification: ( Resources ) Resources: Resource Resource ; Resources Resource: VariableModifiers Type VariableDeclaratorId = Expression Expression [An implication of the combined grammar is that a try statement must have at least one of a catch clause, a finally block, and a resource specification. Furthermore, it is permissible for a try statement to have exactly one of these three components. Note that it is illegal to have a trailing semi-colon in the resource specification.] A try-with-resources statement has a resource specification that expresses resources to be automatically closed at the end of the Block. A resource specification declares one or more local variables and/or has one or more expressions, each of whose type must be a subtype of AutoCloseable or a compile-time error occurs. If a resource specification declares a variable, the variable must not have the same name as a variable declared earlier in the resource specification, a local variable, or parameter of the method or initializer block immediately enclosing the try statement, or a compile-time error occurs. The scope of a variable declared in a resource specification of a try-with-resources statement (?14.20) is from the declaration rightward over the remainder of the resource specification and the entire Block associated with the try. Within the Block of the try, the name of the variable may not be redeclared as a local variable of the directly enclosing method or initializer block, nor may it be redeclared as an exception parameter of a catch clause in a try statement of the directly enclosing method or initializer block, nor may it be redeclared as a variable in the resource specification, or a compile-time error occurs. However, a variable declared in a resource specification may be shadowed (?6.3.1) anywhere inside a class declaration nested within the Block of the try. The meaning of a try-with-resources statement with a Catches clause or Finally block is given by translation to a try-with-resources statement with no Catches clause or Finally block: try ResourceSpecification Block Catches_opt Finally_opt => try { try ResourceSpecification Block } Catches_opt Finally_opt In a try-with-resources statement that manages a single resource: * If the initialization of the resource completes abruptly because of a throw of a value V, or if the Block of the try-with-resources statement completes abruptly because of a throw of a value V and the automatic closing of the resource completes normally, then the try-with-resources statement completes abruptly because of the throw of value V. * If the Block of the try-with-resources statement completes abruptly because of a throw of a value V1, and the automatic closing of the resource completes abruptly because of a throw of a value V2, then the try-with-resources statement completes abruptly because of the throw of value V1, provided that V2 is an Exception. In this case, V2 is added to the suppressed exception list of V1. If V2 is an error (i.e. a Throwable that is not an Exception), then the try-with-resources statement completes abruptly because of the throw of value V2. In this case, V1 is not suppressed by V2. If a try-with-resources statement that manages multiple resources: * If the initialization of a resource completes abruptly because of a throw of a value V, or if the Block of the try-with-resources statement completes abruptly because of a throw of a value V (which implies that the initialization of all resources completed normally) and the automatic closings of all resources completes normally, then the try-with-resources statement completes abruptly because of the throw of value V. * If the Block of the try-with-resources statement completes abruptly because of a throw of a value V1, and the automatic closings of one or more resources (that were previously successfully initialized) complete abruptly because of throws of values V2...Vn, then the try-with-resources statement completes abruptly because of the throw of a value Vi (1 <= i <= n) determined by the translation below. The exceptions that can be thrown by a try-with-resources statement are the exceptions that can thrown by the Block of the try-with-resources statement plus the union of the exceptions that can be thrown by the automatic closing of the resources themselves. Regardless of the number of resources managed by a try-with-resources statement, it is possible for a Catches_opt clause to catch an exception due to initialization or automatic closing of any resource. A try-with-resources statement with a ResourceSpecification clause that declares multiple Resources is treated as if it were multiple try-with-resources statements, each of which has a ResourceSpecification clause that declares a single Resource. When a try-with-resources statement with n Resources (n > 1) is translated, the result is a try-with-resources statement with n-1 Resources. After n such translations, there are n nested try-catch-finally statements, and the overall translation is complete. The meaning of a try-with-resources statement with a ResourceSpecification clause and no Catches clause or Finally block is given by translation to a local variable declaration and a try-catch-finally statement. During translation, if the ResourceSpecification clause declares one Resource, then the try-catch-finally statement is not a try-with-resources statement, and ResourceSpecification_tail is empty. If the ResourceSpecification clause declares n Resources, then the try-catch-finally statement is treated as if it were a try-with-resources-catch-finally statement, where ResourceSpecificationtail is a ResourceSpecification consisting of the 2nd, 3rd, ..., nth Resources in order. The translation is as follows, where the identifiers #primaryException, #t, and #suppressedException are fresh: try ResourceSpecification Block => { final VariableModifiers_minus_final R #resource = Expression; Throwable #primaryException = null; try ResourceSpecification_tail Block catch (final Throwable #t) { #primaryException = t; throw #t; } finally { if (#primaryException != null) { try { #resource.close(); } catch(Exception #suppressedException) { #primaryException.addSuppressedException(#suppressedException); } } else { #resource.close(); } } If the Resource being translated declares a variable, then VariableModifiers_minus_final is the set of modifiers on the variable (except for final if present); R is the type of the variable declaration; and #resource is the name of the variable declared in the Resource. Discussion: Resource declarations in a resource specification are implicitly final. For consistency with existing declarations that have implicit modifiers, it is legal (though discouraged) for a programmer to provide an explicit "final" modifier. By allowing non-final modifiers, annotations such as @SuppressWarnings will be preserved on the translated code. It is unlikely that the Java programming language will ever ascribe a meaning to an explicit final modifier in this location other than the traditional meaning. [Unlike the new meaning ascribed to a final exception parameter.] Discussion: Unlike the fresh identifier in the translation of the enhanced-for statement, the #resource variable is in scope in the Block of a try-with-resources statement. If the Resource being translated is an Expression, then the translation includes an local variable declaration for which VariableModifiers_minus_final is empty; the type R is the type of the Expression (under the condition that the Expression is assigned to a variable of type AutoCloseable); and #resource is a fresh identifier. Discussion: The method Throwable.addSuppressedException has a parameter of type Throwable, but the translation is such that only an Exception from #resource.close() will be passed for suppression. In the judgment of the designers of the Java programming language, an Error due to automatic closing of a resource is sufficiently serious that it should not be automatically suppressed in favor of an exception from the Block or the initialization or automatic closing of lexically rightward resources. [However, perhaps such an Error should instead be recorded as suppressing an exception from the Block or other lexically rightward component.] Discussion: This translation exploits the improved precision of exception analysis now triggered by the rethrow of a final exception parameter. The reachability and definite assignment rules for the try statement with a resource specification are implicitly specified by the translations above. -=-=-=-=-=-=-=-=-=-=-=-=-=- Compared to the earlier proposal, this draft specification: * Assumes the revised supporting API with java.lang.AutoCloseable as the type indicating participation in the new language feature. * Changes the official grammar for a declared resource from LocalVariableDeclaration to VariableModifiers Type VariableDeclaratorId = Expression The former syntactically allowed code like AutoCloseable a, b, c which would not be useful in this context. * Preserves modifiers on explicitly declared resources, which implies @SuppressWarnings on a resource should have the intended effect. * States how the exception behavior of close methods is accounted for in determining the set of exceptions a try-with-resource statement can throw. * Gives a more precise determination of the type used for the local variable holding a resource given as an Expression. This precision is important to allow accurate exception information to be computed. * Provides typing constraints so that type inference works as expected if the Expression given as a Resource in a ResourceSpecification is, say, a generic method or null. Compiler changes implementing this revised specification remain in progress. After experience is gained with the initial implementation, I expect various changes to the feature to be contemplated: * Dropping support for a resource to be specified as a general Expression. Nontrivial specification and implementation complexities arise from allowing a general Expression to be used as resource. Allowing a restricted expression that was just a name may provide nearly all the additional flexibility at marginal additional implementation and specification impact. * Adjustments to the suppressed exception logic: in the present specification, an incoming primary exception will suppress an Exception thrown by a close method; however, if the close method throws an error, that error is propagated out without suppressing an incoming primary exception. Possible alternatives include having a primary exception in a try-with-resource statement suppress all subsequent Throwables originating in the statement and having a non-Exception thrown by a close suppress any incoming primary exception. These alternatives could be implemented by replacing the translated code try { #resource.close(); } catch(Exception #suppressedException) { #primaryException.addSuppressedException(#suppressedException); } with try { #resource.close(); } catch(Throwable #suppressedException) { #primaryException.addSuppressedException(#suppressedException); } or try { #resource.close(); } catch(Exception #suppressedException) { #primaryException.addSuppressedException(#suppressedException); } catch(Throwable #throwable) { #throwable.addSuppressedException(#primaryException); throw #throwable; } respectively. -Joe From schlosna at gmail.com Sat Jul 24 18:38:33 2010 From: schlosna at gmail.com (David Schlosnagle) Date: Sat, 24 Jul 2010 21:38:33 -0400 Subject: ARM API Support In-Reply-To: <4C22A20C.3080106@oracle.com> References: <4C22A20C.3080106@oracle.com> Message-ID: On Wed, Jun 23, 2010 at 8:08 PM, Joe Darcy wrote: > Compared to the API support in earlier versions of the ARM proposal, the > top-level interface to mark participation in ARM is in package java.lang > rather than its own package and, after consultation with the JDBC and > graphics teams, neither java.sql.* nor java.awt.Graphics were > retrofitted for ARM. I'm a little disappointed that JDBC wasn't retrofitted for AutoCloseable as this is one of the areas I've seen where resources aren't always released appropriately and can have disasterous consequences for the database. Can you provide any insight into the reasoning why JDBC was not updated to implement AutoCloseable at this time? Many of the JDBC interfaces already have `public void close() throws SQLException` methods (e.g. java.sql.Connection, java.sql.Statement, java.sql.ResultSet, etc.), so it seems a small step to have them also implement AutoCloseable. There are other JDBC interfaces that define a `public void free() throws SQLException` (e.g. java.sql.Blob, java.sql.Clob, etc.) that could benefit from AutoCloseable support, but those would require incompatible changes. Was one of the concerns JDBC providers needing to provide JDK7 specific versions of their drivers? The JDBC 4.0 update in Java 6 required Java 6 specific JDBC drivers, so there is at least some precedent for major releases requiring new drivers (whether that was a lesson learned and influenced the decision not to make JDBC changes is another story). As a chance to test out ARM, I created simple wrappers for most of the JDBC API to provide support for AutoCloseable, and I'd love any feedback: http://code.google.com/p/arm-extensions/ Here's a simple example of wrapping a javax.sql.DataSource to have it provide AutoCloseable connections: import static com.google.code.arm.sql.AutoCloseables.arm; import java.sql.SQLException; import javax.sql.DataSource; import com.google.code.arm.sql.AutoCloseConnection; import com.google.code.arm.sql.AutoClosePreparedStatement; import com.google.code.arm.sql.AutoCloseResultSet; public class AutoCloseExample { public static void main(String[] args) throws Exception { DataSource dataSource = getDataSource(); // could be injected // "arm" the datasource to get an AutoCloseable instance try ( AutoCloseConnection c = arm(dataSource).getConnection(); AutoClosePreparedStatement stmt = c.prepareStatement("select 1 from dual"); AutoCloseResultSet rs = stmt.executeQuery() ) { while (rs.next()) { // do something useful with the result set } } catch (SQLException e) { e.printStackTrace(); // includes suppressed exceptions (if any) from closing the resources } // the result set, prepared statement, and connection are all automatically closed } } Thanks, Dave From pbenedict at apache.org Mon Jul 26 07:48:37 2010 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 26 Jul 2010 09:48:37 -0500 Subject: ARM API Support Message-ID: David, I like this project! I wonder if the effort to retrofit classes with ARM is being too conservative. AutoCloseable is a new feature and no current code uses it. It's impossible that its introduction on existing classes would have unintended side-effects because the semantics are not automatic -- the interface is benign until the ARM syntax is used in source and recompiled. Kudos to David for this. Even if JDK 7 won't retrofit every case, libraries like this can help close the gap. Paul From joe.darcy at oracle.com Wed Jul 28 09:10:12 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 28 Jul 2010 09:10:12 -0700 Subject: ARM API Support In-Reply-To: References: <4C22A20C.3080106@oracle.com> Message-ID: <4C505664.2060403@oracle.com> David Schlosnagle wrote: > On Wed, Jun 23, 2010 at 8:08 PM, Joe Darcy wrote: > >> Compared to the API support in earlier versions of the ARM proposal, the >> top-level interface to mark participation in ARM is in package java.lang >> rather than its own package and, after consultation with the JDBC and >> graphics teams, neither java.sql.* nor java.awt.Graphics were >> retrofitted for ARM. >> > > I'm a little disappointed that JDBC wasn't retrofitted for > AutoCloseable as this is one of the areas I've seen where resources > aren't always released appropriately and can have disasterous > consequences for the database. Can you provide any insight into the > reasoning why JDBC was not updated to implement AutoCloseable at this > time? > > Many of the JDBC interfaces already have `public void close() throws > SQLException` methods (e.g. java.sql.Connection, java.sql.Statement, > java.sql.ResultSet, etc.), so it seems a small step to have them also > implement AutoCloseable. There are other JDBC interfaces that define a > `public void free() throws SQLException` (e.g. java.sql.Blob, > java.sql.Clob, etc.) that could benefit from AutoCloseable support, > but those would require incompatible changes. > > Was one of the concerns JDBC providers needing to provide JDK7 > specific versions of their drivers? The JDBC 4.0 update in Java 6 > required Java 6 specific JDBC drivers, so there is at least some > precedent for major releases requiring new drivers (whether that was a > lesson learned and influenced the decision not to make JDBC changes is > another story). > [snip] Lance Andersen, JDBC spec lead, left the following comment on my blog regarding JDBC support for ARM/try-with-resources: "The changes to add support for ARM would be part of JDBC 4.1 which we hope to include in Java SE 7. If JDBC 4.1 makes it into Java SE 7 we should be able to include this feature. We have been discussing this in the JDBC EG and at this time we do not see any potential gotchas for the interfaces which support a close() method." http://blogs.sun.com/darcy/entry/project_coin_arm_api#comment-1280332609000 -Joe From schlosna at gmail.com Wed Jul 28 09:19:34 2010 From: schlosna at gmail.com (David Schlosnagle) Date: Wed, 28 Jul 2010 12:19:34 -0400 Subject: ARM API Support In-Reply-To: <4C505664.2060403@oracle.com> References: <4C22A20C.3080106@oracle.com> <4C505664.2060403@oracle.com> Message-ID: On Wed, Jul 28, 2010 at 12:10 PM, Joe Darcy wrote: > Lance Andersen, JDBC spec lead, left the following comment on my blog > regarding JDBC support for ARM/try-with-resources: > > "The changes to add support for ARM would be part of JDBC 4.1 which we hope > to include in Java SE 7. ?If JDBC 4.1 makes it into Java SE 7 we should be > able to include this feature. ?We have been discussing this in the JDBC EG > and at this time we do not see any potential gotchas for the interfaces > which support a close() method." > > http://blogs.sun.com/darcy/entry/project_coin_arm_api#comment-1280332609000 > > -Joe Joe, Thanks! I'd love for ARM support to be included in the JDBC spec and Java SE 7. There is one JDBC specific interaction with AutoCloseable that developers would need to be cautious of -- the java.sql.Connection needs to be committed or rolled back prior to the invocation of close() (whether explicit or implicit via the ARM construct) [1]. This isn't really any different than if someone was already explicitly closing the Connection, but I could see some cases where developers naively assume that using the ARM construct with a Connection would automatically handle this for them, and unfortunately this could be considered a violation of the "do no harm" principle. Adapting any other APIs to AutoCloseable seems reasonable through library support, at least until JDK7 support becomes prevalent enough for developers to adopt AutoCloseable. [1]: http://java.sun.com/javase/6/docs/api/java/sql/Connection.html#close%28%29 It is strongly recommended that an application explicitly commits or rolls back an active transaction prior to calling the close method. If the close method is called and there is an active transaction, the results are implementation-defined. - Dave From fw at deneb.enyo.de Wed Jul 28 12:56:55 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 28 Jul 2010 21:56:55 +0200 Subject: ARM API Support In-Reply-To: <4C505664.2060403@oracle.com> (Joe Darcy's message of "Wed, 28 Jul 2010 09:10:12 -0700") References: <4C22A20C.3080106@oracle.com> <4C505664.2060403@oracle.com> Message-ID: <87eiengz20.fsf@mid.deneb.enyo.de> * Joe Darcy: > Lance Andersen, JDBC spec lead, left the following comment on my blog > regarding JDBC support for ARM/try-with-resources: > > "The changes to add support for ARM would be part of JDBC 4.1 which we > hope to include in Java SE 7. If JDBC 4.1 makes it into Java SE 7 we > should be able to include this feature. We have been discussing this in > the JDBC EG and at this time we do not see any potential gotchas for the > interfaces which support a close() method." > > http://blogs.sun.com/darcy/entry/project_coin_arm_api#comment-1280332609000 Will you add an AutoCloseable2 interface for JDBC? Or the source-level incompatibility which results from retrofitting to an existing interface acceptable in this case? From joe.darcy at oracle.com Wed Jul 28 14:03:29 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 28 Jul 2010 14:03:29 -0700 Subject: ARM API Support In-Reply-To: <87eiengz20.fsf@mid.deneb.enyo.de> References: <4C22A20C.3080106@oracle.com> <4C505664.2060403@oracle.com> <87eiengz20.fsf@mid.deneb.enyo.de> Message-ID: <4C509B21.6050409@oracle.com> Florian Weimer wrote: > * Joe Darcy: > > >> Lance Andersen, JDBC spec lead, left the following comment on my blog >> regarding JDBC support for ARM/try-with-resources: >> >> "The changes to add support for ARM would be part of JDBC 4.1 which we >> hope to include in Java SE 7. If JDBC 4.1 makes it into Java SE 7 we >> should be able to include this feature. We have been discussing this in >> the JDBC EG and at this time we do not see any potential gotchas for the >> interfaces which support a close() method." >> >> http://blogs.sun.com/darcy/entry/project_coin_arm_api#comment-1280332609000 >> > > Will you add an AutoCloseable2 interface for JDBC? Or the > source-level incompatibility which results from retrofitting to an > existing interface acceptable in this case? > There are no source compatibility issues with making a class implement another interface if no new methods are added. -Joe From fw at deneb.enyo.de Wed Jul 28 22:28:37 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 29 Jul 2010 07:28:37 +0200 Subject: ARM API Support In-Reply-To: <4C509B21.6050409@oracle.com> (Joe Darcy's message of "Wed, 28 Jul 2010 14:03:29 -0700") References: <4C22A20C.3080106@oracle.com> <4C505664.2060403@oracle.com> <87eiengz20.fsf@mid.deneb.enyo.de> <4C509B21.6050409@oracle.com> Message-ID: <874ofionzu.fsf@mid.deneb.enyo.de> * Joe Darcy: > There are no source compatibility issues with making a class implement > another interface if no new methods are added. I think this statement permits certain exceptions. Here's code that breaks when a class implements another interface. class ToBeChanged implements I1 /*, I2 */ { } interface I1 { } interface I2 { } interface Dispatch { void action(I1 o); void action(I2 o); } class User { void use(Dispatch d, ToBeChanged o) { d.action(o); } } This particular case cannot happen if I2 is fresh and introduced at the time as ToBeChanged is changed because the user could not have written the Dispatch class. From joe.darcy at oracle.com Thu Jul 29 16:39:32 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 29 Jul 2010 16:39:32 -0700 Subject: ARM API Support In-Reply-To: <874ofionzu.fsf@mid.deneb.enyo.de> References: <4C22A20C.3080106@oracle.com> <4C505664.2060403@oracle.com> <87eiengz20.fsf@mid.deneb.enyo.de> <4C509B21.6050409@oracle.com> <874ofionzu.fsf@mid.deneb.enyo.de> Message-ID: <4C521134.4050901@oracle.com> Florian Weimer wrote: > * Joe Darcy: > > >> There are no source compatibility issues with making a class implement >> another interface if no new methods are added. >> > > I think this statement permits certain exceptions. > Most rules do ;-) > Here's code that breaks when a class implements another interface. > > class ToBeChanged implements I1 /*, I2 */ { > } > > interface I1 { > } > > interface I2 { > } > > interface Dispatch { > void action(I1 o); > void action(I2 o); > } > > class User { > void use(Dispatch d, ToBeChanged o) { > d.action(o); > } > } > > This particular case cannot happen if I2 is fresh and introduced at > the time as ToBeChanged is changed because the user could not have > written the Dispatch class. > Yes, if I2 is a pre-existing interface, the meaning of existing call sites can be changed. However, that is not the case for AutoCloseable and even when retrofitting Closeable, this case is of only minor concern. Cheers, -Joe From fw at deneb.enyo.de Thu Jul 29 22:20:53 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 30 Jul 2010 07:20:53 +0200 Subject: ARM API Support In-Reply-To: <4C521134.4050901@oracle.com> (Joe Darcy's message of "Thu, 29 Jul 2010 16:39:32 -0700") References: <4C22A20C.3080106@oracle.com> <4C505664.2060403@oracle.com> <87eiengz20.fsf@mid.deneb.enyo.de> <4C509B21.6050409@oracle.com> <874ofionzu.fsf@mid.deneb.enyo.de> <4C521134.4050901@oracle.com> Message-ID: <87eielr1e2.fsf@mid.deneb.enyo.de> * Joe Darcy: > Yes, if I2 is a pre-existing interface, the meaning of existing call > sites can be changed. However, that is not the case for AutoCloseable It will be for the JDBC interfaces if they are retrofitted post-JDK7, and I thought that was the current plan. From franzwong at gmail.com Fri Jul 30 00:54:37 2010 From: franzwong at gmail.com (Franz Wong) Date: Fri, 30 Jul 2010 15:54:37 +0800 Subject: Xor for byte Message-ID: Hi mailing list, I don't know if it is suitable to ask this question in this mailing list. I would like to ask why Java requires XOR for integer only instead of byte. Would it be better if XOR applies to byte also? Regards, Franz From opinali at gmail.com Fri Jul 30 05:15:54 2010 From: opinali at gmail.com (Osvaldo Doederlein) Date: Fri, 30 Jul 2010 09:15:54 -0300 Subject: Xor for byte In-Reply-To: References: Message-ID: The Java bytecode contains only the instructions ixor (for int) and lxor (for long); it doesn't have specific opcodes for short- or byte-xor. The same is true for several other operations, e.g. there's no byte-mul bytecode so you cannot multiply bytes either, the compiler will always report "cannot convert int to byte" because it promotes the operands to int, then does an imul, which result is int. IMHO this is a kind of tail-wags-dog situation, there's no reason why the Java language should be constrained so much by the Java bytecode. Recent syntax features (esp. post-Java5, but even some old stuff like inner classes) require extensive workarounds to perform things that the bytecode doesn't directly support. Maybe it's a good time to fix the "little things", i.e., byte a, b, c; c = a ^ b; could easily be compiled with existing bytecode: just do the int->byte narrowing implicitly. This narrowing is a no-brainer as the xor op won't ever produce extra bits that don't fit in a byte. The big problem is (as usual) backwards compatibility. If we try the same change for multiplication, to accept "c = a * b", this will potentially lose some bits because the result of the multiplication, currently defined as a imul, may not fit in a byte (or short, for that matter). This doesn't matter when the result is being assigned to a byte lvalue like c; this requires to lose extra bits anyway, and it's illegal (without explicit cast) in the current language so there's no legacy code to break. The problem though, is that there are certainly lots of legacy code like this: byte a, b; int c; c = a * b; ...and such code, which IS legal in the current language, WOULD break with a naive language change that just auto-narrows a * b to byte (or short, for that matter, if the wider type of {a,b} is short). But even this problem can be fixed, with target typing - a mechanism that's being increasingly adopted by Java (due to needs of type inference). This is quite simple: the compiler would only perform this auto-narrowinfg when the result is immediately used in a context that expects a byte. Then we're back to a scenario that contains a semantic change, but only affects code that is currently illegal, so there's no possible backwards-compat breakage. A+ Osvaldo 2010/7/30 Franz Wong : > Hi mailing list, > > I don't know if it is suitable to ask this question in this mailing list. I > would like to ask why Java requires XOR for integer only instead of byte. > Would it be better if XOR applies to byte also? > > Regards, > Franz > > From joe.darcy at oracle.com Fri Jul 30 08:48:22 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 30 Jul 2010 08:48:22 -0700 Subject: ARM API Support In-Reply-To: <87eielr1e2.fsf@mid.deneb.enyo.de> References: <4C22A20C.3080106@oracle.com> <4C505664.2060403@oracle.com> <87eiengz20.fsf@mid.deneb.enyo.de> <4C509B21.6050409@oracle.com> <874ofionzu.fsf@mid.deneb.enyo.de> <4C521134.4050901@oracle.com> <87eielr1e2.fsf@mid.deneb.enyo.de> Message-ID: <4C52F446.2030404@oracle.com> Florian Weimer wrote: > * Joe Darcy: > > >> Yes, if I2 is a pre-existing interface, the meaning of existing call >> sites can be changed. However, that is not the case for AutoCloseable >> > > It will be for the JDBC interfaces if they are retrofitted post-JDK7, > and I thought that was the current plan. > Please reread the message from Lance Andersen, the JDBC spec lead: http://mail.openjdk.java.net/pipermail/coin-dev/2010-July/002802.html Additionally, the general evolution policy of the JDK has never included such a degree of extreme source compatibility: http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy -Joe From joe.darcy at oracle.com Fri Jul 30 08:48:40 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 30 Jul 2010 08:48:40 -0700 Subject: Xor for byte In-Reply-To: References: Message-ID: <4C52F458.4040001@oracle.com> Greetings. The Project Coin list is not a forum for general question about the Java programming language. Regards, -Joe Darcy Franz Wong wrote: > Hi mailing list, > > I don't know if it is suitable to ask this question in this mailing list. I > would like to ask why Java requires XOR for integer only instead of byte. > Would it be better if XOR applies to byte also? > > Regards, > Franz > > From franzwong at gmail.com Fri Jul 30 11:53:07 2010 From: franzwong at gmail.com (Franz Wong) Date: Sat, 31 Jul 2010 02:53:07 +0800 Subject: Xor for byte In-Reply-To: <4C52F458.4040001@oracle.com> References: <4C52F458.4040001@oracle.com> Message-ID: Sorry for that. I was thinking this list allows subscribers to request language changes. And thanks Osvaldo for answering. Franz On Fri, Jul 30, 2010 at 11:48 PM, Joe Darcy wrote: > Greetings. > > The Project Coin list is not a forum for general question about the Java > programming language. > > Regards, > > -Joe Darcy > > > Franz Wong wrote: > >> Hi mailing list, >> >> I don't know if it is suitable to ask this question in this mailing list. >> I >> would like to ask why Java requires XOR for integer only instead of byte. >> Would it be better if XOR applies to byte also? >> >> Regards, >> Franz >> >> >> > > From joe.darcy at oracle.com Sat Jul 31 00:06:37 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 31 Jul 2010 00:06:37 -0700 Subject: Xor for byte In-Reply-To: References: <4C52F458.4040001@oracle.com> Message-ID: <4C53CB7D.1010208@oracle.com> Franz Wong wrote: > Sorry for that. I was thinking this list allows subscribers to request > language changes. Let's see, the Project Coin project page [1] says: > An open call for proposals period ran from February 27, 2009 through > March 30, 2009. The nearly 70 proposal forms that were submitted > received extensive discussion on the Project Coin mailing list, coin-dev. During that call for proposals period nearly a year and a half ago, the proposal form was a detailed document about the language change for those who wanted to actively *participate* in developing language changes. This mailing list is named coin-*dev* not coin-please-implement-my-request-for-me. Simple requests for language changes belong at: http://bugreport.sun.com/bugreport/ -Joe [1] http://openjdk.java.net/projects/coin/ > > And thanks Osvaldo for answering. > > Franz > > On Fri, Jul 30, 2010 at 11:48 PM, Joe Darcy > wrote: > > Greetings. > > The Project Coin list is not a forum for general question about > the Java programming language. > > Regards, > > -Joe Darcy > > > Franz Wong wrote: > > Hi mailing list, > > I don't know if it is suitable to ask this question in this > mailing list. I > would like to ask why Java requires XOR for integer only > instead of byte. > Would it be better if XOR applies to byte also? > > Regards, > Franz > > > > >