From martijnverburg at gmail.com Wed Jul 4 15:47:19 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 4 Jul 2018 16:47:19 +0100 Subject: Workshop Discussion Proposals from Adoption Group / LJC Message-ID: Hi all, I'm still wrangling schedules to try and get to the workshop but I thought I'd share these anyhow. *AdoptOpenJDK Build Farm 1. We would like to discuss some small changes to source control practices at OpenJDK to make life easier for builders of OpenJDK. In particular we'd like to get agreement on specific release tags so OpenJDK builders can match Oracle's OpenJDK quarterly and CPU releases. 2. The AdoptOpenJDK build farm infrastructure as code includes build scripts, installers, container support, test scripts / suites and JCK utilities (for those who are JCK signatories). How can we make this easier either technically or process wise for folks so that all vendors / parties can benefit from this shared resource? An ideal outcome here is that all vendors can save time and effort on build and test of OpenJDK (no one competes on build / farms) and end users have openly audited, consistent OpenJDK binaries. 3. The AdoptOpenJDK build farm hosts are intended for use by all vendors / interested parties (within reason). How can we make this easier either technically or process wise for folks? Some benefits include being able to better support Java's WORA promise across more ports (AIX, Zos, Arm 32/64, Win32, z390 et al) and to disseminate and test early binaries of builds coming out of amber, valhalla etc. 1. The AdoptOpenJDK build farm team would like to discuss OpenJDK (LTS) patch maintenance (once public updates by Oracle cease for an LTS release). An ideal outcome would be to have clear identification of security and stability patches so that other OpenJDK vendors can back port for their own implementations.Adoption Group 1. The Adoption Group has been going for awhile and has had some success, but not the impact it would have liked. We'd like to discuss the outstanding barriers that developers wanting to contribute to OpenJDK face today so that we can improve the number and velocity of newcomers to OpenJDK. 2. We'd like to discuss the current state of Java 9+ adoption in production and what changes OpenJDK may need to make in order to improve that in order to reduce the length of time that the industry stays on Java 8.OpenJDK Roadmap 1. We'd like to discuss the OpenJDK strategic roadmap, for example is Cloud / Container support the top priority for the next 6 releases? It would be interesting to discuss how that Roadmap could be visualised with JEP's fulfilling the various goals. 1. We'd like to discuss the OpenJDK roadmap specifically around:1. Value Types and related work2. Safer replacements for functionality in sun.misc.Unsafe 3. GPU support / Support for ML specific hardware4. Java Packager5. FFI6. Improvements to Jigsaw These topics in particular are 'future' items that various LJC developers have stated are of most interest to their businesses. 1. We'd like to discuss OpenJDK jdk8u maintenance once public updates by Oracle cease. An ideal outcome would be to find maintainer(s) going forwards.* Questions, comments etc all welcome. Cheers, Martijn From johan.vos at gluonhq.com Wed Jul 4 16:06:11 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 4 Jul 2018 18:06:11 +0200 Subject: workshop umbrella proposal: Java in more environments Message-ID: This is not yet a Topic proposal, but I want to create one or more topics, based on feedback. TLDR: does OpenJDK need to focus on more functionality, or on more portability (support for more architectures and OS'es, and getting rid of more non-core functionality like java.desktop) so that it is more applicable in tomorrows and future environments. Idea: Making Java relevant in new, disruptive IT developments with a huge impact on society. I realize this topic may sound less relevant for a technical OpenJDK workshop. Granted, for a big part this is indeed a political topic, but there are some technical aspects that I want to cover. There are a number of input triggers for this topic: * The blog entry [1] by Steve Poole and the related slide deck [2]. * My observation from the Devoxx CFP: We got a huge amount of submissions in the "Methodology & Culture" and "Cloud, Containers & Infrastructure" tracks. But we got barely submissions in the "Big Data & Machine Learning" track. That is triggering an alarm for me. * Interactions with data scientists over the past months, some claim Java is becoming less relevant. Java is very strong in the server-side, including Cloud and serverless. That's great. I'm a long-time track lead for server-side Java in Devoxx, and I am very happy with the status of Java in this area. However, the future of IT development is more and more leaning towards AI, embedded/mobile systems, quantum computing, Software 2.0[3]. Java is less popular there. There are a number of reasons for this, including a few technical ones. But a major reason, imho, is the image of Java, which is highly associated with the image of its steward (Oracle). Oracle is clearly more prominent in enterprise applications etc than in data science or scientific areas, and there is nothing wrong with that. But Java is also more associated with enterprise only and much less with data science, embedded, mobile, quantum computing,... and that, imho, is very wrong (By no means I want to blame Oracle for this, it is just a wrong association) With Gluon, we're active in those areas (mobile/embedded/AI[4] /quantum computing[5]). We're doing fine, but we don't have the weight to determine the image of Java. The Java tweet handle and related publications are very good in promoting community-related content, but even that is not changing the image and perception of Java. I am not asking Oracle to increase its investments in the areas I mentioned. (Actually, I did ask but the answer was clear). I would rather do a shout-out to other large companies with enough weight to publicly embrace Java in AI, Quantum Computing, Mobile, Embedded. How is this relevant to OpenJDK? I'm the current project lead for OpenJDK Mobile. That doesn't sound right. Mobile, as well as embedded, should be a first-class citizen in OpenJDK. I still have to hear the first valid reason on why Java won't work in the current mobile landscape. Unfortunately, I also still have to hear the first senior VP or higher from a big company saying in public that Java is an excellent choice on mobile instead of the "On mobile, JavaScript is our preferred technology". There exist a (small) number of solutions that bring Java to mobile. I got bashed by a "competitor" who sort of called me a lunatic because I think the best Java solution on mobile is based on OpenJDK[6]. I mean, what else? OpenJDK, being the heart of Java, should be the basis for Java everywhere. One of the key differentiators of the Java Platform is the fact that it runs on a myriad of configurations, architectures and operating systems. I think it would be best for OpenJDK to provide less functionality, but making sure all functionality works on a wide variety of platforms. Removing OpenJFX and Nashorn from the core OpenJDK are good steps in that direction, but there is more functionality that probably need to be stripped (e.g. the whole java.desktop module) so that resources can focus on WORA. The OpenJDK project does a great job in observing interesting patterns in emerging languages, and bringing those into the Java language and/or platform. But we have to make sure to observe a whole shift in the way IT is impacting our society. If Java misses this train, it will still stay relevant for a very, very long time. But it would be a huge pity, to Java developers, to society, and to the people who worked very hard to bring Java where it is today. So the key discussion I want to raise is: does OpenJDK need to focus on more functionality, or on more portability that will allow it to be embraced by more developers and environments. [1] https://www.linkedin.com/pulse/future-java-its-close [2] https://www.slideshare.net/StevePoole/java-in-the-21st-century-are-you-thinking-far-enough-ahead [3] https://medium.com/@karpathy/software-2-0-a64152b37c35 [4] https://gluonhq.com/java-ai-mobile-and-cloud/ [5] https://github.com/gluonhq/strange [6] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018302.html From martijnverburg at gmail.com Tue Jul 10 09:45:29 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 10 Jul 2018 10:45:29 +0100 Subject: Workshop Discussion Proposals from Adoption Group / LJC In-Reply-To: References: Message-ID: Hi all, Was wondering if there was any feedback on these proposals (and the others on this list). Cheers, Martijn On Wed, 4 Jul 2018 at 16:47, Martijn Verburg wrote: > Hi all, > > I'm still wrangling schedules to try and get to the workshop but I thought > I'd share these anyhow. > > > > > > > > > > > > > > > > > > > > > > > *AdoptOpenJDK Build Farm 1. We would like to discuss some small changes to > source control practices at OpenJDK to make life easier for builders of > OpenJDK. In particular we'd like to get agreement on specific release tags > so OpenJDK builders can match Oracle's OpenJDK quarterly and CPU releases. > 2. The AdoptOpenJDK build farm infrastructure as code includes build > scripts, installers, container support, test scripts / suites and JCK > utilities (for those who are JCK signatories). How can we make this easier > either technically or process wise for folks so that all vendors / parties > can benefit from this shared resource? An ideal outcome here is that all > vendors can save time and effort on build and test of OpenJDK (no one > competes on build / farms) and end users have openly audited, consistent > OpenJDK binaries. 3. The AdoptOpenJDK build farm hosts are intended for use > by all vendors / interested parties (within reason). How can we make this > easier either technically or process wise for folks? Some benefits include > being able to better support Java's WORA promise across more ports (AIX, > Zos, Arm 32/64, Win32, z390 et al) and to disseminate and test early > binaries of builds coming out of amber, valhalla etc. 1. The AdoptOpenJDK > build farm team would like to discuss OpenJDK (LTS) patch maintenance (once > public updates by Oracle cease for an LTS release). An ideal outcome would > be to have clear identification of security and stability patches so that > other OpenJDK vendors can back port for their own implementations.Adoption > Group 1. The Adoption Group has been going for awhile and has had some > success, but not the impact it would have liked. We'd like to discuss the > outstanding barriers that developers wanting to contribute to OpenJDK face > today so that we can improve the number and velocity of newcomers to > OpenJDK. 2. We'd like to discuss the current state of Java 9+ adoption in > production and what changes OpenJDK may need to make in order to improve > that in order to reduce the length of time that the industry stays on Java > 8.OpenJDK Roadmap 1. We'd like to discuss the OpenJDK strategic roadmap, > for example is Cloud / Container support the top priority for the next 6 > releases? It would be interesting to discuss how that Roadmap could be > visualised with JEP's fulfilling the various goals. 1. We'd like to discuss > the OpenJDK roadmap specifically around:1. Value Types and related work2. > Safer replacements for functionality in sun.misc.Unsafe 3. GPU support / > Support for ML specific hardware4. Java Packager5. FFI6. Improvements to > Jigsaw These topics in particular are 'future' items that various LJC > developers have stated are of most interest to their businesses. 1. We'd > like to discuss OpenJDK jdk8u maintenance once public updates by Oracle > cease. An ideal outcome would be to find maintainer(s) going forwards.* > Questions, comments etc all welcome. > > Cheers, > Martijn > From aph at redhat.com Tue Jul 10 13:22:30 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 10 Jul 2018 14:22:30 +0100 Subject: Workshop Discussion Proposals from Adoption Group / LJC In-Reply-To: References: Message-ID: <2a110845-85a4-c13a-2ec9-0b28e415d527@redhat.com> On 07/10/2018 10:45 AM, Martijn Verburg wrote: > Was wondering if there was any feedback on these proposals (and the others > on this list). Dunno. The formatting is so awful that it's unreadable. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martijnverburg at gmail.com Tue Jul 10 14:14:43 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 10 Jul 2018 15:14:43 +0100 Subject: Workshop Discussion Proposals from Adoption Group / LJC In-Reply-To: <2a110845-85a4-c13a-2ec9-0b28e415d527@redhat.com> References: <2a110845-85a4-c13a-2ec9-0b28e415d527@redhat.com> Message-ID: That's weird. I assume you're on a text only client? Here it is again: AdoptOpenJDK Build Farm: ------------------------------------ 1. We would like to discuss some small changes to source control practices at OpenJDK to make life easier for builders of OpenJDK. In particular we'd like to get agreement on specific release tags so OpenJDK builders can match Oracle's OpenJDK quarterly and CPU releases. 2. The AdoptOpenJDK build farm infrastructure as code includes build scripts, installers, container support, test scripts / suites and JCK utilities (for those who are JCK signatories). How can we make this easier either technically or process wise for folks so that all vendors / parties can benefit from this shared resource? An ideal outcome here is that all vendors can save time and effort on build and test of OpenJDK (no one competes on build / farms) and end users have openly audited, consistent OpenJDK binaries. 3. The AdoptOpenJDK build farm hosts are intended for use by all vendors / interested parties (within reason). How can we make this easier either technically or process wise for folks? Some benefits include being able to better support Java's WORA promise across more ports (AIX, Zos, Arm 32/64, Win32, z390 et al) and to disseminate and test early binaries of builds coming out of amber, valhalla etc. 4. The AdoptOpenJDK build farm team would like to discuss OpenJDK (LTS) patch maintenance (once public updates by Oracle cease for an LTS release). An ideal outcome would be to have clear identification of security and stability patches so that other OpenJDK vendors can back port for their own implementations. Adoption Group: ----------------------- 1. The Adoption Group has been going for awhile and has had some success, but not the impact it would have liked. We'd like to discuss the outstanding barriers that developers wanting to contribute to OpenJDK face today so that we can improve the number and velocity of newcomers to OpenJDK. 2. We'd like to discuss the current state of Java 9+ adoption in production and what changes OpenJDK may need to make in order to improve that in order to reduce the length of time that the industry stays on Java 8. OpenJDK Roadmap: --------------------------- 1. We'd like to discuss the OpenJDK strategic roadmap, for example is Cloud / Container support the top priority for the next 6 releases? It would be interesting to discuss how that Roadmap could be visualised with JEP's fulfilling the various goals. 2. We'd like to discuss the OpenJDK roadmap specifically around: * Value Types and related work * Safer replacements for functionality in sun.misc.Unsafe * GPU support / Support for ML specific hardware * Java Packager * FFI * Improvements to Jigsaw These topics in particular are 'future' items that various LJC developers have stated are of most interest to their businesses. 3. We'd like to discuss OpenJDK jdk8u maintenance once public updates by Oracle cease. An ideal outcome would be to find maintainer(s) going forwards. Cheers, Martijn On Tue, 10 Jul 2018 at 14:22, Andrew Haley wrote: > On 07/10/2018 10:45 AM, Martijn Verburg wrote: > > Was wondering if there was any feedback on these proposals (and the > others > > on this list). > > Dunno. The formatting is so awful that it's unreadable. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From johan.vos at gluonhq.com Sat Jul 14 10:12:21 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 14 Jul 2018 12:12:21 +0200 Subject: Workshop proposal: loading native code from modules Message-ID: The Java SDK has always been distributed as an SDK that resides on a host filesystem and it contains a directory and a number of subdirectories. Inside those directories, platform-specific native libraries are located, e.g. containing the implementations for native functions. This model works fine for the core Java SDK with the core classes, as it can be assumed the user will download and install the SDK including the platform-specific native libraries. However, there is an increasing amount of downloadable software that may also contain platform-specific native implementations of some code: * more software is created that leverages platform (OS/arch/.../CPU/GPU/...) specific functionalities * components that are removed from the core Java SDK that contain native code (e.g. OpenJFX) * code that is (partially) be compiled using an AOT. Unless those projects all provide SDK's that are happily downloaded by the end user, one can not rely on the fact that the native libraries are 1) on the device file system and 2) on the LD_LIBRARY_PATH. In order to fix this, a number of projects use different approaches to deal with loading native code that is provided (typically as a resource) inside a jar file. In OpenJFX, we are adding some functionality to the NativeLibLoader ( https://github.com/johanvos/openjdk-jfx/blob/nativelibs/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L192 ) There is a project at github that deals with this more general: https://github.com/bytedeco/javacpp Given the fact that there are more and more use cases for this scenario (where native code is not on the filesystem, but inside a jar or a module), I think it would be beneficial to think about best practices, and hopefully a standard approach. From martijnverburg at gmail.com Wed Jul 18 13:45:18 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 18 Jul 2018 14:45:18 +0100 Subject: Workshop Discussion Proposals from Adoption Group / LJC In-Reply-To: References: <2a110845-85a4-c13a-2ec9-0b28e415d527@redhat.com> Message-ID: Hi All, I have and update to the OpenJDK 8u and 11u maintenance topic below. Apologies for not using the proper Workshop topic: or Workshop proposal: titles to split all of these suggestions out. I won't be able to personally attend so please treat the list below as Workshop topic: items. AdoptOpenJDK Build Farm: > ------------------------------------ > > 1. We would like to discuss some small changes to source control > practices at OpenJDK to make life easier for builders of OpenJDK. In > particular we'd like to get agreement on specific release tags so OpenJDK > builders can match Oracle's OpenJDK quarterly and CPU releases. > > 2. The AdoptOpenJDK build farm infrastructure as code includes build > scripts, installers, container support, test scripts / suites and JCK > utilities (for those who are JCK signatories). How can we make this easier > either technically or process wise for folks so that all vendors / parties > can benefit from this shared resource? An ideal outcome here is that all > vendors can save time and effort on build and test of OpenJDK (no one > competes on build / farms) and end users have openly audited, consistent > OpenJDK binaries. > > 3. The AdoptOpenJDK build farm hosts are intended for use by all vendors > / interested parties (within reason). How can we make this easier either > technically or process wise for folks? Some benefits include being able to > better support Java's WORA promise across more ports (AIX, Zos, Arm 32/64, > Win32, z390 et al) and to disseminate and test early binaries of builds > coming out of amber, valhalla etc. > > 4. The AdoptOpenJDK build farm team would like to discuss OpenJDK (LTS) > patch maintenance (once public updates by Oracle cease for an LTS release). > An ideal outcome would be to have clear identification of security and > stability patches so that other OpenJDK vendors can back port for their own > implementations. > > Adoption Group: > ----------------------- > > 1. The Adoption Group has been going for awhile and has had some success, > but not the impact it would have liked. We'd like to discuss the > outstanding barriers that developers wanting to contribute to OpenJDK face > today so that we can improve the number and velocity of newcomers to > OpenJDK. > 2. We'd like to discuss the current state of Java 9+ adoption in > production and what changes OpenJDK may need to make in order to improve > that in order to reduce the length of time that the industry stays on Java > 8. > > OpenJDK Roadmap: > --------------------------- > > 1. We'd like to discuss the OpenJDK strategic roadmap, for example is > Cloud / Container support the top priority for the next 6 releases? It > would be interesting to discuss how that Roadmap could be visualised with > JEP's fulfilling the various goals. > > 2. We'd like to discuss the OpenJDK roadmap specifically around: > * Value Types and related work > * Safer replacements for functionality in sun.misc.Unsafe > * GPU support / Support for ML specific hardware > * Java Packager > * FFI > * Improvements to Jigsaw > > These topics in particular are 'future' items that various LJC developers > have stated are of most interest to their businesses. > > 3. We'd like to discuss OpenJDK jdk8u maintenance once public updates by > Oracle cease. An ideal outcome would be to find maintainer(s) going > forwards. > 4. We'd like to discuss OpenJDK jdk11u maintenance once public updates by Oracle cease. An ideal outcome would be to find maintainer(s) going forwards. I think it would be interesting to explore a shared / collaborative approach to maintaining 8u and 11u as opposed to placing the burden on a particular vendor. If Oracle prefer to have a single vendor lead the maintenance of 8u and 11u we could still explore working in a unified manner behind that official maintainer. Assuming new maintainers will lead 8u updates after 2019 and 11u updates (after 6 months post GA release) then a question for me is how we can work with Oracle to identify patches that a 8u and/or 11u maintainer should back port (in particular security and stability patches). I suspect we all share a concern around the possibility of a proliferation of OpenJDK LTS releases by individual vendors, none of which are alike. One technical challenge is putting patches through a shared build and test pipeline to support the full range of architectures and variants out there today. That hurdle can be mitigated by using the Adopt build farm. Ideally all source code work would occur in OpenJDK update projects and Adopt would just build and test the results of that. Cheers, > Martijn > > > On Tue, 10 Jul 2018 at 14:22, Andrew Haley wrote: > >> On 07/10/2018 10:45 AM, Martijn Verburg wrote: >> > Was wondering if there was any feedback on these proposals (and the >> others >> > on this list). >> >> Dunno. The formatting is so awful that it's unreadable. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> > From aph at redhat.com Thu Jul 19 09:12:47 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Jul 2018 10:12:47 +0100 Subject: Discussion proposal: Who the heck is in charge, anyway? Message-ID: This topic is related to some of the things others have been saying, but is broader. Despite being on on the OpenJDK Governing Board and the Java SE expert group, it's still not clear to me who is guiding the development of the Java platform. Some of the possible candidates are: The JCP executive The OpenJDK Java SE project lead The JCP Java SE expert group A few influential and knowledgeable individuals JCP: Various JSR contributors OpenJDK: Various JEP contributors Closed discussion groups within Oracle and elsewhere All of the voters on mail.openjdk.java.net The JCP Java SE expert group doesn't really have the ability to guide anything because all it can do is reject proposals, and by then it is much too late: everything has already been integrated, and to reject anything would cause huge disruption. JEPs have a fairly low barrier to creation, and although there is a higher bar for targeting, it's not clear to me that there is an overall design for the API: changes are adopted piecemeal as they arrive. In a sense this is the free software way: the people who do the work get to decide what work gets done. Historically, this has seemed to work a lot better than one might reasonably expect, because by and large people want to co-operate, so they do. However, there is a considerable risk to OpenJDK contributors. It's quite possible that a JEP might be accepted, a substantial amount of work done, and then the work blocked at the targeting stage, with a contributor left in limbo. So, I'd like to discuss the decision-making structure we have, hopefully find out a bit more about how it's supposed to work, and think about whether it's the structure we need to go forward. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martijnverburg at gmail.com Thu Jul 19 10:08:58 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 19 Jul 2018 11:08:58 +0100 Subject: Discussion proposal: Who the heck is in charge, anyway? In-Reply-To: References: Message-ID: Andrew has put this far better than I ever could have. We'd also love to see this discussion. Slight side tangent - having a more transparent roadmap (as Oracle sees it) will also help other OpenJDK contributors not unnecessarily duplicate work, be able to assist on JEPs lead by others and add complimentary features. The recent collaboration over the GC interface and various implementations is a great example of how that can work. Cheers, Martijn On Thu, 19 Jul 2018 at 10:13, Andrew Haley wrote: > This topic is related to some of the things others have been saying, > but is broader. > > Despite being on on the OpenJDK Governing Board and the Java SE expert > group, it's still not clear to me who is guiding the development of > the Java platform. Some of the possible candidates are: > > The JCP executive > The OpenJDK Java SE project lead > The JCP Java SE expert group > A few influential and knowledgeable individuals > JCP: Various JSR contributors > OpenJDK: Various JEP contributors > Closed discussion groups within Oracle and elsewhere > All of the voters on mail.openjdk.java.net > > The JCP Java SE expert group doesn't really have the ability to guide > anything because all it can do is reject proposals, and by then it is > much too late: everything has already been integrated, and to reject > anything would cause huge disruption. JEPs have a fairly low barrier > to creation, and although there is a higher bar for targeting, it's > not clear to me that there is an overall design for the API: changes > are adopted piecemeal as they arrive. > > In a sense this is the free software way: the people who do the work > get to decide what work gets done. Historically, this has seemed to > work a lot better than one might reasonably expect, because by and > large people want to co-operate, so they do. > > However, there is a considerable risk to OpenJDK contributors. It's > quite possible that a JEP might be accepted, a substantial amount of > work done, and then the work blocked at the targeting stage, with a > contributor left in limbo. > > So, I'd like to discuss the decision-making structure we have, > hopefully find out a bit more about how it's supposed to work, and > think about whether it's the structure we need to go forward. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From mark.reinhold at oracle.com Fri Jul 20 23:15:30 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 20 Jul 2018 16:15:30 -0700 Subject: OpenJDK =?utf-8?Q?Committers=E2=80=99?= Workshop: Session proposals and topic suggestions so far Message-ID: <20180720161530.609714360@eggemoggin.niobe.net> Thanks to those who?ve already sent session proposals and topic suggestions in the requested format. I?ve listed them on the main Workshop page: http://openjdk.java.net/workshop#unconference . I?ll update these lists as further proposals and suggestions are received. - Mark From samuel.audet at gmail.com Sun Jul 22 02:45:03 2018 From: samuel.audet at gmail.com (Samuel Audet) Date: Sun, 22 Jul 2018 11:45:03 +0900 Subject: Workshop proposal: loading native code from modules Message-ID: As the author of JavaCPP, I just want to point out that what I have in my mind is a bit wider than that, more information here: http://bytedeco.org/news/2018/07/17/bytedeco-as-distribution/ But I think a proper loader (even something as "simple" as Android always had) would be a good way to start getting the Java community on board, and have people understand the importance of good interop with native libraries, including Project Panama, which isn't currently or planning to work on anything that appears useful for mobile or AI (speaking for Skymind here). This is the kind of thing best discussed in person, if anyone over there wants to discuss that is, but for personal reasons I can't attend the workshop, so please don't consider my absence as a lack of interest! Samuel From martijnverburg at gmail.com Sun Jul 22 21:08:23 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 22 Jul 2018 22:08:23 +0100 Subject: Workshop topic: Utilising the AdoptOpenJDK Build Farm Message-ID: Hi all, Splitting my previous mail into proper topics. Here's the first one. The AdoptOpenJDK build farm infrastructure as code includes build scripts, installers, container support, test scripts / suites and JCK utilities (for those who are JCK signatories). 1. We would like to discuss some small changes to source control practices at OpenJDK to make life easier for builders of OpenJDK. In particular we'd like to get agreement on specific release tags so OpenJDK builders can match Oracle's OpenJDK quarterly and CPU releases. 2. How can we make the build farm easier technically or process wise for folks so that all vendors / parties can benefit from this shared resource? An ideal outcome here is that all vendors can save time and effort on build and test of OpenJDK (no one competes on build / farms) and end users have openly audited, consistent OpenJDK binaries. 3. The AdoptOpenJDK build farm hosts are intended for use by all vendors / interested parties (within reason). How can we make this easier either technically or process wise for folks? Some benefits include being able to better support Java's WORA promise across more ports (AIX, Zos, Arm 32/64, Win32, z390 et al) and to disseminate and test early binaries of builds coming out of amber, valhalla etc. Cheers, Martijn From martijnverburg at gmail.com Sun Jul 22 21:10:47 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 22 Jul 2018 22:10:47 +0100 Subject: Workshop topic: OpenJDK 8u and 11u Maintenance Collaboration Message-ID: Hi all 1. We'd like to discuss OpenJDK jdk8u maintenance once public updates by Oracle cease. An ideal outcome would be to find maintainer(s) going forwards. 2. We'd like to discuss OpenJDK jdk11u maintenance once public updates by Oracle cease. An ideal outcome would be to find maintainer(s) going forwards. An extra question for both of these is whether bugs identified as security or stability updates are clearly labelled so all OpenJDK vendors can back port the same set. Cheers, Martijn From martijnverburg at gmail.com Sun Jul 22 21:15:55 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 22 Jul 2018 22:15:55 +0100 Subject: Workshop topic: Improving 9+ deployment in production Message-ID: Hi all, We'd like to discuss the current state of Java 9+ adoption in production and what changes OpenJDK could make / supplemental migration and helper tools OpenJDK could provide in order to improve the adoption rate of 9+ in production. One project is already underway by the Adoption Group WRT to upgrading any lagging libraries and frameworks that are important to developers. Cheers, Martijn From t.p.ellison at gmail.com Mon Jul 23 10:40:50 2018 From: t.p.ellison at gmail.com (Tim Ellison) Date: Mon, 23 Jul 2018 11:40:50 +0100 Subject: Workshop topic: Utilising the AdoptOpenJDK Build Farm In-Reply-To: References: Message-ID: <9f9242a4-02f8-02cf-3fdd-b27d22f5a34b@gmail.com> Hi Martijn, As you know, I'm also interested in AdoptOpenJDK so would be happy to participate in this as a workshop topic. Regards, Tim On 22/07/2018 22:08, Martijn Verburg wrote: > Hi all, > > Splitting my previous mail into proper topics. Here's the first one. > > The AdoptOpenJDK build farm infrastructure as > code includes build scripts, > installers, container support, test scripts / suites and JCK utilities (for > those who are JCK signatories). > > 1. We would like to discuss some small changes to source control practices > at OpenJDK to make life easier for builders of OpenJDK. In particular we'd > like to get agreement on specific release tags > so OpenJDK builders can > match Oracle's OpenJDK quarterly and CPU releases. > > 2. How can we make the build farm easier technically or process wise for > folks so that all vendors / parties can benefit from this shared resource? > An ideal outcome here is that all vendors can save time and effort on build > and test of OpenJDK (no one competes on build / farms) and end users have > openly audited, consistent OpenJDK binaries. > > 3. The AdoptOpenJDK build farm hosts are intended for use by all vendors / > interested parties (within reason). How can we make this easier either > technically or process wise for folks? Some benefits include being able to > better support Java's WORA promise across more ports (AIX, Zos, Arm 32/64, > Win32, z390 et al) and to disseminate and test early binaries of builds > coming out of amber, valhalla etc. > > Cheers, > Martijn > From t.p.ellison at gmail.com Mon Jul 23 10:42:15 2018 From: t.p.ellison at gmail.com (Tim Ellison) Date: Mon, 23 Jul 2018 11:42:15 +0100 Subject: Workshop topic: OpenJDK 8u and 11u Maintenance Collaboration In-Reply-To: References: Message-ID: <2909b741-8492-11cf-c432-6a0a0920485b@gmail.com> Hi Martijn, Important topics for discussion, so I'm a strong +1 to these being on the programme, and I will participate. Regards, Tim On 22/07/2018 22:10, Martijn Verburg wrote: > Hi all > > 1. We'd like to discuss OpenJDK jdk8u maintenance once public updates by > Oracle cease. An ideal outcome would be to find maintainer(s) going > forwards. > > 2. We'd like to discuss OpenJDK jdk11u maintenance once public updates by > Oracle cease. An ideal outcome would be to find maintainer(s) going > forwards. > > An extra question for both of these is whether bugs identified as security > or stability updates are clearly labelled so all OpenJDK vendors can back > port the same set. > > Cheers, > Martijn > From t.p.ellison at gmail.com Mon Jul 23 10:48:08 2018 From: t.p.ellison at gmail.com (Tim Ellison) Date: Mon, 23 Jul 2018 11:48:08 +0100 Subject: Discussion proposal: Who the heck is in charge, anyway? In-Reply-To: References: Message-ID: <536c9ac4-1489-3d7f-f4c4-b834a0313739@gmail.com> Hi Andrew, Getting some clarity and better understanding of expectations here is important. I'd like to see this included in the workshop agenda and participate in the session too. Regards, Tim On 19/07/2018 10:12, Andrew Haley wrote: > This topic is related to some of the things others have been saying, > but is broader. > > Despite being on on the OpenJDK Governing Board and the Java SE expert > group, it's still not clear to me who is guiding the development of > the Java platform. Some of the possible candidates are: > > The JCP executive > The OpenJDK Java SE project lead > The JCP Java SE expert group > A few influential and knowledgeable individuals > JCP: Various JSR contributors > OpenJDK: Various JEP contributors > Closed discussion groups within Oracle and elsewhere > All of the voters on mail.openjdk.java.net > > The JCP Java SE expert group doesn't really have the ability to guide > anything because all it can do is reject proposals, and by then it is > much too late: everything has already been integrated, and to reject > anything would cause huge disruption. JEPs have a fairly low barrier > to creation, and although there is a higher bar for targeting, it's > not clear to me that there is an overall design for the API: changes > are adopted piecemeal as they arrive. > > In a sense this is the free software way: the people who do the work > get to decide what work gets done. Historically, this has seemed to > work a lot better than one might reasonably expect, because by and > large people want to co-operate, so they do. > > However, there is a considerable risk to OpenJDK contributors. It's > quite possible that a JEP might be accepted, a substantial amount of > work done, and then the work blocked at the targeting stage, with a > contributor left in limbo. > > So, I'd like to discuss the decision-making structure we have, > hopefully find out a bit more about how it's supposed to work, and > think about whether it's the structure we need to go forward. > From rramakrishna at twitter.com Mon Jul 23 22:40:09 2018 From: rramakrishna at twitter.com (Ramki Ramakrishna) Date: Mon, 23 Jul 2018 15:40:09 -0700 Subject: Workshop topic: OpenJDK 8u and 11u Maintenance Collaboration In-Reply-To: <2909b741-8492-11cf-c432-6a0a0920485b@gmail.com> References: <2909b741-8492-11cf-c432-6a0a0920485b@gmail.com> Message-ID: +1 On Mon, Jul 23, 2018 at 4:12 AM Tim Ellison wrote: > Hi Martijn, > > Important topics for discussion, so I'm a strong +1 to these being on > the programme, and I will participate. > > Regards, > Tim > > On 22/07/2018 22:10, Martijn Verburg wrote: > > Hi all > > > > 1. We'd like to discuss OpenJDK jdk8u maintenance once public updates by > > Oracle cease. An ideal outcome would be to find maintainer(s) going > > forwards. > > > > 2. We'd like to discuss OpenJDK jdk11u maintenance once public updates by > > Oracle cease. An ideal outcome would be to find maintainer(s) going > > forwards. > > > > An extra question for both of these is whether bugs identified as > security > > or stability updates are clearly labelled so all OpenJDK vendors can back > > port the same set. > > > > Cheers, > > Martijn > > > -- JVM Team, Infrastructure Engineering, Twitter (San Francisco) From rramakrishna at twitter.com Mon Jul 23 22:41:52 2018 From: rramakrishna at twitter.com (Ramki Ramakrishna) Date: Mon, 23 Jul 2018 15:41:52 -0700 Subject: Workshop topic: Utilising the AdoptOpenJDK Build Farm In-Reply-To: <9f9242a4-02f8-02cf-3fdd-b27d22f5a34b@gmail.com> References: <9f9242a4-02f8-02cf-3fdd-b27d22f5a34b@gmail.com> Message-ID: I'm very interested in this topic too. -- ramki On Mon, Jul 23, 2018 at 3:52 AM Tim Ellison wrote: > Hi Martijn, > > As you know, I'm also interested in AdoptOpenJDK so would be happy to > participate in this as a workshop topic. > > Regards, > Tim > > On 22/07/2018 22:08, Martijn Verburg wrote: > > Hi all, > > > > Splitting my previous mail into proper topics. Here's the first one. > > > > The AdoptOpenJDK build farm > infrastructure as > > code includes build scripts, > > installers, container support, test scripts / suites and JCK utilities > (for > > those who are JCK signatories). > > > > 1. We would like to discuss some small changes to source control > practices > > at OpenJDK to make life easier for builders of OpenJDK. In particular > we'd > > like to get agreement on specific release tags > > so OpenJDK builders > can > > match Oracle's OpenJDK quarterly and CPU releases. > > > > 2. How can we make the build farm easier technically or process wise for > > folks so that all vendors / parties can benefit from this shared > resource? > > An ideal outcome here is that all vendors can save time and effort on > build > > and test of OpenJDK (no one competes on build / farms) and end users have > > openly audited, consistent OpenJDK binaries. > > > > 3. The AdoptOpenJDK build farm hosts are intended for use by all vendors > / > > interested parties (within reason). How can we make this easier either > > technically or process wise for folks? Some benefits include being able > to > > better support Java's WORA promise across more ports (AIX, Zos, Arm > 32/64, > > Win32, z390 et al) and to disseminate and test early binaries of builds > > coming out of amber, valhalla etc. > > > > Cheers, > > Martijn > > > -- JVM Team, Infrastructure Engineering, Twitter (San Francisco) From johan.vos at gluonhq.com Sun Jul 29 22:05:20 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 29 Jul 2018 15:05:20 -0700 Subject: Workshop proposal: Java Packager Message-ID: Recently, a sandbox project has been created by Kevin Rushforth for a new Java Packager, replacing the current java(fx)packager that is part of the OpenJFX repository. Given the increased role of packaged software/applications, this is an important project. The initial discussion with information about the code location is here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html A follow-up is at http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054296.html There is an issue created for this at JBS: https://bugs.openjdk.java.net/browse/JDK-8200758 Based on the feedback on the mailinglist, this seems a topic that requires a longer brainstorm/discussion before it can be nailed down. - Johan