Hi Shilpi, I will be happy to sponsor the push. Best, Michael
Am 07.06.2016 um 11:39 schrieb shilpi.rastogi@oracle.com:
Thanks Joseph!! Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.05/
Regards, Shilpi
On 6/7/2016 6:00 AM, Joseph D. Darcy wrote:
Hello,
The test
45 void testAnnotationWithLambda() { 46 Method[] methods = AnnotationWithLambda.MethodsWithAnnotations.class.getDeclaredMethods(); 47 for (Method method : methods) { 48 assertEquals(1, method.getDeclaredAnnotations().length); 49 } 50 }
is very non-specific in what it is testing. A better test would include something like
method.isAnnotationPresent(@LambdaWithParameter) && method.isAnnotationPresent(@LambdaWithouParameter)
if both annotations were put on the same method.
Cheers,
-Joe
On 6/6/2016 12:20 AM, shilpi.rastogi@oracle.com wrote:
Gentle reminder!!
On 6/3/2016 11:40 AM, shilpi.rastogi@oracle.com wrote:
Thanks Vladimir and Joel!! Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.04/ Added restriction for synthetic methods as well.
On 6/2/2016 5:04 PM, Vladimir Ivanov wrote:
On 6/2/16 12:02 AM, Joel Borggrén-Franck wrote:
Hi,
I think this was caught by the verifier before 8 since you couldn't have concrete or private methods in an interface. Now you can (though not in Java for private ones).
My spider sense tells me there might be something lurking here (though it was a while since this was in my L1 cache). It is not likely, but I'm not 100% sure that it is impossible to make javac produce a bridge when compiling an annotation type for example, so why not remove synthetic methods as well?
I'm not an expert in annotation processing, but it bothers me as well, since current behavior looks too Java-centric. There are valid (in JVMS sense) class files which are not produced by javac or from java source file.
What is expected behavior in such case? It is unfortunate when non-Java languages have to obey to Java rules. It reminds me a problem with Class.getSimpleName() (see JDK-8057919 [1]) we fixed some time ago. Best regards, Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8057919
Spending some time with ASM to do a bunch of tests not compilable in java might be useful, there should also be some frameworks in langtools to produce invalid classfiles IIRC.
Raised https://bugs.openjdk.java.net/browse/JDK-8158510 to include new test cases.
Regards, Shilpi
cheers /Joel
On Tue, 31 May 2016 at 17:49 shilpi.rastogi@oracle.com <mailto:shilpi.rastogi@oracle.com> <shilpi.rastogi@oracle.com <mailto:shilpi.rastogi@oracle.com>> wrote:
Thanks Paul!! Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.03/
Thanks, Shilpi
On 5/31/2016 7:57 PM, Paul Sandoz wrote: > >"Returns an array containing Method objects reflecting all the declared methods of the class or interface represented by this Class object, including public, protected, default (package) access, and private methods, but excluding inherited methods."
-- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment