From linuxhippy at gmail.com Sat Nov 1 21:21:21 2014 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 1 Nov 2014 22:21:21 +0100 Subject: Are there prebuilt binaries of (open)jdk8-b110 to (open)jdk8-b120 still available somewhere? Message-ID: Hi, Since the rollout of JDK8 via the auto-update started, I received several reports of users complaining about servere focus-issues in one of our applications running on different platforms. The cause of the problem is that we open a JPopup for autocompletion support below a JTextField, and immediatly after calling show() we are calling requestFocus() on the JTextField - so that the user can continue to type while we hiding and showing new popups with updated content. However with Java-8 the requestFocus() often leads to JRootPane receiving focus, and not the JTextField itself. I've worked-arround the issue by calling setFocuseable(false) on the JPopup. Nonetheless there is a regression or at least a behaviour-change in Java8 I would like to track down. I commit in question happend between b110 (still works) and b120 (broken), however the build-system changed quite heavily and it is a real pain to get every build-number compiling. What would help a lot would be pre-built binaries of jdk8-b110 to jdk8-b120, so I could at least find the first build with the issue. Are those binaries of oracle's EA builds available at jdk8.java.net still availbale somewhere? (I know this is kind of off-topic, but the issue is present in openjdk as well as Oracle's binary distribution). Thank you in advance, Clemens From linuxhippy at gmail.com Sat Nov 1 22:59:01 2014 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 1 Nov 2014 23:59:01 +0100 Subject: Are there prebuilt binaries of (open)jdk8-b110 to (open)jdk8-b120 still available somewhere? In-Reply-To: References: Message-ID: Hi again, I was able to find the commit which introduced the issues mentioned earlier. Unfortunetely it is a "merge" commit and therefore contains many seemingly non-related changes: > changeset: 8894:657a3cccf8a1 > parent: 8839:2bcdf1e05642 > parent: 8893:2370d285d08b > user: lana > date: Wed Nov 27 10:47:53 2013 -0800 > summary: Merge Are there ways to split this large commit into the smaller sub-commits it does exist of? Otherwise I don't see a way how to bisect this further... Thank you in advance, Clemens From linuxhippy at gmail.com Sun Nov 2 10:16:24 2014 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sun, 2 Nov 2014 11:16:24 +0100 Subject: Are there prebuilt binaries of (open)jdk8-b110 to (open)jdk8-b120 still available somewhere? In-Reply-To: <5455F3CA.9050705@oracle.com> References: <5455F3CA.9050705@oracle.com> Message-ID: Hi Sergey, hi Alan, > Looks like default jdk8 page suggest to download builds of 8u40 only, but if I change those links manually I am able to download b119... Thanks for the suggestions and good to know the binaries are still available. I was able to track this down to: 7160604 client-libs Using non-opaque windows - popups are initially not painted correctly and will bother the AWT team with my findings ;) Thanks and best regards, Clemens From mparchet at sunrise.ch Mon Nov 3 07:20:10 2014 From: mparchet at sunrise.ch (=?UTF-8?B?TWljaGHDq2wgUGFyY2hldA==?=) Date: Mon, 03 Nov 2014 08:20:10 +0100 Subject: [suggestion]java multiple inheritence Message-ID: <54572CAA.7070003@sunrise.ch> Hello, In the futture, why not implement the multiple intermittence and other python or c++ function ? For exemple class1 extends class2,class3 { super class2() :: class1() { } Is it possible ? Thanks for your answer Best regards mparchet From neugens.limasoftware at gmail.com Mon Nov 3 07:24:22 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 3 Nov 2014 08:24:22 +0100 Subject: [suggestion]java multiple inheritence In-Reply-To: <54572CAA.7070003@sunrise.ch> References: <54572CAA.7070003@sunrise.ch> Message-ID: I don't think something like that is advisable :) You can use interfaces to achieve something similar, and even in this case you need extra care to keep your code well maintained especially now with default methods. Cheers, Mario Il 03/nov/2014 08:20 "Micha?l Parchet" ha scritto: > Hello, > > In the futture, why not implement the multiple intermittence and other > python or c++ function ? > > > For exemple > > class1 extends class2,class3 > { > super class2() :: class1() { > > } > Is it possible ? > > Thanks for your answer > > Best regards > > mparchet > From manasthakur17 at gmail.com Thu Nov 6 05:48:18 2014 From: manasthakur17 at gmail.com (Manas Thakur) Date: Thu, 6 Nov 2014 11:18:18 +0530 Subject: Building openjdk 8 on Mac OS X Message-ID: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> I have tried building openjdk8 on mac os x yosemite by trying all means available on net. I made xcode4.6.3 as the default one; configure is fine, but I get several errors while making the hotspot images in FSEvents.h and NSUserNotification.h. I tried following some suggestions regarding commenting some lines, but that doesn?t work as well. - Manas From david.holmes at oracle.com Thu Nov 6 08:30:07 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Nov 2014 18:30:07 +1000 Subject: Building openjdk 8 on Mac OS X In-Reply-To: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> References: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> Message-ID: <545B318F.3090805@oracle.com> Re-directing to build-dev - please don't respond further on the discuss list. David On 6/11/2014 3:48 PM, Manas Thakur wrote: > I have tried building openjdk8 on mac os x yosemite by trying all means available on net. I made xcode4.6.3 as the default one; configure is fine, but I get several errors while making the hotspot images in FSEvents.h and NSUserNotification.h. > I tried following some suggestions regarding commenting some lines, but that doesn?t work as well. > > - Manas > > > > > From neugens at redhat.com Tue Nov 11 11:23:12 2014 From: neugens at redhat.com (Mario Torre) Date: Tue, 11 Nov 2014 12:23:12 +0100 Subject: Method and Field Literals Message-ID: <1415704992.3847.8.camel@nirvana.localdomain> Hi all, Yesterday I came across a use case where having method literals would have been very, very handy. Before I started to play with the idea of writing up a proposal, I went on looking for someone who already did, and it occurred to me that it was done here: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000388.html But I'm not sure what happened to it (I'm still going through the whole thread but it seems that the discussion just stops at some point). I think method literals are a very nice addition. My own use case would be to have a compile time description of a java class. Let's make a simple example: class SomeBean { getTimestamp() } Map descriptors = SomeBeanUtility.createDescriptors(SomeBean.class); PropertyDescriptor prop = descriptors.get(SomeBean#getTimestamp); No more strings! What do you think about resuming the original discussion? This seems a very good thing to put into Java 9. Cheers, Mario From brian.goetz at oracle.com Tue Nov 11 11:28:39 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 11 Nov 2014 12:28:39 +0100 Subject: Method and Field Literals In-Reply-To: <1415704992.3847.8.camel@nirvana.localdomain> References: <1415704992.3847.8.camel@nirvana.localdomain> Message-ID: <8FE590A4-05F1-4CA1-8BB5-B14B585144D9@oracle.com> Method and field literals came up during lambda. (As did method handle literals ). The upshot was that while we did not dislike them, they were sufficiently distant from the lambda mission that, when the inevitable need to cut scope made its appearance, they didn't make the cut. But they are on the list of features to b considered. Sent from my iPhone > On Nov 11, 2014, at 12:23 PM, Mario Torre wrote: > > Hi all, > > Yesterday I came across a use case where having method literals would > have been very, very handy. > > Before I started to play with the idea of writing up a proposal, I went > on looking for someone who already did, and it occurred to me that it > was done here: > > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000388.html > > But I'm not sure what happened to it (I'm still going through the whole > thread but it seems that the discussion just stops at some point). > > I think method literals are a very nice addition. > > My own use case would be to have a compile time description of a java > class. Let's make a simple example: > > class SomeBean { getTimestamp() } > > Map descriptors = > SomeBeanUtility.createDescriptors(SomeBean.class); > > PropertyDescriptor prop = descriptors.get(SomeBean#getTimestamp); > > No more strings! > > What do you think about resuming the original discussion? This seems a > very good thing to put into Java 9. > > Cheers, > Mario > > > From neugens at redhat.com Tue Nov 11 12:03:26 2014 From: neugens at redhat.com (Mario Torre) Date: Tue, 11 Nov 2014 13:03:26 +0100 Subject: Method and Field Literals In-Reply-To: <8FE590A4-05F1-4CA1-8BB5-B14B585144D9@oracle.com> References: <1415704992.3847.8.camel@nirvana.localdomain> <8FE590A4-05F1-4CA1-8BB5-B14B585144D9@oracle.com> Message-ID: <1415707406.3847.10.camel@nirvana.localdomain> On Tue, 2014-11-11 at 12:28 +0100, Brian Goetz wrote: > Method and field literals came up during lambda. (As did method > handle literals ). The upshot was that while we did not dislike them, > they were sufficiently distant from the lambda mission that, when the > inevitable need to cut scope made its appearance, they didn't make the > cut. But they are on the list of features to b considered. Hi Brian, Very nice to hear that. Do you plan to resume the discussion for 9 or later? If 9 is the goal, is there a public space where this is being tracked/discussed so we can follow it? Cheers, Mario From gunnar at hibernate.org Tue Nov 11 12:55:22 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 11 Nov 2014 13:55:22 +0100 Subject: Method and Field Literals In-Reply-To: <1415707406.3847.10.camel@nirvana.localdomain> References: <1415704992.3847.8.camel@nirvana.localdomain> <8FE590A4-05F1-4CA1-8BB5-B14B585144D9@oracle.com> <1415707406.3847.10.camel@nirvana.localdomain> Message-ID: Hi, 2014-11-11 13:03 GMT+01:00 Mario Torre : > On Tue, 2014-11-11 at 12:28 +0100, Brian Goetz wrote: > > Method and field literals came up during lambda. (As did method > > handle literals ). The upshot was that while we did not dislike them, > > they were sufficiently distant from the lambda mission that, when the > > inevitable need to cut scope made its appearance, they didn't make the > > cut. But they are on the list of features to b considered. > > Hi Brian, > > Very nice to hear that. Do you plan to resume the discussion for 9 or > later? > > If 9 is the goal, is there a public space where this is being > tracked/discussed so we can follow it? > FWIW, method/field literals would be very useful for POJO-centric libraries such as JPA/Hibernate, Bean Validation etc. In several Hibernate projects we have APIs which allow for some sort of "configuration" of bean properties (e.g. to specify constraints in the case of Bean Validation [1]). These APIs are provided as an alternative to annotations for specifying different kinds of meta-data in more dynamic manner. Atm. we use the tuple (property name, element type) for specifying the configured elements. Real literals of course would be much nicer for this and would improve type-safety of such APIs. While method/field literals themselves already would be very helpful, being able to specify them within annotation values (similar to class literals today) would add another benefit e.g. for data binding scenarios. Cheers, > Mario > Cheers, --Gunnar [1] https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#section-programmatic-api From paul.sandoz at oracle.com Tue Nov 11 14:03:17 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 11 Nov 2014 15:03:17 +0100 Subject: Method and Field Literals In-Reply-To: <8FE590A4-05F1-4CA1-8BB5-B14B585144D9@oracle.com> References: <1415704992.3847.8.camel@nirvana.localdomain> <8FE590A4-05F1-4CA1-8BB5-B14B585144D9@oracle.com> Message-ID: <60A836B0-A52C-498C-B71F-E77C2AEE011F@oracle.com> On Nov 11, 2014, at 12:28 PM, Brian Goetz wrote: > Method and field literals came up during lambda. (As did method handle literals ). The upshot was that while we did not dislike them, they were sufficiently distant from the lambda mission that, when the inevitable need to cut scope made its appearance, they didn't make the cut. But they are on the list of features to b considered. > See the following for a use-case using field references to look VarHandles: http://openjdk.java.net/jeps/193 At some point in the near future i want to prototype this in the valhalla repo. Paul. From brian.goetz at oracle.com Tue Nov 11 15:44:21 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 11 Nov 2014 16:44:21 +0100 Subject: Method and Field Literals In-Reply-To: References: <1415704992.3847.8.camel@nirvana.localdomain> <8FE590A4-05F1-4CA1-8BB5-B14B585144D9@oracle.com> <1415707406.3847.10.camel@nirvana.localdomain> Message-ID: <072EBF49-1ECB-4019-95A3-914CC0E39870@oracle.com> Yes, we are aware that there is a contingent out there that would like this a lot. Even if we had method and field literals, though, this isn't free -- it's another feature on top of them. But we are on board with the goal of reducing the need to program with untyped strings. Sent from my iPhone > On Nov 11, 2014, at 1:55 PM, Gunnar Morling wrote: > > Hi, > > 2014-11-11 13:03 GMT+01:00 Mario Torre : >> On Tue, 2014-11-11 at 12:28 +0100, Brian Goetz wrote: >> > Method and field literals came up during lambda. (As did method >> > handle literals ). The upshot was that while we did not dislike them, >> > they were sufficiently distant from the lambda mission that, when the >> > inevitable need to cut scope made its appearance, they didn't make the >> > cut. But they are on the list of features to b considered. >> >> Hi Brian, >> >> Very nice to hear that. Do you plan to resume the discussion for 9 or >> later? >> >> If 9 is the goal, is there a public space where this is being >> tracked/discussed so we can follow it? > > FWIW, method/field literals would be very useful for POJO-centric libraries such as JPA/Hibernate, Bean Validation etc. > > In several Hibernate projects we have APIs which allow for some sort of "configuration" of bean properties (e.g. to specify constraints in the case of Bean Validation [1]). These APIs are provided as an alternative to annotations for specifying different kinds of meta-data in more dynamic manner. Atm. we use the tuple (property name, element type) for specifying the configured elements. Real literals of course would be much nicer for this and would improve type-safety of such APIs. > > While method/field literals themselves already would be very helpful, being able to specify them within annotation values (similar to class literals today) would add another benefit e.g. for data binding scenarios. > >> Cheers, >> Mario > > Cheers, > > --Gunnar > > [1] https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#section-programmatic-api > > From gunnar at hibernate.org Fri Nov 21 08:02:22 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 21 Nov 2014 09:02:22 +0100 Subject: Language feature proposal: Partial Java types Message-ID: Hi, At Devoxx last week, Brian gave indications that properties are unlikely to be added as a Java language feature [1], one of the reasons being that several competing ideas exist how "properties" should look like. As a work-around, the required boiler-plate code can be generated using annotation processors (see e.g. Joe's post at [2]). That approach is limited though by the fact that the JSR 269 API is not meant to modify sources. Only additional sources may be generated, e.g. a super-class with getters/setters. Projects such as Lombok [3] try to fill the gap by altering the AST via internal APIs. This works, but it bends the usage of annotation processors quite a bit. I therefore would like to suggest the addition of partial types to the Java language. Similar to what's possible in C# [4], that'd allow the source code of one Java class/interface to be split up into several source files. That way, annotation processors (and other tools such as IDEs) could generate amendments to classes by creating additional parts which all together form the resulting type. The following shows an example: // this part is hand-written; e.g. in src/main/java @Partial public class OrderLine { @Property private String item; // ... } // this part is generated; e.g. in target/generated-sources @Partial public class OrderLine { public String getItem() { return item }; public void setItem(String item) { this.item = item }; } The @Partial annotation (or a specific keyword) denotes that the OrderLine class comprises of several parts. The @Property annotation is a custom annotation, triggering a corresponding annotation processor which generates the second part with the getter/setter for the property. Partials would be a compile-time only feature. The compiler would have to consider all the parts of a class; At runtime, the OrderLine class would exactly look as if it was given in one source file. Partial types would allow for the implementation of "soft keywords" to emulate language features via code generators. Examples are properties, property "literals", delegates etc. Instead of baking all these things into the language, projects could have their own notion of such concepts if they wish. I believe partial types would be in the spirit of JSR 269, as one still would not modify existing sources, but rather add new sources. The developer would see all the source code of a class, so there is no mismatch between the sources and the AST. IDE tooling could provide linking and easy navigation between all the parts of one class. I'd be very interested in any feedback on this. Would it be worth pursuing? If so, I could try to work on a more specific proposal and/or prototype implementing this feature. Thanks, --Gunnar [1] http://blog.joda.org/2014/11/no-properties-in-java-language.html [2] https://blogs.oracle.com/darcy/entry/properties_via_annotation_processing [3] http://projectlombok.org/ [4] http://msdn.microsoft.com/en-us/library/wa80x488.aspx From scolebourne at joda.org Fri Nov 21 12:31:46 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 21 Nov 2014 12:31:46 +0000 Subject: Language feature proposal: Partial Java types In-Reply-To: References: Message-ID: There are definitely use cases for a feature like this. For example, Joda-Beans [1] adopts the source code generation approach to beans. This results in classes that are 90% autogenerated code: Mutable, with setters as well as getters: https://github.com/JodaOrg/joda-beans/blob/v1.0/src/test/java/org/joda/beans/gen/SimplePerson.java#L43 Immutable, with getters and builders: https://github.com/JodaOrg/joda-beans/blob/v1.0/src/test/java/org/joda/beans/gen/ImmPerson.java#L52 This approach ensures good Javadoc and debugging, because the classes are just standard Java source files. It also allows genuinely immutable classes (because they can be final). But it is far from ideal, and partial classes, or the ability to generate into the same source file, is really what is needed here. However, desirability does not create engineering development time within Oracle. (The choice of using annotation processing to generate an implementation - as per the AutoValue or Immutables projects - is one option, but we felt the trade off of having real Java source code was preferable, providing the class can be regenerated without losing logic added by the developer. Joda-Beans also provides abstraction over properties, which isn't provided by those other projects.) Just to note that value types in a future JDK may provide some of what is needed here for "immutable beans" (though not all). But Brian Goetz has also noted that large value types may behave in a different way to smaller ones that fit in registers. Stephen [1] http://www.joda.org/joda-beans/ On 21 November 2014 08:02, Gunnar Morling wrote: > several parts would allow for the implementation of "soft keywords" to > emulate language features via code generators> > > Hi, > > At Devoxx last week, Brian gave indications that properties are unlikely to > be added as a Java language feature [1], one of the reasons being that > several competing ideas exist how "properties" should look like. > > As a work-around, the required boiler-plate code can be generated using > annotation processors (see e.g. Joe's post at [2]). That approach is > limited though by the fact that the JSR 269 API is not meant to modify > sources. Only additional sources may be generated, e.g. a super-class with > getters/setters. Projects such as Lombok [3] try to fill the gap by > altering the AST via internal APIs. This works, but it bends the usage of > annotation processors quite a bit. > > I therefore would like to suggest the addition of partial types to the Java > language. Similar to what's possible in C# [4], that'd allow the source > code of one Java class/interface to be split up into several source files. > > That way, annotation processors (and other tools such as IDEs) could > generate amendments to classes by creating additional parts which all > together form the resulting type. The following shows an example: > > // this part is hand-written; e.g. in src/main/java > @Partial > public class OrderLine { > > @Property private String item; > > // ... > } > > // this part is generated; e.g. in target/generated-sources > @Partial > public class OrderLine { > > public String getItem() { return item }; > public void setItem(String item) { this.item = item }; > } > > The @Partial annotation (or a specific keyword) denotes that the OrderLine > class comprises of several parts. The @Property annotation is a custom > annotation, triggering a corresponding annotation processor which generates > the second part with the getter/setter for the property. > > Partials would be a compile-time only feature. The compiler would have to > consider all the parts of a class; At runtime, the OrderLine class would > exactly look as if it was given in one source file. > > Partial types would allow for the implementation of "soft keywords" to > emulate language features via code generators. Examples are properties, > property "literals", delegates etc. Instead of baking all these things into > the language, projects could have their own notion of such concepts if they > wish. > > I believe partial types would be in the spirit of JSR 269, as one still > would not modify existing sources, but rather add new sources. The > developer would see all the source code of a class, so there is no mismatch > between the sources and the AST. IDE tooling could provide linking and easy > navigation between all the parts of one class. > > I'd be very interested in any feedback on this. Would it be worth pursuing? > If so, I could try to work on a more specific proposal and/or prototype > implementing this feature. > > Thanks, > > --Gunnar > > [1] http://blog.joda.org/2014/11/no-properties-in-java-language.html > [2] > https://blogs.oracle.com/darcy/entry/properties_via_annotation_processing > [3] http://projectlombok.org/ > [4] http://msdn.microsoft.com/en-us/library/wa80x488.aspx From neugens at redhat.com Fri Nov 21 15:26:48 2014 From: neugens at redhat.com (Mario Torre) Date: Fri, 21 Nov 2014 16:26:48 +0100 Subject: Possible new project: OpenJDK LaF In-Reply-To: <1409220286.25913.8.camel@nirvana.localdomain> References: <1409155016.25913.6.camel@nirvana.localdomain> <1409220286.25913.8.camel@nirvana.localdomain> Message-ID: <1416583608.22846.43.camel@nirvana.localdomain> On Thu, 2014-08-28 at 12:04 +0200, Mario Torre wrote: > On Wed, 2014-08-27 at 17:03 +0100, Martijn Verburg wrote: > > I think a move to GTK 3 would eliminate a class of java/Linux desktop > > issues we run across today. My concern would be the long term maintenance > > of this piece... Given no further comments on this thread, I went ahead and created a draft JEP proposal: https://bugs.openjdk.java.net/browse/JDK-8065658 I would appreciate if you could comment on this and help me out moving forward. Please, ensure that all the replies happen to be on the swing-dev mailing list. Thanks! Mario From gunnar at hibernate.org Fri Nov 21 18:03:39 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 21 Nov 2014 19:03:39 +0100 Subject: Language feature proposal: Partial Java types In-Reply-To: References: Message-ID: 2014-11-21 13:31 GMT+01:00 Stephen Colebourne : > There are definitely use cases for a feature like this. For example, > Joda-Beans [1] adopts the source code generation approach to beans. [...] > This approach ensures good Javadoc and debugging, because the classes > are just standard Java source files. It also allows genuinely > immutable classes (because they can be final). But it is far from > ideal, and partial classes, or the ability to generate into the same > source file, is really what is needed here. Right, generators like Joda-Beans are exactly what I have in mind here. Also some UI builders work with "protected regions" where they put generated code; Clearly a separate part for generated code would be very beneficial. > However, desirability does > not create engineering development time within Oracle. > Yes, I understand that. I still wanted to bring it up as it would allow developers and libraries out there to define their own approach for things such as properties or traits. The desire to add these features to the language itself might be reduced if they can be emulated sufficiently well on a library level. This may be a way out for cases where features can't be added natively because it's not clear which approach to take (properties) or because they don't pull their weight in terms of complexity cost as they are only interesting for a minority of users etc. From arjan.tijms at gmail.com Sat Nov 22 15:51:56 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Sat, 22 Nov 2014 16:51:56 +0100 Subject: Method and Field Literals Message-ID: >FWIW, method/field literals would be very useful for POJO-centric libraries such as JPA/Hibernate, Bean Validation etc. Absolutely, in fact JPA is now simulating Field Literals by means of generating a so-called Metamodel for every entity class. See https://docs.oracle.com/javaee/6/tutorial/doc/gjiup.html#gjivl In short, given a class: public class Foo { public String bar; } JPA generates a class Foo_: @Static @Metamodel(Foo.class) public class Foo_ { public static volatile SingularAttribute bar; } Everywhere a Field Literal would be actually needed, we then use Foo_.bar, half telling ourselves that there's the imaginary operator "_.". While this works, it's a nasty workaround and for some reason it's always an issue to generate that Metamodel. Real Field Literals would make this so much easier. Kind regards, Arjan Tijms