From jason_mehrens at hotmail.com Tue Dec 7 09:46:20 2010 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 7 Dec 2010 11:46:20 -0600 Subject: Suppressed exceptions with catch and rethrow Message-ID: Hello coin-dev, As a best practice, can/should the suppressed exceptions be used when cleaning up resources in a catch and rethrow? Using the FileChannelImpl changes at http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/c164d0d59465 as an example. Should 'ignore' be added as a suppressed exception to 'e'? Thanks, Jason From joe.darcy at oracle.com Thu Dec 9 09:22:07 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 09 Dec 2010 09:22:07 -0800 Subject: Suppressed exceptions with catch and rethrow In-Reply-To: References: Message-ID: <4D01103F.2080301@oracle.com> On 12/7/2010 9:46 AM, Jason Mehrens wrote: > Hello coin-dev, > > As a best practice, can/should the suppressed exceptions be used when cleaning up resources in a catch and rethrow? Using the FileChannelImpl changes at http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/c164d0d59465 as an example. Should 'ignore' be added as a suppressed exception to 'e'? > > Thanks, > > Jason > Hello. Yes, we're evaluating several uses of suppressed exceptions for situations like this. Thanks for the suggestion, -Joe From angelarifb at gmail.com Mon Dec 13 11:26:34 2010 From: angelarifb at gmail.com (Eugene Zola) Date: Mon, 13 Dec 2010 21:26:34 +0200 Subject: Post positive reviews Message-ID: Google?s Huge Change and How it affects you. ? Anyone can now post bad reviews and kill your rank. ? We post good reviews and improve your rank. ? We post good reviews to keep others from killing your rank. Google: Judge, Jury and Online Shopping Executioner Google rank is based on reviews of your business? Google Statement: "...in the last few days we developed an algorithmic solution which detects the merchant from the Times article along with hundreds of other merchants that, in our opinion, provide an extremely poor user experience. The algorithm we incorporated into our search rankings represents an initial solution to this issue, and Google users are now getting a better experience as a result." This means that anyone can write bad reviews about your business and lower your ranking. We knew that getting good reviews and not getting bad reviews was always important. Now it is a must to have good reviews for your business to keep the rank safe or to improve rank with Google. We post positive reviews for your company. We have the experience and ability to post hundreds of positive reviews that are all unique content and posted on unique IP addresses. Visit www.postpositivereviews.com for more information. From joe.darcy at oracle.com Mon Dec 13 15:17:08 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 13 Dec 2010 15:17:08 -0800 Subject: Safe Varargs Message-ID: <4D06A974.6090003@oracle.com> Greetings. Following up on earlier work, the javac team has pushed a new implementation of Project Coin's simplified varargs method invocation feature. [1] The changes are scheduled to appear in the promotion of JDK 7 b123. As envisioned previously, a new @Documented annotation type, java.lang.SafeVararags, can be used to suppress warnings related to unchecked warnings, both the new mandatory warnings at the declaration site of a varargs method/constructor with a non-reifiable element type and the existing unchecked warnings at the call sites of such methods. A systematic application of this annotation to appropriate declarations in the JDK libraries will follow as future work. Since new unchecked warnings are being introduced, those diligently compiling with options like "-Xlint:unchecked -Werror" will see a build error under JDK 7 if any of the suspicious varargs method declarations are found. To address this, the @SafeVarargs annotation can be applied to the declarations, if appropriate, or the @SuppressWarnings({"unchecked", "varargs"}) annotation can be applied. Unlike @SafeVarargs, the @SuppressWarnings annotation will not squelch unchecked warnings at the call site of the annotated method. The specification of the new SafeVarargs annotation type is below. -Joe [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/78885e69c42c http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7b99f98b3035 -=-=-=-=-=-=- Annotation Type SafeVarargs @Documented @Retention(value=RUNTIME) @Target(value={CONSTRUCTOR,METHOD}) public @interface SafeVarargs A programmer assertion that the body of the annotated method or constructor does not perform potentially unsafe operations on its varargs parameter. Applying this annotation to a method or constructor suppresses unchecked warnings about a non-reifiable variable-arity (vararg) type and suppresses unchecked warnings about parameterized array creation at call sites. In addition to the usage restrictions imposed by its @Target meta-annotation, compilers are required to implement additional usage restrictions on this annotation type; it is a compile-time error if a method or constructor declaration is annotated with a @SafeVarargs annotation, and either: * the declaration is a fixed-arity method or constructor * the declaration is a variable-arity method that is neither static nor final. Compilers are encouraged to issue warnings when this annotation type is applied to a method or constructor declaration where: * The variable-arity parameter has a reifiable element type, which includes primitive types, Object, and String. (The unchecked warnings this annotation type suppresses already do not occur for a reifiable element type.) * The body of the method or constructor declaration performs potentially unsafe operations, such as an assignment to an element of the variable-arity parameter's array that generates an unchecked warning. Future versions of the platform may mandate compiler errors for such unsafe operations. From neal at gafter.com Mon Dec 13 20:30:13 2010 From: neal at gafter.com (Neal Gafter) Date: Mon, 13 Dec 2010 20:30:13 -0800 Subject: Safe Varargs In-Reply-To: <4D06A974.6090003@oracle.com> References: <4D06A974.6090003@oracle.com> Message-ID: This documentation uses the phrase "potentially unsafe operations" without defining it. Presumably such unsafe operations include an assignment to a variable of the same type (i.e. allowing the varargs parameter to escape). On Monday, December 13, 2010, Joe Darcy wrote: > Greetings. > > Following up on earlier work, the javac team has pushed a new > implementation of Project Coin's simplified varargs method invocation > feature. [1] The changes are scheduled to appear in the promotion of JDK > 7 b123. > > As envisioned previously, a new @Documented annotation type, > java.lang.SafeVararags, can be used to suppress warnings related to > unchecked warnings, both the new mandatory warnings at the declaration > site of a varargs method/constructor with a non-reifiable element type > and the existing unchecked warnings at the call sites of such methods. A > systematic application of this annotation to appropriate declarations in > the JDK libraries will follow as future work. > > Since new unchecked warnings are being introduced, those diligently > compiling with options like "-Xlint:unchecked -Werror" will see a build > error under JDK 7 if any of the suspicious varargs method declarations > are found. To address this, the @SafeVarargs annotation can be applied > to the declarations, if appropriate, or the > @SuppressWarnings({"unchecked", "varargs"}) annotation can be applied. > Unlike @SafeVarargs, the @SuppressWarnings annotation will not squelch > unchecked warnings at the call site of the annotated method. > > The specification of the new SafeVarargs annotation type is below. > > -Joe > > [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/78885e69c42c > http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7b99f98b3035 > > -=-=-=-=-=-=- > > Annotation Type SafeVarargs > > ? ?@Documented > ? ?@Retention(value=RUNTIME) > ? ?@Target(value={CONSTRUCTOR,METHOD}) > ? ?public @interface SafeVarargs > > A programmer assertion that the body of the annotated method or > constructor does not perform potentially unsafe operations on its > varargs parameter. Applying this annotation to a method or constructor > suppresses unchecked warnings about a non-reifiable variable-arity > (vararg) type and suppresses unchecked warnings about parameterized > array creation at call sites. > > In addition to the usage restrictions imposed by its @Target > meta-annotation, compilers are required to implement additional usage > restrictions on this annotation type; it is a compile-time error if a > method or constructor declaration is annotated with a @SafeVarargs > annotation, and either: > > ? ? ? ?* the declaration is a fixed-arity method or constructor > ? ? ? ?* the declaration is a variable-arity method that is neither > static nor final. > > Compilers are encouraged to issue warnings when this annotation type is > applied to a method or constructor declaration where: > > ? ? ? ?* The variable-arity parameter has a reifiable element type, > which includes primitive types, Object, and String. (The unchecked > warnings this annotation type suppresses already do not occur for a > reifiable element type.) > ? ? ? ?* The body of the method or constructor declaration performs > potentially unsafe operations, such as an assignment to an element of > the variable-arity parameter's array that generates an unchecked warning. > > ? ? ? ? ?Future versions of the platform may mandate compiler errors > for such unsafe operations. > > > > From joe.darcy at oracle.com Tue Dec 14 18:45:52 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 14 Dec 2010 18:45:52 -0800 Subject: FYI, "Updating JDK libraries to use Project Coin features" Message-ID: <4D082BE0.3080500@oracle.com> Hello. FYI, we'll soon start a process to systematically update the JDK libraries to use Project Coin features: http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-December/001727.html -Joe From Ulf.Zibis at gmx.de Thu Dec 16 05:15:50 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 16 Dec 2010 14:15:50 +0100 Subject: coin features in JDK-7 or JDK-8 ? In-Reply-To: <4D095C40.4030100@oracle.com> References: <4D095C40.4030100@oracle.com> Message-ID: <4D0A1106.9000508@gmx.de> Hi all, in the recent issue of the German "Java Spektrum" I read, that the project coin features are scheduled for JDK-8 2012 (Plan B). (Jigsaw and Lambda too) Now I'm wondering, as the coin features are already in the JDK-7 codebase. Can someone clarify ? -Ulf From brian.goetz at oracle.com Thu Dec 16 05:27:18 2010 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 16 Dec 2010 14:27:18 +0100 Subject: coin features in JDK-7 or JDK-8 ? In-Reply-To: <4D0A1106.9000508@gmx.de> References: <4D095C40.4030100@oracle.com> <4D0A1106.9000508@gmx.de> Message-ID: Coin is part of Java 7. There may be *more* Coin features ("Coin: the flip side") coming in 8. On Dec 16, 2010, at 2:15 PM, Ulf Zibis wrote: > Hi all, > > in the recent issue of the German "Java Spektrum" I read, that the project coin features are > scheduled for JDK-8 2012 (Plan B). (Jigsaw and Lambda too) > > Now I'm wondering, as the coin features are already in the JDK-7 codebase. > > Can someone clarify ? > > -Ulf > > From markmahieu at gmail.com Thu Dec 16 05:36:06 2010 From: markmahieu at gmail.com (Mark Mahieu) Date: Thu, 16 Dec 2010 13:36:06 +0000 Subject: coin features in JDK-7 or JDK-8 ? In-Reply-To: <4D0A1106.9000508@gmx.de> References: <4D095C40.4030100@oracle.com> <4D0A1106.9000508@gmx.de> Message-ID: Hi. Further to Brian's reply, you may also want to look over the JSR: http://www.jcp.org/en/jsr/detail?id=334 and these entries from Joe Darcy's blog: http://blogs.sun.com/darcy/entry/project_coin_javaone_2010 http://blogs.sun.com/darcy/entry/project_coin_jsr_filed Mark On 16 Dec 2010, at 13:15, Ulf Zibis wrote: > Hi all, > > in the recent issue of the German "Java Spektrum" I read, that the project coin features are > scheduled for JDK-8 2012 (Plan B). (Jigsaw and Lambda too) > > Now I'm wondering, as the coin features are already in the JDK-7 codebase. > > Can someone clarify ? > > -Ulf > > From Ulf.Zibis at gmx.de Thu Dec 16 07:06:49 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 16 Dec 2010 16:06:49 +0100 Subject: coin features in JDK-7 or JDK-8 ? In-Reply-To: References: <4D095C40.4030100@oracle.com> <4D0A1106.9000508@gmx.de> Message-ID: <4D0A2B09.6090800@gmx.de> Ok, there seems to be an error in the German magazine "Java Spektrum". For example the "switch on strings" feature is mentioned for coin to come in 2012, if I remember right. -Ulf Am 16.12.2010 14:36, schrieb Mark Mahieu: > Hi. > > Further to Brian's reply, you may also want to look over the JSR: > > http://www.jcp.org/en/jsr/detail?id=334 > > and these entries from Joe Darcy's blog: > > http://blogs.sun.com/darcy/entry/project_coin_javaone_2010 > > http://blogs.sun.com/darcy/entry/project_coin_jsr_filed > > > Mark > > > On 16 Dec 2010, at 13:15, Ulf Zibis wrote: > >> Hi all, >> >> in the recent issue of the German "Java Spektrum" I read, that the project coin features are >> scheduled for JDK-8 2012 (Plan B). (Jigsaw and Lambda too) >> >> Now I'm wondering, as the coin features are already in the JDK-7 codebase. >> >> Can someone clarify ? >> >> -Ulf >> >> > From joe.darcy at oracle.com Fri Dec 17 11:34:57 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 17 Dec 2010 11:34:57 -0800 Subject: Safe Varargs In-Reply-To: References: <4D06A974.6090003@oracle.com> Message-ID: <4D0BBB61.7040302@oracle.com> Hi Neal. On 12/13/2010 8:30 PM, Neal Gafter wrote: > This documentation uses the phrase "potentially unsafe operations" > without defining it. Presumably such unsafe operations include an > assignment to a variable of the same type (i.e. allowing the varargs > parameter to escape). Yes, we choosing at this time to not precisely define the full set of safe or unsafe operations on the parameter. Not aliasing the parameter, only reading from the parameter, and treating the parameter in an invariant sense would generally be safe. -Joe > On Monday, December 13, 2010, Joe Darcy wrote: >> Greetings. >> >> Following up on earlier work, the javac team has pushed a new >> implementation of Project Coin's simplified varargs method invocation >> feature. [1] The changes are scheduled to appear in the promotion of JDK >> 7 b123. >> >> As envisioned previously, a new @Documented annotation type, >> java.lang.SafeVararags, can be used to suppress warnings related to >> unchecked warnings, both the new mandatory warnings at the declaration >> site of a varargs method/constructor with a non-reifiable element type >> and the existing unchecked warnings at the call sites of such methods. A >> systematic application of this annotation to appropriate declarations in >> the JDK libraries will follow as future work. >> >> Since new unchecked warnings are being introduced, those diligently >> compiling with options like "-Xlint:unchecked -Werror" will see a build >> error under JDK 7 if any of the suspicious varargs method declarations >> are found. To address this, the @SafeVarargs annotation can be applied >> to the declarations, if appropriate, or the >> @SuppressWarnings({"unchecked", "varargs"}) annotation can be applied. >> Unlike @SafeVarargs, the @SuppressWarnings annotation will not squelch >> unchecked warnings at the call site of the annotated method. >> >> The specification of the new SafeVarargs annotation type is below. >> >> -Joe >> >> [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/78885e69c42c >> http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7b99f98b3035 >> >> -=-=-=-=-=-=- >> >> Annotation Type SafeVarargs >> >> @Documented >> @Retention(value=RUNTIME) >> @Target(value={CONSTRUCTOR,METHOD}) >> public @interface SafeVarargs >> >> A programmer assertion that the body of the annotated method or >> constructor does not perform potentially unsafe operations on its >> varargs parameter. Applying this annotation to a method or constructor >> suppresses unchecked warnings about a non-reifiable variable-arity >> (vararg) type and suppresses unchecked warnings about parameterized >> array creation at call sites. >> >> In addition to the usage restrictions imposed by its @Target >> meta-annotation, compilers are required to implement additional usage >> restrictions on this annotation type; it is a compile-time error if a >> method or constructor declaration is annotated with a @SafeVarargs >> annotation, and either: >> >> * the declaration is a fixed-arity method or constructor >> * the declaration is a variable-arity method that is neither >> static nor final. >> >> Compilers are encouraged to issue warnings when this annotation type is >> applied to a method or constructor declaration where: >> >> * The variable-arity parameter has a reifiable element type, >> which includes primitive types, Object, and String. (The unchecked >> warnings this annotation type suppresses already do not occur for a >> reifiable element type.) >> * The body of the method or constructor declaration performs >> potentially unsafe operations, such as an assignment to an element of >> the variable-arity parameter's array that generates an unchecked warning. >> >> Future versions of the platform may mandate compiler errors >> for such unsafe operations. >> >> >> >> From pbenedict at apache.org Fri Dec 17 11:51:56 2010 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 17 Dec 2010 13:51:56 -0600 Subject: Safe Varargs In-Reply-To: <4D0BBB61.7040302@oracle.com> References: <4D06A974.6090003@oracle.com> <4D0BBB61.7040302@oracle.com> Message-ID: Joe, > Yes, we choosing at this time to not precisely define the full set of > safe or unsafe operations on the parameter. > > Not aliasing the parameter, only reading from the parameter, and > treating the parameter in an invariant sense would generally be safe. Your above explanation would be good enough for me. At least developers could then have some sort of an idea what was intended by "safe operation". Right now, it's too vague. Paul From crazybob at crazybob.org Fri Dec 17 12:10:37 2010 From: crazybob at crazybob.org (Bob Lee) Date: Fri, 17 Dec 2010 12:10:37 -0800 Subject: Safe Varargs In-Reply-To: References: <4D06A974.6090003@oracle.com> <4D0BBB61.7040302@oracle.com> Message-ID: I'm disappointed that we're adding another type to java.lang, especially for an ugly workaround. As you know, this is roughly equivalent to adding a reserved word to the language. The original proposal (see below) didn't require this. I'm also not sure the new proposal addresses overriding varags methods. For example, if I override a method add(T[]) with add(String[]) (see proposal for more complete example), the compiler should generate a warning. On Fri, Dec 17, 2010 at 11:51 AM, Paul Benedict wrote: > Your above explanation would be good enough for me. At least > developers could then have some sort of an idea what was intended by > "safe operation". Right now, it's too vague. >From the original proposal: "For a varargs argument with a component type T, the programmer can safely suppress the warning using @SuppressWarnings("generic-varargs") so long as the varargs method ensures that only elements of type T can be stored in the varargs array." Thanks, Bob ---------- Forwarded message ---------- From: Bob Lee Date: Sun, Mar 8, 2009 at 3:29 PM Subject: PROPOSAL: Simplified Varargs Method Invocation (Round II) To: coin-dev at openjdk.java.net Simplified Varargs Method Invocation AUTHOR: Bob Lee OVERVIEW FEATURE SUMMARY: When a programmer tries to invoke a varargs (variable arity) method with a non-reifiable varargs type, the compiler currently generates an "unsafe operation" warning. This proposal moves the warning from the call site to the method declaration. MAJOR ADVANTAGE: Safely and significantly reduces the total number of warnings reported to and suppressed by programmers. Reduces programmer confusion. Enables API designers to use varargs with non-reifiable types. MAJOR BENEFITS: - Plugs a leaky abstraction. Creating an array when you call a varargs method is an implementation detail that we needn't expose to users. - Most programmers are surprised to find out they can only clear this warning by suppressing it. They expect two language features introduced in the same version to work well together. Programmers will no longer waste time looking for alternatives that don't exist. - Google Code Search finds almost 90k callers of Arrays.asList() ( http://tinyurl.com/dept4d). We can safely suppress the warning once and for all on asList()'s declaration instead of unnecessarily warning every caller that uses a non-reifiable type. MAJOR DISADVANTAGE: The compiler will generate a warning for a method declaration whether or not someone actually calls the method with a non-reifiable type. Allows loss of type safety if the varargs method suppresses the warning and uses the varargs array unsafely. Introduces a small risk of not reporting warnings if you compile against code compiled with Java 7 but run against code compiled with an earlier version. ALTERNATIVES: a) Don't mix varargs with generics. Use the more verbose and less straightforward but warning-free builder pattern. Most API designers choose this route. b) Improve the warning message. Current message: "uses unchecked or unsafe operations" c) Reify generics. d) Introduce a second varargs syntax (perhaps using "...." instead of "...") that uses List instead of T[]. e) Defile the type system. f) List literals: [a, b, c] instead of Arrays.asList(a, b, c) Note: This proposal doesn't preclude any of these other approaches. EXAMPLES SIMPLE EXAMPLE: Before this change: static List asList(T... elements) { ... } static List> stringFactories() { Callable a, b, c; ... // Warning: "uses unchecked or unsafe operations" return asList(a, b, c); } After this change: // Warning: "enables unsafe generic array creation" static List asList(T... elements) { ... } static List> stringFactories() { Callable a, b, c; ... return asList(a, b, c); } If asList() prohibits storing elements that aren't of type T in the elements array, we can safely suppress the warning: @SuppressWarnings("generic-varargs") // Ensures only values of type T can be stored in elements. static List asList(T... elements) { ... } OVERRIDE VARARGS WITH ARRAY: Before this change: interface Sink { void add(T... a); } interface BrokenSink extends Sink { /** Overrides Sink.add(T...). */ void add(T[] a); // no varargs } This code compiles and runs: BrokenSink s = ...; s.add("a", "b", "c"); // varargs A BrokenSink implementation could do something unsafe to the T[], so after this change, we generate a warning: interface BrokenSink extends Sink { // Warning: "Overriddes non-reifiable varargs type with array" void add(T[] a); } To clear the warning, the programmer should use varargs instead of an array: interface BrokenSink extends Sink { void add(T... a); } VARARGS TYPE ERASURE NARROWED BY OVERRIDE: The following method adds a non-null element to a Sink. Before this proposal, the call to Sink.add() generates a warning: static void addUnlessNull(Sink sink, T t) { if (t != null) // Warning: "uses unchecked or unsafe operations" sink.add(t); } Type T is unknown, so the method creates a single-element Object[] containing t and passes it to Sink.add(). After erasure, this String-based implementation of Sink produces a more narrow erased varargs type, specifically String[] instead of the Object[] accepted by Sink.add(): class StringSink implements Sink { public void add(String... a) { ... } } If you run the following code, the bridge method StringSink.add(Object[]) will throw a ClassCastException when it tries to cast the Object[] created in addUnlessNull() to the String[] required by StringSink.add(String[]): Sink ss = new StringSink(); addUnlessNull(ss, "Bob"); // ClassCastException! After this change, the compiler warning moves to the vargs method declaration that results in a more narrow erased array type: static void addUnlessNull(Sink sink, T t) { if (t != null) sink.add(t); // no warning } class StringSink implements Sink { // Warning: "override generates a more specific varargs type erasure" public void add(String... a) {} } At this point, the API designer would likely choose a different design without an overridable varargs method. For example: interface Sink { void add(T t); // no varargs } static void addNonNull(Sink sink, T... a) { for (T t : a) if (t != null) sink.add(t); } DETAILS SPECIFICATION: - A varargs type is reifiable if its component type is reifiable (see JLS 4.7). - When compiling code that calls a varargs method with a non-reifiable varargs type, if the target method was compiled with Java 7 or later, the compiler needn't generate a warning for the caller. (Note: This won't help if you then run against code compiled with an earlier version, but the risk is very low.) - When compiling a varargs method that could accept a non-reifiable varargs type, the compiler should generate a warning on the varargs method declaration. - If a non-varargs method overrides a varargs method with a non-reifiable varargs type, generate a warning. The warning a) makes it clear that the method can still be used like a varargs method, and b) warns the implementor to prevent unsafe operations on the array. - If a varargs method with a non-reifiable varargs type overrides another varargs method and the varargs parameter erases to a more-specific array type than that of the overridden method, generate a warning. If a client invokes the sub type implementation through the super type's interface, the client may pass in a super type of the array type expected by the sub type's method which will result in a ClassCastException at run time. - For a varargs argument with a component type T, the programmer can safely suppress the warning using @SuppressWarnings("generic-varargs") so long as the varargs method ensures that only elements of type T can be stored in the varargs array. COMPILATION: Tools should no longer generate a warning for varargs method callers. Instead, they should generate a warning on certain varargs method declarations. TESTING: Compile test programs and ensure that the compiler generates the expected warnings. LIBRARY SUPPORT: Suppress warnings on the following varargs methods in the JDK: - Arrays.asList(T... a) - Collections.addAll(Collection c, T... elements) - EnumSet.of(E first, E... rest) REFLECTIVE APIS: n/a OTHER CHANGES: n/a MIGRATION: Existing callers may be able to remove @SuppressWarnings("unchecked") from their code. Existing libraries should add @SuppressWarnings("generic-varargs") to methods with signatures containing non-reifiable varargs types. COMPATIBILITY BREAKING CHANGES: None EXISTING PROGRAMS: If you recompile an existing program with "-target 7", the compiler will generate warnings for method declarations containing non-reifiable varargs types. REFERENCES Bug #5048776: "promote varargs/non-varargs overrider diagnostics to errors" http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5048776 Bug #6227971: "generic inferrence bug in varargs" http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6227971 JLS Section 15.12.4.2 "Evaluate Arguments" ( http://java.sun.com/docs/books/jls/third_edition/html/expressions.html) "If the method being invoked is a variable arity method (?8.4.1) m, it necessarily has n>0 formal parameters. The final formal parameter of m necessarily has type T[] for some T, and m is necessarily being invoked with k0 actual argument expressions. If m is being invoked with kn actual argument expressions, or, if m is being invoked with k=n actual argument expressions and the type of the kth argument expression is not assignment compatible with T[], then the argument list (e1, ... , en-1, en, ...ek) is evaluated as if it were written as (e1, ..., en-1, new T[]{en, ..., ek}). The argument expressions (possibly rewritten as described above) are now evaluated to yield argument values. Each argument value corresponds to exactly one of the method's n formal parameters." Angelika Langer's Java Generics FAQ, "Why does the compiler sometimes issue an unchecked warning when I invoke a 'varargs' method?" ( http://tinyurl.com/8w2dk) Josh Bloch's "Effective Java" 2nd Edition, page 120 ( http://tinyurl.com/chtgbd) Alex Miller's blog, "Generics puzzler - array construction" ( http://tech.puredanger.com/2007/02/27/generics-array-construction/) "Java Generic and Collections", page 95 (http://tinyurl.com/c53pnu) From joe.darcy at oracle.com Fri Dec 17 12:17:33 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 17 Dec 2010 12:17:33 -0800 Subject: Safe Varargs In-Reply-To: References: <4D06A974.6090003@oracle.com> <4D0BBB61.7040302@oracle.com> Message-ID: <4D0BC55D.10100@oracle.com> On 12/17/2010 12:10 PM, Bob Lee wrote: > I'm disappointed that we're adding another type to java.lang, > especially for an ugly workaround. As you know, this is roughly > equivalent to adding a reserved word to the language. > > The original proposal (see below) didn't require this. > > I'm also not sure the new proposal addresses overriding varags > methods. For example, if I override a method add(T[]) with > add(String[]) (see proposal for more complete example), the compiler > should generate a warning. As documented in its specification, the SafeVarargs annotation is only applicable to static methods, final instance methods, and constructors; therefore, overriding does not occur. Annotation inheritance only works on classes (not methods, interfaces, or constructors) so without changing annotation inheritance, a SafeVarargs-style annotation cannot be passed through general instance methods in classes or through interfaces. -Joe From crazybob at crazybob.org Fri Dec 17 12:29:10 2010 From: crazybob at crazybob.org (Bob Lee) Date: Fri, 17 Dec 2010 12:29:10 -0800 Subject: Safe Varargs In-Reply-To: <4D0BC55D.10100@oracle.com> References: <4D06A974.6090003@oracle.com> <4D0BBB61.7040302@oracle.com> <4D0BC55D.10100@oracle.com> Message-ID: On Fri, Dec 17, 2010 at 12:17 PM, Joe Darcy wrote: > As documented in its specification, the SafeVarargs annotation is only > applicable to static methods, final instance methods, and constructors; > therefore, overriding does not occur. > Got it. I missed that. Bob From fweimer at bfk.de Mon Dec 20 02:11:19 2010 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 20 Dec 2010 10:11:19 +0000 Subject: For Coin 8: preservation of parameter names in class files Message-ID: <82oc8g92k8.fsf@mid.bfk.de> IDEs need parameter names for code templates (stubs for inherited abstract methods, delegates, etc.) and completion of invocations. Currently, debug information is used if available, or information parsed from Javadoc. There are useful constructs which are currently difficult to implement due to the lack of parameter names. For instance, there was a lightweight SQL mapping proposal in the JDBC update for JDK 6 which had to be killed because it turned out to be close to unimplementable due to lack of method parameter names at run time. The implementation would likely use attributes and not change the class file format. java.lang.reflect.Constructor and java.lang.reflect.Method would get a new method, getParameterNames(), which returns a fresh array array of parameter names (or an unmodifiable list, if you want sharing). I'm not sure if the implementation should try to extract parameter names from debugging information if available. If no parameter names are available, the new methods should throw IllegalStateException, in the spirit of the most of the java.lang.reflect API, which prefers exceptions over null return values. (I think this is a language change because it updates classes in java.lang.reflect.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From joe.darcy at oracle.com Mon Dec 20 07:56:25 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 20 Dec 2010 07:56:25 -0800 Subject: For Coin 8: preservation of parameter names in class files In-Reply-To: <82oc8g92k8.fsf@mid.bfk.de> References: <82oc8g92k8.fsf@mid.bfk.de> Message-ID: <4D0F7CA9.90004@oracle.com> Hello Florian. Hold that thought, coin: the flip side, won't get underway for a while, but the ability to retrieve parameter names from class files is a long-standing request from various parties so I'm sure it will be considered again for JDK 8. -Joe Florian Weimer wrote: > IDEs need parameter names for code templates (stubs for inherited > abstract methods, delegates, etc.) and completion of invocations. > Currently, debug information is used if available, or information > parsed from Javadoc. There are useful constructs which are currently > difficult to implement due to the lack of parameter names. For > instance, there was a lightweight SQL mapping proposal in the JDBC > update for JDK 6 which had to be killed because it turned out to be > close to unimplementable due to lack of method parameter names at run > time. > > The implementation would likely use attributes and not change the > class file format. java.lang.reflect.Constructor and > java.lang.reflect.Method would get a new method, getParameterNames(), > which returns a fresh array array of parameter names (or an > unmodifiable list, if you want sharing). I'm not sure if the > implementation should try to extract parameter names from debugging > information if available. If no parameter names are available, the > new methods should throw IllegalStateException, in the spirit of the > most of the java.lang.reflect API, which prefers exceptions over null > return values. > > (I think this is a language change because it updates classes in > java.lang.reflect.) > > From tronicek at fit.cvut.cz Sun Dec 26 20:50:32 2010 From: tronicek at fit.cvut.cz (=?utf-8?B?IlpkZW7Em2sgVHJvbsOtxI1layI=?=) Date: Mon, 27 Dec 2010 05:50:32 +0100 Subject: FYI, "Updating JDK libraries to use Project Coin features" In-Reply-To: <4D082BE0.3080500@oracle.com> References: <4D082BE0.3080500@oracle.com> Message-ID: Hi, RefactoringNG can be used to update the code in batch. For example, the following rule used in v0.3 (http://kenai.com/projects/refactoringng/downloads) will update the code to the diamond operator: NewClass { Expression [id: enclosing, nullable: true], List [id: typeArgs], ParameterizedType { Expression [id: ident], List }, List [id: args], Class [id: body, elementKind: CLASS, nullable: true] } -> NewClass { Expression [ref: enclosing], List [ref: typeArgs], ParameterizedType { Expression [ref: ident], List { } }, List [ref: args], Class [ref: body] } (NetBeans 7 throws NullPointerException, but it is not severe and you can continue. In NetBeans 6, it is performed without any error.) When trying this, I found inconsistency in javac's AST. In NewClassTree, identifier is ExpressionTree: public interface NewClassTree extends ExpressionTree { ExpressionTree getEnclosingExpression(); List getTypeArguments(); ExpressionTree getIdentifier(); List getArguments(); ClassTree getClassBody(); } However, for new ArrayList() the identifier is ParameterizedTypeTree which is not ExpressionTree: public interface ParameterizedTypeTree extends Tree { Tree getType(); List getTypeArguments(); } Z.T. -- Zdenek Tronicek FIT CTU in Prague Joe Darcy napsal(a): > Hello. > > FYI, we'll soon start a process to systematically update the JDK > libraries to use Project Coin features: > > http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-December/001727.html > > -Joe > > From joe.darcy at oracle.com Mon Dec 27 10:51:13 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 27 Dec 2010 10:51:13 -0800 Subject: FYI, "Updating JDK libraries to use Project Coin features" In-Reply-To: References: <4D082BE0.3080500@oracle.com> Message-ID: <4D18E021.8020409@oracle.com> FYI, Stuart explains the Jackpot-based automated tooling he is using in this blog entry: http://stuartmarks.wordpress.com/2010/12/23/jdk7-coin-and-making-libraries-fresh-and-minty/ -Joe On 12/26/2010 8:50 PM, "Zden?k Tron??ek" wrote: > Hi, > > RefactoringNG can be used to update the code in batch. > For example, the following rule used in v0.3 > (http://kenai.com/projects/refactoringng/downloads) will update the code > to the diamond operator: > > NewClass { > Expression [id: enclosing, nullable: true], > List [id: typeArgs], > ParameterizedType { > Expression [id: ident], > List > }, > List [id: args], > Class [id: body, elementKind: CLASS, nullable: true] > } -> > NewClass { > Expression [ref: enclosing], > List [ref: typeArgs], > ParameterizedType { > Expression [ref: ident], > List { } > }, > List [ref: args], > Class [ref: body] > } > > (NetBeans 7 throws NullPointerException, but it is not severe and you can > continue. In NetBeans 6, it is performed without any error.) > > When trying this, I found inconsistency in javac's AST. In NewClassTree, > identifier is ExpressionTree: > > public interface NewClassTree extends ExpressionTree { > ExpressionTree getEnclosingExpression(); > List getTypeArguments(); > ExpressionTree getIdentifier(); > List getArguments(); > ClassTree getClassBody(); > } > > However, for new ArrayList() the identifier is > ParameterizedTypeTree which is not ExpressionTree: > > public interface ParameterizedTypeTree extends Tree { > Tree getType(); > List getTypeArguments(); > } > > Z.T. From lnarasimhan at in.ibm.com Mon Dec 27 14:36:47 2010 From: lnarasimhan at in.ibm.com (Lakshmi Narasimhan) Date: Tue, 28 Dec 2010 04:06:47 +0530 Subject: AUTO: Lakshmi Narasimhan is on leave (returning 29/12/2010) Message-ID: I am out of the office until 29/12/2010. Please contact Amar Devegowda (adevegow at in.ibm.com) for any queries on Class Libraries. For anything else, please contact my manager Arvind Ramakrishnan (arvindr at in.ibm.com) Note: This is an automated response to your message "coin-dev Digest, Vol 23, Issue 10" sent on 28/12/10 1:30:01. This is the only notification you will receive while this person is away.