From joe.darcy at ORACLE.COM Wed Sep 8 09:45:27 2010 From: joe.darcy at ORACLE.COM (Joe Darcy) Date: Wed, 08 Sep 2010 09:45:27 -0700 Subject: Project Coin possibilities under JDK 7 plan A and plan B Message-ID: <4C87BDA7.6080101@oracle.com> Greetings. As you may have seen Mark Reinhold announce in various venues [1] [2], Oracle is rethinking the plan for JDK 7. In summary, the two plans under consideration with their ship dates are: > Plan A: JDK 7 (as currently defined) Mid 2012 > > Plan B: JDK 7 (minus Lambda, Jigsaw, and part of Coin) Mid 2011 > JDK 8 (Lambda, Jigsaw, the rest of Coin, ++) Late 2012 Oracle is leaning heavily toward plan B, but is also soliciting feedback on the plans, as indicated in Mark's announcement. For Project Coin, the maximum likelihood outcome [3] under plan B is that the currently implemented Coin features: * binary literals and underscores in literals * strings in switch * diamond operator * improved exception handling * simplified varargs method invocation * try-with-resources will be included in JDK 7, subject to future refinements and revisions (and even possible removals) as experience is gained with the features. The remaining accepted Coin features would then be reconsidered in the context of other language changes being planned for JDK 8. -Joe [1] http://blogs.sun.com/mr/entry/rethinking_jdk7 [2] http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-September/001528.html [3] http://en.wikipedia.org/wiki/Maximum_likelihood From joe.darcy at oracle.com Fri Sep 10 16:19:27 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 10 Sep 2010 16:19:27 -0700 Subject: JDBC 4.1 and try-with-resources Message-ID: <4C8ABCFF.7010404@oracle.com> Hello. I'm happy to report that Lance Andersen and the JDBC expert group have decided to support the new try-with-resources statement in JDBC 4.1. Lance just pushed a change set [1] for JDBC 4.1 that retrofits the AutoCloseable interface to the types: * java.sql.Connection * java.sql.ResultSet * java.sql.Statement The change will be available in the JDK 7 promoted builds [2] in due course. -Joe [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c786a9c927fd [2] http://dlc.sun.com.edgesuite.net/jdk7/binaries/index.html From jjb at google.com Sat Sep 11 00:30:25 2010 From: jjb at google.com (Joshua Bloch) Date: Sat, 11 Sep 2010 09:30:25 +0200 Subject: JDBC 4.1 and try-with-resources In-Reply-To: <4C8ABCFF.7010404@oracle.com> References: <4C8ABCFF.7010404@oracle.com> Message-ID: Joe, That's marvelous news! I'm thrilled that the many JDBC users will be able to enjoy the benefits of this construct. Thanks to Lance and all those who made this happen. Regards from Elba, Josh On 9/11/10, Joe Darcy wrote: > Hello. > > I'm happy to report that Lance Andersen and the JDBC expert group have > decided to support the new try-with-resources statement in JDBC 4.1. > Lance just pushed a change set [1] for JDBC 4.1 that retrofits the > AutoCloseable interface to the types: > > * java.sql.Connection > * java.sql.ResultSet > * java.sql.Statement > > The change will be available in the JDK 7 promoted builds [2] in due course. > > -Joe > > [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c786a9c927fd > [2] http://dlc.sun.com.edgesuite.net/jdk7/binaries/index.html > > > > > From ralf at ralfebert.de Wed Sep 15 05:33:10 2010 From: ralf at ralfebert.de (Ralf Ebert) Date: Wed, 15 Sep 2010 14:33:10 +0200 Subject: throw with String Message-ID: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> I realize that I am late here, but wanted to propose another little small language change anyway: --- throw "error" should be a shortcut to throw new RuntimeException("error") --- I recently added this to the Eclipse Java compiler (for educational purposes only), it's just a tiny change, not even requiring a grammar change: http://www.ralfebert.de/blog/java_hacking/throw_string/ Greetings, Ralf From dalibor.topic at oracle.com Wed Sep 15 10:52:04 2010 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 15 Sep 2010 10:52:04 -0700 Subject: throw with String In-Reply-To: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> Message-ID: <4C9107C4.4040501@oracle.com> On 9/15/10 5:33 AM, Ralf Ebert wrote: > I realize that I am late here, but wanted to propose another little > small language change anyway: Hi Ralf, Please see http://mail.openjdk.java.net/pipermail/coin-dev/2009-December/002663.html cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | | | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From thomas.andreas.jung at googlemail.com Wed Sep 15 12:03:23 2010 From: thomas.andreas.jung at googlemail.com (Thomas Jung) Date: Wed, 15 Sep 2010 21:03:23 +0200 Subject: throw with String In-Reply-To: <4C9107C4.4040501@oracle.com> References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> <4C9107C4.4040501@oracle.com> Message-ID: Beside the organizational details, throwing RuntimeException all over the place is not very useful. You would have to support better pattern matching to make it bearable. Setting up an exception type hierarchy will pay off. Maybe scripting is the only exception but this is something Java is not the best choice for. Thomas On 15 September 2010 19:52, Dalibor Topic wrote: > On 9/15/10 5:33 AM, Ralf Ebert wrote: >> I realize that I am late here, but wanted to propose another little >> small language change anyway: > > Hi Ralf, > > Please see http://mail.openjdk.java.net/pipermail/coin-dev/2009-December/002663.html > > cheers, > dalibor topic > -- > Oracle > Dalibor Topic | Java F/OSS Ambassador > Phone: +494023646738 | | | Mobile: +491772664192 > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Rijnzathe 6, 3454PV De Meern, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven > > Green Oracle Oracle is committed to developing practices and products that help protect the environment > > From ralf at ralfebert.de Wed Sep 15 12:50:11 2010 From: ralf at ralfebert.de (Ralf Ebert) Date: Wed, 15 Sep 2010 21:50:11 +0200 Subject: throw with String In-Reply-To: References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> <4C9107C4.4040501@oracle.com> Message-ID: <1284580211.3111.212.camel@lucy.SSG5-Serial-WLAN> > Beside the organizational details, throwing RuntimeException all over > the place is not very useful. You would have to support better pattern > matching to make it bearable. Setting up an exception type hierarchy > will pay off. Maybe scripting is the only exception but this is > something Java is not the best choice for. For errors that are supposed to be handled in code, exception hierarchies and 'throw new MyException()' statements are perfectly fine of course. But a fair share of exceptions thrown in Java software are exceptions that can never be specifically handled. This includes assertions and situations that can only occur because of programming errors. For these, exception hierarchies are often declared without need, because 'throw new RuntimeException' in considered somewhat in bad style by some programmers (without much reason in my humble opinion). Sorry for not noticing the 'project coin ended' message, I'll file a bug report about the proposal. - Ralf From dalibor.topic at oracle.com Wed Sep 15 13:22:02 2010 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 15 Sep 2010 13:22:02 -0700 Subject: throw with String In-Reply-To: <1284580211.3111.212.camel@lucy.SSG5-Serial-WLAN> References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> <4C9107C4.4040501@oracle.com> <1284580211.3111.212.camel@lucy.SSG5-Serial-WLAN> Message-ID: <4C912AEA.8080206@oracle.com> On 9/15/10 12:50 PM, Ralf Ebert wrote: > Sorry for not noticing the 'project coin ended' message, I'll file a bug > report about the proposal. Thanks, Ralf. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | | | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From forax at univ-mlv.fr Wed Sep 15 15:08:49 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 16 Sep 2010 00:08:49 +0200 Subject: throw with String In-Reply-To: <1284580211.3111.212.camel@lucy.SSG5-Serial-WLAN> References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> <4C9107C4.4040501@oracle.com> <1284580211.3111.212.camel@lucy.SSG5-Serial-WLAN> Message-ID: <4C9143F1.9060008@univ-mlv.fr> Le 15/09/2010 21:50, Ralf Ebert a ?crit : >> Beside the organizational details, throwing RuntimeException all over >> the place is not very useful. You would have to support better pattern >> matching to make it bearable. Setting up an exception type hierarchy >> will pay off. Maybe scripting is the only exception but this is >> something Java is not the best choice for. >> > For errors that are supposed to be handled in code, exception > hierarchies and 'throw new MyException()' statements are perfectly fine > of course. But a fair share of exceptions thrown in Java software are > exceptions that can never be specifically handled. This includes > assertions and situations that can only occur because of programming > errors. For these, exception hierarchies are often declared without > need, because 'throw new RuntimeException' in considered somewhat in bad > style by some programmers (without much reason in my humble opinion). > Do you mean that it's not useful to make a difference between a NPE and an AIOOB ? > Sorry for not noticing the 'project coin ended' message, I'll file a bug > report about the proposal. > > - Ralf > R?mi From opinali at gmail.com Wed Sep 15 15:46:11 2010 From: opinali at gmail.com (Osvaldo Doederlein) Date: Wed, 15 Sep 2010 19:46:11 -0300 Subject: throw with String In-Reply-To: <4C9143F1.9060008@univ-mlv.fr> References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> <4C9107C4.4040501@oracle.com> <1284580211.3111.212.camel@lucy.SSG5-Serial-WLAN> <4C9143F1.9060008@univ-mlv.fr> Message-ID: As my $2c, translated excerpt of my latest article (Brazilian Java Magazine's cover story on the Java 7 language - too bad the new delay...): "One endless debate about the Java language is checked exceptions. Some Pharisees consider this a design error. (...) It's true though that checked exceptions can result in bulky code, especially with badly-designed APIs: checked exceptions that should have been unchecked; failure to define a good hierarchy (...) Adding everything - ARM, Multi-Catch, Final Rethrow and API tunings like ReflectiveOperationException, and also other specs like EJB 3 (no RemoteException) - exception handling has become MUCH cleaner in Java 7. We keep the huge advantage of Java of allowing tight policies for error handling, ensuring compiler validation, but without imposing a high price in boilerplate, repetitive code." For another $2c, the only design mistake (IMHO) and remaining problem, is that exceptions should have been defined as a special kind of interface (just like annotations in Java 5), so we could use multiple inheritance for really good exception hierarchies, and also to prevent abuse (it's extremely rare the need of any custom code inside exception classes, other that trivial stuff like constructors/getters/setters for properties, which could be compiler-generated just like javac does for for annotations). Removing the explicit "new" operator from throw's syntax would also provide the runtime with some extra leeway for optimization (reusing exception objects automatically when possible; allocating a lightweight stub implementation [basically just doing a longjmp] when the exception's properties and stack trace are never used, etc.) Too bad that Microsoft, with C#, ignored the great opportunity to fix and enhance Java's checked exceptions, preferring the easier and "demagogic" option to just drop them. The horrendous absence of checked exceptions is the single thing that makes C# hard for me to love, even with its many cool features. And yep, -1 to that idea of throwing strings or other simple values. :) A+ Osvaldo 2010/9/15 R?mi Forax : > Le 15/09/2010 21:50, Ralf Ebert a ?crit : >>> Beside the organizational details, throwing RuntimeException all over >>> the place is not very useful. You would have to support better pattern >>> matching to make it bearable. Setting up an exception type hierarchy >>> will pay off. Maybe scripting is the only exception but this is >>> something Java is not the best choice for. >>> >> For errors that are supposed to be handled in code, exception >> hierarchies and 'throw new MyException()' statements are perfectly fine >> of course. But a fair share of exceptions thrown in Java software are >> exceptions that can never be specifically handled. This includes >> assertions and situations that can only occur because of programming >> errors. For these, exception hierarchies are often declared without >> need, because 'throw new RuntimeException' in considered somewhat in bad >> style by some programmers (without much reason in my humble opinion). >> > > Do you mean that it's not useful to make a difference between > a NPE and an AIOOB ? > >> Sorry for not noticing the 'project coin ended' message, I'll file a bug >> report about the proposal. >> >> - Ralf >> > > R?mi > > From ralf at ralfebert.de Wed Sep 15 15:49:43 2010 From: ralf at ralfebert.de (Ralf Ebert) Date: Thu, 16 Sep 2010 00:49:43 +0200 Subject: throw with String In-Reply-To: <4C9143F1.9060008@univ-mlv.fr> References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> <4C9107C4.4040501@oracle.com> <1284580211.3111.212.camel@lucy.SSG5-Serial-WLAN> <4C9143F1.9060008@univ-mlv.fr> Message-ID: <1284590983.3111.238.camel@lucy.SSG5-Serial-WLAN> > Do you mean that it's not useful to make a difference between > a NPE and an AIOOB ? No. I was saying that sometimes code is written that throws exceptions where the author knows that nobody wants to specifically catch this type of exception. For NullPointerException and ArrayIndexOutOfBoundsException, no idea, I could imagine it being useful when writing code that can recover from programming errors. But despite from that, what's the use case for making that difference or doing a catch(ArrayIndexOutOfBoundsException e)? Ralf From thomas.andreas.jung at googlemail.com Wed Sep 15 23:32:30 2010 From: thomas.andreas.jung at googlemail.com (Thomas Jung) Date: Thu, 16 Sep 2010 08:32:30 +0200 Subject: throw with String In-Reply-To: <1284590983.3111.238.camel@lucy.SSG5-Serial-WLAN> References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> <4C9107C4.4040501@oracle.com> <1284580211.3111.212.camel@lucy.SSG5-Serial-WLAN> <4C9143F1.9060008@univ-mlv.fr> <1284590983.3111.238.camel@lucy.SSG5-Serial-WLAN> Message-ID: > I was saying that sometimes code is written that throws exceptions > where the author knows that nobody wants to specifically catch this type > of exception. Isn't this a java.lang.Error: "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch." Thomas From ralf at ralfebert.de Thu Sep 16 01:25:39 2010 From: ralf at ralfebert.de (Ralf Ebert) Date: Thu, 16 Sep 2010 10:25:39 +0200 Subject: throw with String In-Reply-To: References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> <4C9107C4.4040501@oracle.com> <1284580211.3111.212.camel@lucy.SSG5-Serial-WLAN> <4C9143F1.9060008@univ-mlv.fr> <1284590983.3111.238.camel@lucy.SSG5-Serial-WLAN> Message-ID: <1284625539.25004.13.camel@lucy.SSG5-Serial-WLAN> > Isn't this a java.lang.Error: > > "An Error is a subclass of Throwable that indicates serious problems > that a reasonable application should not try to catch." imho "serious" means "JVM almost dying", I was thinking more about casual, unserious errors like: throw new RuntimeException("You can specify a width in pixel OR in percent, but not both!"); throw new RuntimeException("setFoo() requires bar."); throw new RuntimeException("Value cannot be set because of null value in nested property 'foo'!"); (these are cases from a library I'm writing where I'm very sure than an application developer is misusing the library when trying to catch one of these exceptions specifically) Ralf From pdoubleya at gmail.com Thu Sep 16 02:10:54 2010 From: pdoubleya at gmail.com (Patrick Wright) Date: Thu, 16 Sep 2010 11:10:54 +0200 Subject: throw with String In-Reply-To: <1284625539.25004.13.camel@lucy.SSG5-Serial-WLAN> References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> <4C9107C4.4040501@oracle.com> <1284580211.3111.212.camel@lucy.SSG5-Serial-WLAN> <4C9143F1.9060008@univ-mlv.fr> <1284590983.3111.238.camel@lucy.SSG5-Serial-WLAN> <1284625539.25004.13.camel@lucy.SSG5-Serial-WLAN> Message-ID: People - pretty soon Joe Darcy is going to show up in a bad mood. Project Coin is not interested in any more submissions or discussion like this, and if it were, as Joe will soon remind you, it would only be with a detailed proposal for how it should work and be implemented. The list is now just used for updates regarding the implementations of the respective proposals that were selected. It's an interesting discussion, but I think you should just take it somewhere else. Regards Patrick On Thu, Sep 16, 2010 at 10:25 AM, Ralf Ebert wrote: >> Isn't this a java.lang.Error: >> >> "An Error is a subclass of Throwable that indicates serious problems >> that a reasonable application should not try to catch." > > imho "serious" means "JVM almost dying", I was thinking more about > casual, unserious errors like: > > throw new RuntimeException("You can specify a width in pixel OR in > percent, but not both!"); > throw new RuntimeException("setFoo() requires bar."); > throw new RuntimeException("Value cannot be set because of null value in > nested property 'foo'!"); > > (these are cases from a library I'm writing where I'm very sure than an > application developer is misusing the library when trying to catch one > of these exceptions specifically) > > Ralf > > > From David.Holmes at oracle.com Thu Sep 16 02:09:50 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 16 Sep 2010 19:09:50 +1000 Subject: throw with String In-Reply-To: <1284625539.25004.13.camel@lucy.SSG5-Serial-WLAN> References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> <4C9107C4.4040501@oracle.com> <1284580211.3111.212.camel@lucy.SSG5-Serial-WLAN> <4C9143F1.9060008@univ-mlv.fr> <1284590983.3111.238.camel@lucy.SSG5-Serial-WLAN> <1284625539.25004.13.camel@lucy.SSG5-Serial-WLAN> Message-ID: <4C91DEDE.4090408@oracle.com> Ralf Ebert said the following on 09/16/10 18:25: >> Isn't this a java.lang.Error: >> >> "An Error is a subclass of Throwable that indicates serious problems >> that a reasonable application should not try to catch." > > imho "serious" means "JVM almost dying", I was thinking more about > casual, unserious errors like: > > throw new RuntimeException("You can specify a width in pixel OR in > percent, but not both!"); IllegalArgumentException. This should be part of the API contract. (Though it sounds to me like a design issue with the API.) > throw new RuntimeException("setFoo() requires bar."); IllegalStateException. Again part of contract. > throw new RuntimeException("Value cannot be set because of null value in > nested property 'foo'!"); Either of the above depending on context but again part of the API contract. Use the right exception to do the job IMHO. David Holmes > (these are cases from a library I'm writing where I'm very sure than an > application developer is misusing the library when trying to catch one > of these exceptions specifically) > > Ralf > > From Ulf.Zibis at gmx.de Thu Sep 16 02:19:04 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 16 Sep 2010 11:19:04 +0200 Subject: throw with String In-Reply-To: References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> <4C9107C4.4040501@oracle.com> <1284580211.3111.212.camel@lucy.SSG5-Serial-WLAN> <4C9143F1.9060008@univ-mlv.fr> <1284590983.3111.238.camel@lucy.SSG5-Serial-WLAN> <1284625539.25004.13.camel@lucy.SSG5-Serial-WLAN> Message-ID: <4C91E108.9050209@gmx.de> Am 16.09.2010 11:10, schrieb Patrick Wright: > People - pretty soon Joe Darcy is going to show up in a bad mood. > Project Coin is not interested in any more submissions or discussion > like this, and if it were, as Joe will soon remind you, it would only > be with a detailed proposal for how it should work and be implemented. > The list is now just used for updates regarding the implementations of > the respective proposals that were selected. +1 > It's an interesting discussion, but I think you should just take it > somewhere else. ... but there seems to be a need for a place for such java language discussions. Is there one? -Ulf From Ulf.Zibis at gmx.de Thu Sep 16 03:16:47 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 16 Sep 2010 12:16:47 +0200 Subject: throw with String In-Reply-To: <4C91E108.9050209@gmx.de> References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> <4C9107C4.4040501@oracle.com> <1284580211.3111.212.camel@lucy.SSG5-Serial-WLAN> <4C9143F1.9060008@univ-mlv.fr> <1284590983.3111.238.camel@lucy.SSG5-Serial-WLAN> <1284625539.25004.13.camel@lucy.SSG5-Serial-WLAN> <4C91E108.9050209@gmx.de> Message-ID: <4C91EE8F.5030507@gmx.de> Am 16.09.2010 11:19, schrieb Ulf Zibis: > Am 16.09.2010 11:10, schrieb Patrick Wright: >> People - pretty soon Joe Darcy is going to show up in a bad mood. >> Project Coin is not interested in any more submissions or discussion >> like this, and if it were, as Joe will soon remind you, it would only >> be with a detailed proposal for how it should work and be implemented. >> The list is now just used for updates regarding the implementations of >> the respective proposals that were selected. > +1 > >> It's an interesting discussion, but I think you should just take it >> somewhere else. > ... but there seems to be a need for a place for such java language discussions. Is there one? The question above was meant rhetorically: Is there one officially hosted from java.net etc.? If not, it maybe should become installed there. -Ulf From alexander.veit at gmx.net Sat Sep 18 04:18:35 2010 From: alexander.veit at gmx.net (Alexander Veit) Date: Sat, 18 Sep 2010 13:18:35 +0200 Subject: throw with String In-Reply-To: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> References: <1284553990.3111.50.camel@lucy.SSG5-Serial-WLAN> Message-ID: <001701cb5723$3d1688f0$b7439ad0$@veit@gmx.net> > I realize that I am late here, but wanted to propose another little > small language change anyway: > > --- > throw "error" > > should be a shortcut to > > throw new RuntimeException("error") > --- Hm, I would suggest using a preprocessor, or something like raise("error"); // static import instead. -- Cheers, Alex From forax at univ-mlv.fr Fri Sep 24 07:32:55 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 24 Sep 2010 16:32:55 +0200 Subject: Is language support for collections is a coin feature ? Message-ID: <4C9CB697.3030403@univ-mlv.fr> In the list of feature deferred to JDK8 [1] "Language support for collections" is listed as a coin feature, I think it's an error. There is no way to store a constant array in the bytecode [2], If we add supports for collections literal, hitting the 64k limit will be easier. So this feature also require to modify the classfile format to store constant array as constant in the bytecode. As far as I remember, a coin feature can't modify the classfile format. Moreover, supporting only collection literal is in my opinion a half baked feature, we all know JSON [3] and how powerful this kind of literal syntax is. User user = { firstName: ''remi", lastName: "forax", addresses: [ { zipcode: "30785" }, { zipcode: "67899" } ] }; is better than User user = new User(); user.setFirstName("remi"); user.setLastName("forax"); Address addr1 = new Address(); addr1.setZipCode("30785"); Address addr2 = new Address(); addr2.setZipCode("67899"); user.setAddresses([ addr1, addr2 ]); But to support this syntax, we need to introduce properties in the language. Also note that if you have property in your language, you can write a decent binding API. From here, the new JavaFX API is not far :) So a JSR is a better place for this feature. But it seems we are short in term of new JSR :) In my opinion, the best is to hijack the JSR 295 [4], sorry I mean to reactivate JSR 295. R?mi [1] http://openjdk.java.net/projects/jdk7/features/#deferred [2] Terence Parr: Java Parsers http://wiki.jvmlangsummit.com/Image:Parr_Java_Parsers.pdf [3] http://json.org/ [4] JSR 295: Beans Binding http://jcp.org/en/jsr/detail?id=295 From eamonn.mcmanus at oracle.com Fri Sep 24 08:46:28 2010 From: eamonn.mcmanus at oracle.com (Eamonn McManus) Date: Fri, 24 Sep 2010 17:46:28 +0200 Subject: Is language support for collections is a coin feature ? In-Reply-To: <4C9CB697.3030403@univ-mlv.fr> References: <4C9CB697.3030403@univ-mlv.fr> Message-ID: <4C9CC7D4.2080006@oracle.com> Hi, Without commenting on your conclusions, I don't think your premises are correct. First of all, I don't think collection literals will be limited to constant values, so they couldn't in general be stored in the constant pool even if the classfile format were extended to allow that. Secondly, if the 64K limit on the size of methods is a concern, nothing stops the compiler from creating a private synthetic method that creates and returns the collection, in the same way as it used to create one for Foo.class literals, and even doing that recursively for really big literals. The situation is anyway exactly the same as for array literals today. Regards, ?amonn McManus -- http://weblogs.java.net/blog/emcmanus On 24/9/10 4:32 PM, R?mi Forax wrote: > In the list of feature deferred to JDK8 [1] > "Language support for collections" is listed as a coin feature, > I think it's an error. > > There is no way to store a constant array in the bytecode [2], > If we add supports for collections literal, hitting the 64k limit will > be easier. So this feature also require to modify the classfile format > to store constant array as constant in the bytecode. > As far as I remember, a coin feature can't modify the classfile format. > > Moreover, supporting only collection literal is in my opinion a half > baked feature, > we all know JSON [3] and how powerful this kind of literal syntax is. > > User user = { > firstName: ''remi", > lastName: "forax", > addresses: [ > { > zipcode: "30785" > }, { > zipcode: "67899" > } > ] > }; > > is better than > > User user = new User(); > user.setFirstName("remi"); > user.setLastName("forax"); > Address addr1 = new Address(); > addr1.setZipCode("30785"); > Address addr2 = new Address(); > addr2.setZipCode("67899"); > user.setAddresses([ addr1, addr2 ]); > > But to support this syntax, we need to introduce properties in the language. > Also note that if you have property in your language, you can write > a decent binding API. From here, the new JavaFX API is not far :) > > So a JSR is a better place for this feature. > But it seems we are short in term of new JSR :) > In my opinion, the best is to hijack the JSR 295 [4], > sorry I mean to reactivate JSR 295. > > R?mi > > > [1] http://openjdk.java.net/projects/jdk7/features/#deferred > [2] Terence Parr: Java Parsers > http://wiki.jvmlangsummit.com/Image:Parr_Java_Parsers.pdf > [3] http://json.org/ > [4] JSR 295: Beans Binding > http://jcp.org/en/jsr/detail?id=295 > > From forax at univ-mlv.fr Fri Sep 24 09:43:23 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Fri, 24 Sep 2010 18:43:23 +0200 Subject: Is language support for collections is a coin feature ? In-Reply-To: <4C9CC550.7080903@oracle.com> References: <4C9CB697.3030403@univ-mlv.fr> <4C9CC550.7080903@oracle.com> Message-ID: <4C9CD52B.2080805@univ-mlv.fr> Le 24/09/2010 17:35, Eamonn McManus a ?crit : > Hi, Hi, > > Without commenting on your conclusions, I don't think your premises > are correct. First of all, I don't think collection literals will be > limited to constant values, so they couldn't in general be stored in > the constant pool even if the classfile format were extended to allow > that. It depends how you design the new constant pool attribute. I can be a tree of constants (like the annotation values) plus some placeholders for storing values sent during the execution if by example some local variable values are needed. > Secondly, if the 64K limit on the size of methods is a concern, > nothing stops the compiler from creating a private synthetic method > that creates and returns the collection, in the same way as it used to > create one for Foo.class literals, and even doing that recursively for > really big literals. The situation is anyway exactly the same as for > array literals today. What you describe for a collection is applicable for an array, but the current compiler fails if the array of literal is too big. Splitting a method is far from obvious because you can have side effect and the number of method parameters is limited to 255. This code is legal in Java: int i =0; int[] array = {i++, i}; System.out.println(i); > > Regards, > > ?amonn McManus -- http://weblogs.java.net/blog/emcmanus > regards, R?mi > > On 24/9/10 4:32 PM, R?mi Forax wrote: >> In the list of feature deferred to JDK8 [1] >> "Language support for collections" is listed as a coin feature, >> I think it's an error. >> >> There is no way to store a constant array in the bytecode [2], >> If we add supports for collections literal, hitting the 64k limit will >> be easier. So this feature also require to modify the classfile format >> to store constant array as constant in the bytecode. >> As far as I remember, a coin feature can't modify the classfile format. >> >> Moreover, supporting only collection literal is in my opinion a half >> baked feature, >> we all know JSON [3] and how powerful this kind of literal syntax is. >> >> User user = { >> firstName: ''remi", >> lastName: "forax", >> addresses: [ >> { >> zipcode: "30785" >> }, { >> zipcode: "67899" >> } >> ] >> }; >> >> is better than >> >> User user = new User(); >> user.setFirstName("remi"); >> user.setLastName("forax"); >> Address addr1 = new Address(); >> addr1.setZipCode("30785"); >> Address addr2 = new Address(); >> addr2.setZipCode("67899"); >> user.setAddresses([ addr1, addr2 ]); >> >> But to support this syntax, we need to introduce properties in the >> language. >> Also note that if you have property in your language, you can write >> a decent binding API. From here, the new JavaFX API is not far :) >> >> So a JSR is a better place for this feature. >> But it seems we are short in term of new JSR :) >> In my opinion, the best is to hijack the JSR 295 [4], >> sorry I mean to reactivate JSR 295. >> >> R?mi >> >> >> [1] http://openjdk.java.net/projects/jdk7/features/#deferred >> [2] Terence Parr: Java Parsers >> http://wiki.jvmlangsummit.com/Image:Parr_Java_Parsers.pdf >> [3] http://json.org/ >> [4] JSR 295: Beans Binding >> http://jcp.org/en/jsr/detail?id=295 >> >> From jonathan.gibbons at oracle.com Fri Sep 24 09:39:49 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 24 Sep 2010 09:39:49 -0700 Subject: Is language support for collections is a coin feature ? In-Reply-To: <4C9CD52B.2080805@univ-mlv.fr> References: <4C9CB697.3030403@univ-mlv.fr> <4C9CC550.7080903@oracle.com> <4C9CD52B.2080805@univ-mlv.fr> Message-ID: <4C9CD455.7000404@oracle.com> It would seem there is room for two distinct features here: 1) language support for collection literals 2) JVM support for large arrays Logically, they are distinct, but either would be enhanced by the availability of the other. -- Jon On 09/24/2010 09:43 AM, R?mi Forax wrote: > Le 24/09/2010 17:35, Eamonn McManus a ?crit : > >> Hi, >> > Hi, > > >> Without commenting on your conclusions, I don't think your premises >> are correct. First of all, I don't think collection literals will be >> limited to constant values, so they couldn't in general be stored in >> the constant pool even if the classfile format were extended to allow >> that. >> > It depends how you design the new constant pool attribute. I can be a > tree of constants (like the annotation values) > plus some placeholders for storing values sent during the execution if > by example some local variable values > are needed. > > > >> Secondly, if the 64K limit on the size of methods is a concern, >> nothing stops the compiler from creating a private synthetic method >> that creates and returns the collection, in the same way as it used to >> create one for Foo.class literals, and even doing that recursively for >> really big literals. The situation is anyway exactly the same as for >> array literals today. >> > What you describe for a collection is applicable for an array, > but the current compiler fails if the array of literal is too big. > Splitting a method is far from obvious because you can have side effect and > the number of method parameters is limited to 255. > > This code is legal in Java: > int i =0; > int[] array = {i++, i}; > System.out.println(i); > > > >> Regards, >> >> ?amonn McManus -- http://weblogs.java.net/blog/emcmanus >> >> > regards, > R?mi > > >> On 24/9/10 4:32 PM, R?mi Forax wrote: >> >>> In the list of feature deferred to JDK8 [1] >>> "Language support for collections" is listed as a coin feature, >>> I think it's an error. >>> >>> There is no way to store a constant array in the bytecode [2], >>> If we add supports for collections literal, hitting the 64k limit will >>> be easier. So this feature also require to modify the classfile format >>> to store constant array as constant in the bytecode. >>> As far as I remember, a coin feature can't modify the classfile format. >>> >>> Moreover, supporting only collection literal is in my opinion a half >>> baked feature, >>> we all know JSON [3] and how powerful this kind of literal syntax is. >>> >>> User user = { >>> firstName: ''remi", >>> lastName: "forax", >>> addresses: [ >>> { >>> zipcode: "30785" >>> }, { >>> zipcode: "67899" >>> } >>> ] >>> }; >>> >>> is better than >>> >>> User user = new User(); >>> user.setFirstName("remi"); >>> user.setLastName("forax"); >>> Address addr1 = new Address(); >>> addr1.setZipCode("30785"); >>> Address addr2 = new Address(); >>> addr2.setZipCode("67899"); >>> user.setAddresses([ addr1, addr2 ]); >>> >>> But to support this syntax, we need to introduce properties in the >>> language. >>> Also note that if you have property in your language, you can write >>> a decent binding API. From here, the new JavaFX API is not far :) >>> >>> So a JSR is a better place for this feature. >>> But it seems we are short in term of new JSR :) >>> In my opinion, the best is to hijack the JSR 295 [4], >>> sorry I mean to reactivate JSR 295. >>> >>> R?mi >>> >>> >>> [1] http://openjdk.java.net/projects/jdk7/features/#deferred >>> [2] Terence Parr: Java Parsers >>> http://wiki.jvmlangsummit.com/Image:Parr_Java_Parsers.pdf >>> [3] http://json.org/ >>> [4] JSR 295: Beans Binding >>> http://jcp.org/en/jsr/detail?id=295 >>> >>> >>> > > From joe.darcy at oracle.com Fri Sep 24 10:45:35 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 24 Sep 2010 10:45:35 -0700 Subject: Is language support for collections is a coin feature ? In-Reply-To: <4C9CC7D4.2080006@oracle.com> References: <4C9CB697.3030403@univ-mlv.fr> <4C9CC7D4.2080006@oracle.com> Message-ID: <4C9CE3BF.6070106@oracle.com> Hello. Eamonn McManus wrote: > Hi, > > Without commenting on your conclusions, I don't think your premises are > correct. Yes, the assumptions are not necessarily valid. First, the Coin proposal for collection literals [1] desugars into a sequence of calls to new methods. No JVM change is needed; although such a design is possible of course. The lack of ability is store, say, pre-initialized arrays is a long-standing shortcoming of the class file format. However, I doubt collections literals would do much to exacerbate that problem. Cheers, -Joe [1] http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001193.html > First of all, I don't think collection literals will be limited > to constant values, so they couldn't in general be stored in the > constant pool even if the classfile format were extended to allow that. > Secondly, if the 64K limit on the size of methods is a concern, nothing > stops the compiler from creating a private synthetic method that creates > and returns the collection, in the same way as it used to create one for > Foo.class literals, and even doing that recursively for really big > literals. The situation is anyway exactly the same as for array literals > today. > > Regards, > > ?amonn McManus -- http://weblogs.java.net/blog/emcmanus > > > On 24/9/10 4:32 PM, R?mi Forax wrote: > >> In the list of feature deferred to JDK8 [1] >> "Language support for collections" is listed as a coin feature, >> I think it's an error. >> >> There is no way to store a constant array in the bytecode [2], >> If we add supports for collections literal, hitting the 64k limit will >> be easier. So this feature also require to modify the classfile format >> to store constant array as constant in the bytecode. >> As far as I remember, a coin feature can't modify the classfile format. >> >> Moreover, supporting only collection literal is in my opinion a half >> baked feature, >> we all know JSON [3] and how powerful this kind of literal syntax is. >> >> User user = { >> firstName: ''remi", >> lastName: "forax", >> addresses: [ >> { >> zipcode: "30785" >> }, { >> zipcode: "67899" >> } >> ] >> }; >> >> is better than >> >> User user = new User(); >> user.setFirstName("remi"); >> user.setLastName("forax"); >> Address addr1 = new Address(); >> addr1.setZipCode("30785"); >> Address addr2 = new Address(); >> addr2.setZipCode("67899"); >> user.setAddresses([ addr1, addr2 ]); >> >> But to support this syntax, we need to introduce properties in the language. >> Also note that if you have property in your language, you can write >> a decent binding API. From here, the new JavaFX API is not far :) >> >> So a JSR is a better place for this feature. >> But it seems we are short in term of new JSR :) >> In my opinion, the best is to hijack the JSR 295 [4], >> sorry I mean to reactivate JSR 295. >> >> R?mi >> >> >> [1] http://openjdk.java.net/projects/jdk7/features/#deferred >> [2] Terence Parr: Java Parsers >> http://wiki.jvmlangsummit.com/Image:Parr_Java_Parsers.pdf >> [3] http://json.org/ >> [4] JSR 295: Beans Binding >> http://jcp.org/en/jsr/detail?id=295 >> >> >> > > From reinier at zwitserloot.com Sat Sep 25 20:51:44 2010 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Sun, 26 Sep 2010 05:51:44 +0200 Subject: Is language support for collections is a coin feature ? In-Reply-To: <4C9CB697.3030403@univ-mlv.fr> References: <4C9CB697.3030403@univ-mlv.fr> Message-ID: Advocate of the devil mode: User user = new User() .firstName("Remi") .lastName("Forax") .addAddress().zipCode("30785").done() .address(new Address().zipCode("30785")); Note the two styles for address - you can pick either, whichever you think is nicer (don't, obviously, add both methods to the API!) As near to the cleanliness as the JSON syntax as makes no difference, and perfectly doable in java today. It does mean User and Address can't be immutable and that's a bit of a shame. Fixable though: User user = User.make() .firstName("Remi") .lastName("Forax") .addAddress().zipCode("30785").done() .address(Address.make().zipCode("30785").build()) .build(); Moving away a bit from the cleanliness, but still sufficiently nice to question the need for major language change to address this stuff. For extra zing, though this is delving a bit deep into language hackery, you can even do this, in today's java. The below works with immutables, and unlike the JSON example, supports a lot more safety features - typoing any of the keys will result in an as-you-type error, as does assigning a value of the wrong type: User user = new UserBuilder() {{ firstName = "Remi"; lastName = "Forax"; addresses.add( new AddressBuilder() {{ zipCode = "30785"; }}, new AddressBuilder() {{ zipCode = "67899"; }}); }}.build(); Sure, there's opportunity for cleanup. But I don't think it should be high priority. Especially because, even with the superfluous need for the double braces, the call to build(), and the need for an add method for 0-* 'fields': This beats the JSON example, because of all the safety measures. Now, that's API use. Writing the boilerplate to make the above code possible, _THAT_ is a right mess. It's something Roel and I are looking at generating with lombok. I got the vibe from some of the reports at JavaOne (I'm not there myself) that there's a plan to take lombok's @Data annotation and make it part of java itself. In that case, well, while you're at it... :) NB: Expanding builders to support compile-time reporting of forgetting to set required fields is possible but all approaches I can think of do not scale. If its deemed important, then the only way to get there that I can see, is to add syntax support for it. --Reinier Zwitserloot On Fri, Sep 24, 2010 at 4:32 PM, R?mi Forax wrote: > In the list of feature deferred to JDK8 [1] > "Language support for collections" is listed as a coin feature, > I think it's an error. > > There is no way to store a constant array in the bytecode [2], > If we add supports for collections literal, hitting the 64k limit will > be easier. So this feature also require to modify the classfile format > to store constant array as constant in the bytecode. > As far as I remember, a coin feature can't modify the classfile format. > > Moreover, supporting only collection literal is in my opinion a half > baked feature, > we all know JSON [3] and how powerful this kind of literal syntax is. > > User user = { > firstName: ''remi", > lastName: "forax", > addresses: [ > { > zipcode: "30785" > }, { > zipcode: "67899" > } > ] > }; > > is better than > > User user = new User(); > user.setFirstName("remi"); > user.setLastName("forax"); > Address addr1 = new Address(); > addr1.setZipCode("30785"); > Address addr2 = new Address(); > addr2.setZipCode("67899"); > user.setAddresses([ addr1, addr2 ]); > > But to support this syntax, we need to introduce properties in the > language. > Also note that if you have property in your language, you can write > a decent binding API. From here, the new JavaFX API is not far :) > > So a JSR is a better place for this feature. > But it seems we are short in term of new JSR :) > In my opinion, the best is to hijack the JSR 295 [4], > sorry I mean to reactivate JSR 295. > > R?mi > > > [1] http://openjdk.java.net/projects/jdk7/features/#deferred > [2] Terence Parr: Java Parsers > http://wiki.jvmlangsummit.com/Image:Parr_Java_Parsers.pdf > [3] http://json.org/ > [4] JSR 295: Beans Binding > http://jcp.org/en/jsr/detail?id=295 > > > From per at bothner.com Sat Sep 25 21:15:22 2010 From: per at bothner.com (Per Bothner) Date: Sat, 25 Sep 2010 21:15:22 -0700 Subject: Is language support for collections is a coin feature ? In-Reply-To: References: <4C9CB697.3030403@univ-mlv.fr> Message-ID: <4C9EC8DA.90503@bothner.com> On 09/25/2010 08:51 PM, Reinier Zwitserloot wrote: > User user = new User() > .firstName("Remi") > .lastName("Forax") > .addAddress().zipCode("30785").done() > .address(new Address().zipCode("30785")); > > Note the two styles for address - you can pick either, whichever you think > is nicer (don't, obviously, add both methods to the API!) > > As near to the cleanliness as the JSON syntax as makes no difference, and > perfectly doable in java today. It does mean User and Address can't be > immutable and that's a bit of a shame. For immutable ("value") types you can define the firstName method as one that takes a User and returns new User that has the same values, expect with a modified firstName. > User user = new UserBuilder() {{ > firstName = "Remi"; > lastName = "Forax"; > addresses.add( > new AddressBuilder() {{ > zipCode = "30785"; > }}, > new AddressBuilder() {{ > zipCode = "67899"; > }}); > }}.build(); > > Sure, there's opportunity for cleanup. But I don't think it should be high > priority. Especially because, even with the superfluous need for the double > braces, the call to build(), and the need for an add method for 0-* > 'fields': This beats the JSON example, because of all the safety measures. Creating the extra UserBuilder adds some overhead, but it can perhaps be optimized away. I think there should standard compact way to do this. Unless whether it is best to use conventions or a syntax change. Various issues tie in with it: properties; value types; block expressions. -- --Per Bothner per at bothner.com http://per.bothner.com/ From isidore at setgame.com Sat Sep 25 22:30:39 2010 From: isidore at setgame.com (Llewellyn Falco) Date: Sat, 25 Sep 2010 22:30:39 -0700 Subject: Lambda's/Closures & Extension Methods in JDK 1.6 Message-ID: Hello, I found out about project coin this week at JavaOne and thought I would like to join the discussion. I've implemented 2 features to the JDK 6 without any changes to the JDK, JavaC, Java Syntax, or Java Byte code. As such, I think they might be of interest to Project Coin. Those 2 features are: Lambdas Extension Methods You can read about them, see videos, and even download and start using them here: Lambda : http://bit.ly/lambdas Extension Methods : http://bit.ly/ExtensionMethods I look forward to your thoughts. Llewellyn Falco @isidore_us From Ulf.Zibis at gmx.de Sun Sep 26 05:39:03 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 26 Sep 2010 14:39:03 +0200 Subject: Is language support for collections is a coin feature ? In-Reply-To: References: <4C9CB697.3030403@univ-mlv.fr> Message-ID: <4C9F3EE7.80601@gmx.de> Am 26.09.2010 05:51, schrieb Reinier Zwitserloot: > Advocate of the devil mode: > > User user = new User() > .firstName("Remi") > .lastName("Forax") > .addAddress().zipCode("30785").done() > .address(new Address().zipCode("30785")); See also: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6479372 > User user = new UserBuilder() {{ > firstName = "Remi"; > lastName = "Forax"; > addresses.add( > new AddressBuilder() {{ > zipCode = "30785"; > }}, > new AddressBuilder() {{ > zipCode = "67899"; > }}); > }}.build(); > Why not? : User user = new UserBuilder() {{ firstName = "Remi"; lastName = "Forax"; addresses = new Address[] { new AddressBuilder() {{ zipCode = "30785"; }}, new AddressBuilder() {{ zipCode = "67899"; }} }; }}.build(); -Ulf From kevin at lckymn.com Mon Sep 27 11:42:43 2010 From: kevin at lckymn.com (Kevin Lee) Date: Tue, 28 Sep 2010 04:42:43 +1000 Subject: Is language support for collections is a coin feature ? In-Reply-To: References: Message-ID: > Why not? : > > User user = new UserBuilder() {{ > firstName = "Remi"; > lastName = "Forax"; > addresses = new Address[] { > new AddressBuilder() {{ > zipCode = "30785"; > }}, > new AddressBuilder() {{ > zipCode = "67899"; > }} > }; > }}.build(); You're adding AddressBuilder objects to an Address array. If Reinier didn't make any mistake the code probably be like User user = new User.UserBuilder() {{ firstName = "Kevin"; lastName = "Lee"; addresses.add(new AddressBuilder(){{ zipCode = "12345"; }}, new AddressBuilder(){{ zipCode = "111111"; }}); }}.build(); It probably has AddressesBuilder to build a list of Address objects. public class AddressesBuilder implements GenericBuilder> { private List
addressList = new ArrayList
(); public void add(AddressBuilder... addressBuilders) { for (AddressBuilder addressBuilder : addressBuilders) addressList.add(addressBuilder.build()); } @Override public List
build() { return Collections.unmodifiableList(addressList); } } public class User { private final String firstName; private final String lastName; private final List
addresses; public static class UserBuilder implements GenericBuilder { public String firstName; public String lastName; public AddressesBuilder addresses = new AddressesBuilder(); @Override public User build() { return new User(this); } } private User(UserBuilder builder) { this.firstName = builder.firstName; this.lastName = builder.lastName; this.addresses = builder.addresses.build(); } // getters are omitted. } I think it can be just like User user = new User.UserBuilder() {{ firstName = "Kevin"; lastName = "Lee"; addresses(new AddressBuilder(){{ zipCode = "12345"; }}, new AddressBuilder(){{ zipCode = "111111"; }}); }}.build(); if UserBuilder is changed to public static class UserBuilder implements GenericBuilder { public String firstName; public String lastName; private List
addresses = new ArrayList
(); public void *addresses*(AddressBuilder... addressBuilders) { for (AddressBuilder addressBuilder : addressBuilders) addresses.add(addressBuilder.build()); } @Override public User build() { return new User(this); } } and the constructor of User would be private User(UserBuilder builder) { this.firstName = builder.firstName; this.lastName = builder.lastName; this.addresses = Collections.unmodifiableList(builder.addresses); } Then it doesn't need an additional builder that is Address*es*Builder. Or it can just use the Arrays.asList() method. User user = new User.UserBuilder() {{ firstName = "Kevin"; lastName = "Lee"; addresses = Arrays.asList(new AddressBuilder(){{ zipCode = "12345"; }}.build(), new AddressBuilder(){{ zipCode = "111111"; }}.build()); }}.build(); and UserBuilder would be simpler public static class UserBuilder implements GenericBuilder { public String firstName; public String lastName; public List
addresses; @Override public User build() { return new User(this); } } Anyway, although that would be a good way to create an (immutable) object especially because Java does not have Named Parameter ( http://en.wikipedia.org/wiki/Named_parameter), I prefer using Builder Pattern to using double brace initialisation (using Instance Initializer) as this creates a new class per each use. I don't know why the matter of collections literals has become a matter of properties nor am I sure if introducing properties is a good idea, because I like to use a method with a meaningful name. For instance, if I want to cut down the price of a product, I don't want to do like product.price - 10; but product.cutDownPrice(10); It's probably just me who doesn't like properties but I'm a flip-flopper so I would perhaps one day like it. :) So will 'Language support for collections' be included in JDK8 or not? By the way, is there any possibility that a future Java will have Named Parameter? On 26/09/10 22:39, Ulf Zibis wrote: > > Am 26.09.2010 05:51, schrieb Reinier Zwitserloot: > > Advocate of the devil mode: > > > > User user = new User() > > .firstName("Remi") > > .lastName("Forax") > > .addAddress().zipCode("30785").done() > > .address(new Address().zipCode("30785")); > > See also: > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6479372 > > > User user = new UserBuilder() {{ > > firstName = "Remi"; > > lastName = "Forax"; > > addresses.add( > > new AddressBuilder() {{ > > zipCode = "30785"; > > }}, > > new AddressBuilder() {{ > > zipCode = "67899"; > > }}); > > }}.build(); > > > > Why not? : > > User user = new UserBuilder() {{ > firstName = "Remi"; > lastName = "Forax"; > addresses = new Address[] { > new AddressBuilder() {{ > zipCode = "30785"; > }}, > new AddressBuilder() {{ > zipCode = "67899"; > }} > }; > }}.build(); > > > -Ulf > From weijun.wang at oracle.com Tue Sep 28 05:08:03 2010 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 28 Sep 2010 20:08:03 +0800 Subject: Why the diamond operator does not work here? Message-ID: <4CA1DAA3.3060407@oracle.com> Compiling this program 1 import java.util.*; 2 3 class A3 { 4 public static void main(String[] args) { 5 Map> map = new HashMap<>(); 6 map.put("x", new ArrayList<>()); // compile error! 7 } 8 } results in A3.java:6: method put in interface Map cannot be applied to given types map.put("x", new ArrayList<>()); ^ required: String,List found: String,ArrayList where K,V are type-variables: K extends Object declared in interface Map V extends Object declared in interface Map 1 error Thanks Max From Ulf.Zibis at gmx.de Tue Sep 28 09:23:03 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 28 Sep 2010 18:23:03 +0200 Subject: Why the diamond operator does not work here? In-Reply-To: <4CA1DAA3.3060407@oracle.com> References: <4CA1DAA3.3060407@oracle.com> Message-ID: <4CA21667.5090006@gmx.de> Try something like (not sure if it would work): 5 Map> map = new HashMap<>(); -Ulf Am 28.09.2010 14:08, schrieb Weijun Wang: > Compiling this program > > 1 import java.util.*; > 2 > 3 class A3 { > 4 public static void main(String[] args) { > 5 Map> map = new HashMap<>(); > 6 map.put("x", new ArrayList<>()); // compile error! > 7 } > 8 } > > results in > > A3.java:6: method put in interface Map cannot be applied to given types > map.put("x", new ArrayList<>()); > ^ > required: String,List > found: String,ArrayList > where K,V are type-variables: > K extends Object declared in interface Map > V extends Object declared in interface Map > 1 error > > Thanks > Max > > From forax at univ-mlv.fr Tue Sep 28 11:09:23 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 28 Sep 2010 20:09:23 +0200 Subject: Why the diamond operator does not work here? In-Reply-To: <4CA21667.5090006@gmx.de> References: <4CA1DAA3.3060407@oracle.com> <4CA21667.5090006@gmx.de> Message-ID: <4CA22F53.9090103@univ-mlv.fr> Le 28/09/2010 18:23, Ulf Zibis a ?crit : > Try something like (not sure if it would work): > > 5 Map> map = new HashMap<>(); > > -Ulf > See slides 99+ from the presentation of Joe and Maurizio http://blogs.sun.com/darcy/resource/JavaOne/J1_2010-ProjectCoin.pdf R?mi From brian.goetz at oracle.com Tue Sep 28 11:55:40 2010 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 28 Sep 2010 14:55:40 -0400 Subject: Lambda's/Closures & Extension Methods in JDK 1.6 In-Reply-To: References: Message-ID: <4CA23A2C.6020105@oracle.com> > I've implemented 2 features to the JDK 6 without any changes to the JDK, > JavaC, Java Syntax, or Java Byte code. As such, I think they might be of > interest to Project Coin. > > Those 2 features are: > Lambdas > Extension Methods We considered, and explicitly rejected, implementing extension methods with a compiler-only strategy because it can cause all sorts of "brittle class" problems. From reinier at zwitserloot.com Tue Sep 28 14:55:25 2010 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Tue, 28 Sep 2010 23:55:25 +0200 Subject: Is language support for collections is a coin feature ? In-Reply-To: <4C9F3EE7.80601@gmx.de> References: <4C9CB697.3030403@univ-mlv.fr> <4C9F3EE7.80601@gmx.de> Message-ID: Because arrays are obsolete. Also, in the example I showed, you're actually giving an AddressBuilder to .add(), not an Address. With methods, you could accept either. This trick doesn't work so well with arrays. Same story if generics are involved. --Reinier Zwitserloot On Sun, Sep 26, 2010 at 2:39 PM, Ulf Zibis wrote: > Am 26.09.2010 05:51, schrieb Reinier Zwitserloot: > > Advocate of the devil mode: >> >> User user = new User() >> .firstName("Remi") >> .lastName("Forax") >> .addAddress().zipCode("30785").done() >> .address(new Address().zipCode("30785")); >> > > See also: > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6479372 > > > User user = new UserBuilder() {{ >> firstName = "Remi"; >> lastName = "Forax"; >> addresses.add( >> new AddressBuilder() {{ >> zipCode = "30785"; >> }}, >> new AddressBuilder() {{ >> zipCode = "67899"; >> }}); >> }}.build(); >> >> > Why not? : > > > User user = new UserBuilder() {{ > firstName = "Remi"; > lastName = "Forax"; > addresses = new Address[] { > > new AddressBuilder() {{ > zipCode = "30785"; > }}, > new AddressBuilder() {{ > zipCode = "67899"; > }} > }; > }}.build(); > > > -Ulf > > From isidore at setgame.com Wed Sep 29 00:36:56 2010 From: isidore at setgame.com (Llewellyn Falco) Date: Wed, 29 Sep 2010 00:36:56 -0700 Subject: Lambda's/Closures & Extension Methods in JDK 1.6 In-Reply-To: <4CA23A2C.6020105@oracle.com> References: <4CA23A2C.6020105@oracle.com> Message-ID: On Tue, Sep 28, 2010 at 11:55 AM, Brian Goetz wrote: > I've implemented 2 features to the JDK 6 without any changes to the JDK, >> JavaC, Java Syntax, or Java Byte code. As such, I think they might be of >> interest to Project Coin. >> >> Those 2 features are: >> Lambdas >> Extension Methods >> > > We considered, and explicitly rejected, implementing extension methods with > a compiler-only strategy because it can cause all sorts of "brittle class" > problems. > As I mentioned, I'm currently using them without even changing the compiler. They work well, but I find the syntax a bit cumbersome. I haven't found any brittle class issues. I should mention that the syntax was cumbersome enough that I didn't use them for about a year, until I started using lambdas. Now they have become more essential. Did you try out the solution? Llewellyn From Ulf.Zibis at gmx.de Wed Sep 29 04:02:37 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 29 Sep 2010 13:02:37 +0200 Subject: Is language support for collections is a coin feature ? In-Reply-To: References: <4C9CB697.3030403@univ-mlv.fr> <4C9F3EE7.80601@gmx.de> Message-ID: <4CA31CCD.6060909@gmx.de> My intention was to focus on consistent syntax: Either use "=" or method invocations consistently. -Ulf Am 28.09.2010 23:55, schrieb Reinier Zwitserloot: > Because arrays are obsolete. Also, in the example I showed, you're actually giving an > AddressBuilder to .add(), not an Address. With methods, you could accept either. This trick > doesn't work so well with arrays. Same story if generics are involved. > > --Reinier Zwitserloot > > > > On Sun, Sep 26, 2010 at 2:39 PM, Ulf Zibis > wrote: > > Am 26.09.2010 05:51, schrieb Reinier Zwitserloot: > > Advocate of the devil mode: > > User user = new User() > .firstName("Remi") > .lastName("Forax") > .addAddress().zipCode("30785").done() > .address(new Address().zipCode("30785")); > > > See also: > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6479372 > > > User user = new UserBuilder() {{ > firstName = "Remi"; > lastName = "Forax"; > addresses.add( > new AddressBuilder() {{ > zipCode = "30785"; > }}, > new AddressBuilder() {{ > zipCode = "67899"; > }}); > }}.build(); > > > Why not? : > > > User user = new UserBuilder() {{ > firstName = "Remi"; > lastName = "Forax"; > addresses = new Address[] { > > new AddressBuilder() {{ > zipCode = "30785"; > }}, > new AddressBuilder() {{ > zipCode = "67899"; > }} > }; > }}.build(); > > > -Ulf > > From reinier at zwitserloot.com Wed Sep 29 07:57:52 2010 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Wed, 29 Sep 2010 16:57:52 +0200 Subject: Is language support for collections is a coin feature ? In-Reply-To: <4CA31CCD.6060909@gmx.de> References: <4C9CB697.3030403@univ-mlv.fr> <4C9F3EE7.80601@gmx.de> <4CA31CCD.6060909@gmx.de> Message-ID: Sure, consistency is important. I didn't post these examples as a bid for 'this is to be the definitive syntax', just trying to show that within the confines of the current syntax rules, there are plenty of options. What's needed is a keyword or some other facility to quickly _produce_ the builders that are required to make it all work. The annotations system can more or less do this (the builders are new source files), though some standardization or at least shipping it with java itself wouldn't go amiss. These are much simpler options than changing the syntax itself. --Reinier Zwitserloot On Wed, Sep 29, 2010 at 1:02 PM, Ulf Zibis wrote: > My intention was to focus on consistent syntax: > > Either use "=" or method invocations consistently. > > -Ulf > > > > Am 28.09.2010 23:55, schrieb Reinier Zwitserloot: > > Because arrays are obsolete. Also, in the example I showed, you're actually > giving an AddressBuilder to .add(), not an Address. With methods, you could > accept either. This trick doesn't work so well with arrays. Same story if > generics are involved. > > --Reinier Zwitserloot > > > > On Sun, Sep 26, 2010 at 2:39 PM, Ulf Zibis wrote: > >> Am 26.09.2010 05:51, schrieb Reinier Zwitserloot: >> >> Advocate of the devil mode: >>> >>> User user = new User() >>> .firstName("Remi") >>> .lastName("Forax") >>> .addAddress().zipCode("30785").done() >>> .address(new Address().zipCode("30785")); >>> >> >> See also: >> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6479372 >> >> >> User user = new UserBuilder() {{ >>> firstName = "Remi"; >>> lastName = "Forax"; >>> addresses.add( >>> new AddressBuilder() {{ >>> zipCode = "30785"; >>> }}, >>> new AddressBuilder() {{ >>> zipCode = "67899"; >>> }}); >>> }}.build(); >>> >>> >> Why not? : >> >> >> User user = new UserBuilder() {{ >> firstName = "Remi"; >> lastName = "Forax"; >> addresses = new Address[] { >> >> new AddressBuilder() {{ >> zipCode = "30785"; >> }}, >> new AddressBuilder() {{ >> zipCode = "67899"; >> }} >> }; >> }}.build(); >> >> >> -Ulf >> >> > From brian.goetz at oracle.com Wed Sep 29 08:53:40 2010 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 29 Sep 2010 11:53:40 -0400 Subject: Lambda's/Closures & Extension Methods in JDK 1.6 In-Reply-To: References: <4CA23A2C.6020105@oracle.com> Message-ID: <4CA36104.4010308@oracle.com> > As I mentioned, I'm currently using them without even changing the compiler. > They work well, but I find the syntax a bit cumbersome. I haven't found any > brittle class issues. I should mention that the syntax was cumbersome enough > that I didn't use them for about a year, until I started using lambdas. Now > they have become more essential. > > Did you try out the solution? A compiler-only solution fails on the following case: interface Foo { public extension void foo() default X.a(); } interface Bar extends Foo { } class C implements Bar { } // Compile the above classes, then recompile Bar with: interface Bar extends Foo { public extension void foo() default X.b(); } // Re-run your program. Now behavior of C is wrong; you call the wrong default when C.foo() is called. From isidore at setgame.com Wed Sep 29 09:26:09 2010 From: isidore at setgame.com (Llewellyn Falco) Date: Wed, 29 Sep 2010 09:26:09 -0700 Subject: Lambda's/Closures & Extension Methods in JDK 1.6 In-Reply-To: <4CA36104.4010308@oracle.com> References: <4CA23A2C.6020105@oracle.com> <4CA36104.4010308@oracle.com> Message-ID: I don't think we are talking about different things. I'm not talking about a compiler based solution. I'm refereeing to my own object based solution. you can see it here: Extension Methods : http://bit.ly/ExtensionMethods the syntax looks like "abcde".use(StringUtils.class).removeVowels() On Wed, Sep 29, 2010 at 8:53 AM, Brian Goetz wrote: > As I mentioned, I'm currently using them without even changing the >> compiler. >> They work well, but I find the syntax a bit cumbersome. I haven't found >> any >> brittle class issues. I should mention that the syntax was cumbersome >> enough >> that I didn't use them for about a year, until I started using lambdas. >> Now >> they have become more essential. >> >> Did you try out the solution? >> > > A compiler-only solution fails on the following case: > > interface Foo { > public extension void foo() default X.a(); > } > > interface Bar extends Foo { > } > > class C implements Bar { } > > // Compile the above classes, then recompile Bar with: > > interface Bar extends Foo { > public extension void foo() default X.b(); > } > > // Re-run your program. Now behavior of C is wrong; you call the wrong > default when C.foo() is called. > > From brian.goetz at oracle.com Wed Sep 29 09:46:25 2010 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 29 Sep 2010 12:46:25 -0400 Subject: Lambda's/Closures & Extension Methods in JDK 1.6 In-Reply-To: References: <4CA23A2C.6020105@oracle.com> <4CA36104.4010308@oracle.com> Message-ID: <4CA36D61.80309@oracle.com> You should look at the work going on in Lambda surrounding "Virtual Extension Methods" as well as the work going on in JSR-292 on "interface injection." On 9/29/2010 12:26 PM, Llewellyn Falco wrote: > I don't think we are talking about different things. > I'm not talking about a compiler based solution. > I'm refereeing to my own object based solution. > you can see it here: > Extension Methods : http://bit.ly/ExtensionMethods > > the syntax looks like > "abcde".use(StringUtils.class).removeVowels() > > > > On Wed, Sep 29, 2010 at 8:53 AM, Brian Goetz > wrote: > > As I mentioned, I'm currently using them without even changing the > compiler. > They work well, but I find the syntax a bit cumbersome. I haven't > found any > brittle class issues. I should mention that the syntax was cumbersome > enough > that I didn't use them for about a year, until I started using > lambdas. Now > they have become more essential. > > Did you try out the solution? > > > A compiler-only solution fails on the following case: > > interface Foo { > public extension void foo() default X.a(); > } > > interface Bar extends Foo { > } > > class C implements Bar { } > > // Compile the above classes, then recompile Bar with: > > interface Bar extends Foo { > public extension void foo() default X.b(); > } > > // Re-run your program. Now behavior of C is wrong; you call the wrong > default when C.foo() is called. > > From pbenedict at apache.org Wed Sep 29 18:44:03 2010 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 29 Sep 2010 20:44:03 -0500 Subject: Hmm... Suppressed Exceptions are Throwables[] Message-ID: I just happened to notice the incongruity of having getSuppressedExceptions() not being Exception instances -- but Throwables. The return type is correct but the method name is slightly misleading. Can I recommend another option? Since Throwable already has a notion of a "root cause," turning "suppressed exceptions" into "ancillary" or "secondary" causes would be a better inline with current documentation. Throwable[] causes = t.getSecondaryCauses(); Paul From David.Holmes at oracle.com Thu Sep 30 00:51:18 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 30 Sep 2010 17:51:18 +1000 Subject: Hmm... Suppressed Exceptions are Throwables[] In-Reply-To: References: Message-ID: <4CA44176.30600@oracle.com> Paul, Paul Benedict said the following on 09/30/10 11:44: > I just happened to notice the incongruity of having > getSuppressedExceptions() not being Exception instances -- but > Throwables. The return type is correct but the method name is slightly > misleading. If not for Java naming style it would be "exceptions" with a small 'e' which always means any kind of exception instance ie anything that is an instanceof Throwable. > has a notion of a "root cause," turning "suppressed exceptions" into > "ancillary" or "secondary" causes would be a better inline with > current documentation. > > Throwable[] causes = t.getSecondaryCauses(); But the suppressed exception is NOT a cause of the exception being thrown! Cheers, David Holmes From pbenedict at apache.org Thu Sep 30 06:22:12 2010 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 30 Sep 2010 08:22:12 -0500 Subject: Hmm... Suppressed Exceptions are Throwables[] In-Reply-To: <4CA44176.30600@oracle.com> References: <4CA44176.30600@oracle.com> Message-ID: > If not for Java naming style it would be "exceptions" with a small 'e' which always means any kind of exception instance ie anything that is an instanceof Throwable. I totally disagree. I read the javadoc of Throwable at least twice before composing my first email. The documentation goes out of its way to avoid using the word "exception" and talk strictly about "throwable" objects. This getSuppressedExceptions() method is simply out of place in the class' documentation. Can you think of some other alternative names? > But the suppressed exception is NOT a cause of the exception being thrown! Well, of course. That would be the initial cause. But you can talk about ancillary causes ... secondary effects. Paul From scolebourne at joda.org Thu Sep 30 08:38:47 2010 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 30 Sep 2010 08:38:47 -0700 Subject: Hmm... Suppressed Exceptions are Throwables[] In-Reply-To: References: Message-ID: Personally, I agree with the reasoning here. getSecondaryThrowables() or getSecondaryCauses() would work for me. Stephen On 29 September 2010 18:44, Paul Benedict wrote: > I just happened to notice the incongruity of having > getSuppressedExceptions() not being Exception instances -- but > Throwables. The return type is correct but the method name is slightly > misleading. Can I recommend another option? Since Throwable already > has a notion of a "root cause," turning "suppressed exceptions" into > "ancillary" or "secondary" causes would be a better inline with > current documentation. > > Throwable[] causes = t.getSecondaryCauses(); > > Paul > > From mclark at apache.org Thu Sep 30 10:12:20 2010 From: mclark at apache.org (Mike Clark) Date: Thu, 30 Sep 2010 11:12:20 -0600 Subject: Hmm... Suppressed Exceptions are Throwables[] In-Reply-To: References: Message-ID: Re: "cause" instead of "suppressed" To me it is fairly obvious that suppressed exceptions are not causes, secondary or otherwise. Thus I would vote against any use of the term "cause" in relationship to suppressed exceptions. Re: "Exception" vs "Throwable": The Java exception class hierarchy and naming?has always been ever so slightly awkward.? In conversation, when I talk about exceptions in a _general_ sense, I mean anything that can be thrown.? Thus when I speak of Java exceptions in the general sense, I am usually talking about Throwable and its subclasses. This follows with the Java Language Specification where you will find the specification of?java.lang.Throwable under the prominent chapter title "Exceptions." So, you might say that while java.lang.Exception is subordinate to java.lang.Throwable, java.lang.Throwable is itself subordinate to the Java language feature "exceptions." And so it could be argued that the "Exceptions" term in "getSuppressedExceptions" actually refers to the exceptions language feature, not java.lang.Exception. I am also familiar with (and myself use, where appropriate) the convention of keeping a method's name in sync with the type name of its return value. Under this convention, the method would be better named "getSuppressedThrowables." However, I think the current naming ("getSuppressedExceptions") is understandable and justifiable under the perspective of "exceptions are a language feature" (e.g. JLS.) So for me, I'm happy either way. my 2 cents, Mike From opinali at gmail.com Thu Sep 30 10:50:21 2010 From: opinali at gmail.com (Osvaldo Pinali Doederlein) Date: Thu, 30 Sep 2010 14:50:21 -0300 Subject: Hmm... Suppressed Exceptions are Throwables[] In-Reply-To: References: Message-ID: <4CA4CDDD.5050701@gmail.com> My $0.02: getSupressed(). - It's sufficiently clear (from both the context of the containing class and the return static type), so this is terse without being obscure; - There is a BIG precedent: we already have getCause(), not getCauseException() or getCauseThrowable(). A+ Osvaldo On 30/09/2010 14:12, Mike Clark wrote: > Re: "cause" instead of "suppressed" > To me it is fairly obvious that suppressed exceptions are not causes, > secondary or otherwise. Thus I would vote against any use of the term > "cause" in relationship to suppressed exceptions. > > Re: "Exception" vs "Throwable": > The Java exception class hierarchy and naming has always been ever so > slightly awkward. In conversation, when I talk about exceptions in a > _general_ sense, I mean anything that can be thrown. Thus when I > speak of Java exceptions in the general sense, I am usually talking > about Throwable and its subclasses. > > This follows with the Java Language Specification where you will find > the specification of java.lang.Throwable under the prominent chapter > title "Exceptions." So, you might say that while java.lang.Exception > is subordinate to java.lang.Throwable, java.lang.Throwable is itself > subordinate to the Java language feature "exceptions." And so it > could be argued that the "Exceptions" term in > "getSuppressedExceptions" actually refers to the exceptions language > feature, not java.lang.Exception. > > I am also familiar with (and myself use, where appropriate) the > convention of keeping a method's name in sync with the type name of > its return value. Under this convention, the method would be better > named "getSuppressedThrowables." > > However, I think the current naming ("getSuppressedExceptions") is > understandable and justifiable under the perspective of "exceptions > are a language feature" (e.g. JLS.) > > So for me, I'm happy either way. > > my 2 cents, > > Mike > From joe.darcy at oracle.com Thu Sep 30 21:31:28 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 30 Sep 2010 21:31:28 -0700 Subject: Hmm... Suppressed Exceptions are Throwables[] In-Reply-To: <4CA4CDDD.5050701@gmail.com> References: <4CA4CDDD.5050701@gmail.com> Message-ID: <4CA56420.7090203@oracle.com> Osvaldo Pinali Doederlein wrote: > My $0.02: getSupressed(). > Hopefully the method name would not be misinterpreted as a command! > - It's sufficiently clear (from both the context of the containing class > and the return static type), so this is terse without being obscure; > - There is a BIG precedent: we already have getCause(), not > getCauseException() or getCauseThrowable(). > Good point; I'll consider this renaming. Thanks, -Joe > A+ > Osvaldo > > On 30/09/2010 14:12, Mike Clark wrote: > >> Re: "cause" instead of "suppressed" >> To me it is fairly obvious that suppressed exceptions are not causes, >> secondary or otherwise. Thus I would vote against any use of the term >> "cause" in relationship to suppressed exceptions. >> >> Re: "Exception" vs "Throwable": >> The Java exception class hierarchy and naming has always been ever so >> slightly awkward. In conversation, when I talk about exceptions in a >> _general_ sense, I mean anything that can be thrown. Thus when I >> speak of Java exceptions in the general sense, I am usually talking >> about Throwable and its subclasses. >> >> This follows with the Java Language Specification where you will find >> the specification of java.lang.Throwable under the prominent chapter >> title "Exceptions." So, you might say that while java.lang.Exception >> is subordinate to java.lang.Throwable, java.lang.Throwable is itself >> subordinate to the Java language feature "exceptions." And so it >> could be argued that the "Exceptions" term in >> "getSuppressedExceptions" actually refers to the exceptions language >> feature, not java.lang.Exception. >> >> I am also familiar with (and myself use, where appropriate) the >> convention of keeping a method's name in sync with the type name of >> its return value. Under this convention, the method would be better >> named "getSuppressedThrowables." >> >> However, I think the current naming ("getSuppressedExceptions") is >> understandable and justifiable under the perspective of "exceptions >> are a language feature" (e.g. JLS.) >> >> So for me, I'm happy either way. >> >> my 2 cents, >> >> Mike >> >> > > >