From christoph.dreis at freenet.de Fri Oct 2 15:20:13 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Fri, 02 Oct 2020 17:20:13 +0200 Subject: How to contribute after the move to GitHub? Message-ID: <90E9F9FD-7ACD-4263-8F89-64414D4C1275@freenet.de> Hi, after the move to GitHub I?m unsure how to contribute to the OpenJDK exactly. I?ve contributed before and I?m also familiar with GitHub, so that?s not that big of a topic, but the JDK specific flow isn't yet entirely clear to me - if there's any. The contributing sections[1] don?t seem to be updated (yet). Should one still discuss a potential change upfront via the respective mailing lists or is it okay to open a PR directly ? even without a tracked bug yet - which is then the center of the discussion? Given that I'm not a committer I'm also not sure how the sponsoring process has potentially changed. Any clarification is highly appreciated. Cheers, Christoph [1] - https://openjdk.java.net/contribute/ From sgehwolf at redhat.com Fri Oct 2 15:34:21 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 02 Oct 2020 17:34:21 +0200 Subject: How to contribute after the move to GitHub? In-Reply-To: <90E9F9FD-7ACD-4263-8F89-64414D4C1275@freenet.de> References: <90E9F9FD-7ACD-4263-8F89-64414D4C1275@freenet.de> Message-ID: Hi Christoph, On Fri, 2020-10-02 at 17:20 +0200, Christoph Dreis wrote: > Hi, > > after the move to GitHub I?m unsure how to contribute to the OpenJDK exactly. > > I?ve contributed before and I?m also familiar with GitHub, so that?s not that big of a topic, but the JDK specific flow isn't yet entirely clear to me - if there's any. > The contributing sections[1] don?t seem to be updated (yet). > > Should one still discuss a potential change upfront via the respective mailing lists or is it okay to open a PR directly ? even without a tracked bug yet - which is then the center of the discussion? > Given that I'm not a committer I'm also not sure how the sponsoring process has potentially changed. > > Any clarification is highly appreciated. This post to jdk-dev might be helpful: http://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004694.html Particularly this: https://wiki.openjdk.java.net/display/SKARA/#Skara-GettingStarted HTH. Thanks, Severin > [1] - https://openjdk.java.net/contribute/ > > > From piotr.tarsa at gmail.com Sat Oct 3 14:58:35 2020 From: piotr.tarsa at gmail.com (Piotr Tarsa) Date: Sat, 3 Oct 2020 16:58:35 +0200 Subject: Idea: guaranteed object-level immutability, like in JavaScript's Object.freeze() In-Reply-To: References: Message-ID: Thanks for your response. > The biggest problem is building a user model that answers questions like, ?when is it useful?? and ?who has privileges to freeze an object?? and ?what happens when there?s a mix of frozen and unfrozen objects in a workload?? And of course, ?are frozen objects the same type as their ordinary siblings, or somehow a different type?? There are no easy answers here, simply because any eventual design has to work well with millions of existing APIs and programs. I *do* think there are probably ?hard? answers out there. These are interesting questions. I'll try to answer them. > ?who has privileges to freeze an object?? That could probably be determined by the class of an object. Today we have class and class members access scopes (public, protected, package private and private) and the same could apply to freezing, i.e. there could be an class level annotation e.g. @AllowFreezing.PackagePrivate (also since Java 15 got Sealed Classes we could implement Sealed Freezing Permits). Access scopes are used to determine who can change object state so it seems sensible that it could extend also to freezing. There are special kinds of objects though - arrays. They don't have state management (encapsulation) built-in, i.e. one cannot subclass an array to add some checks on e.g. mutation or achieve that in other ways without wrapping that array in a wrapper object. Since they don't have encapsulation then at least creating a frozen copy of them should always be safe. Today we can clone any array we have a reference to, so making a frozen copy shouldn't introduce any additional risk. Making a frozen copy of an array should also be safe after introducing inline types from Project Valhalla. Inline types are immutable by design, so freezing doesn't affect them at all. > ?are frozen objects the same type as their ordinary siblings, or somehow a different type?? In the case of arrays I'm not sure. Sharing mutable arrays is risky as they don't have any encapsulation (mentioned previously) and also (because they are covariant) mutating then is unsafe in general case (mixing mutability with covariance can result in array store exceptions). Therefore they need to be handled with care anyway. OTOH there was a proposal (long time ago) to develop Arrays 2.0 for Java so if that introduces new syntax (or hierarchy of types) for arrays then there could be something new to describe frozen arrays. For other types of objects (i.e. the ones defined through classes) the answer is: definitely the same type. If the privileges for freezing an object are set on class level then freezing is an explicitly allowed (and thus managed) operation on a given type (assuming the access scopes allow freezing). > ?what happens when there?s a mix of frozen and unfrozen objects in a workload? If we have objects that are not arrays then freezing is controlled by objects' class so we need to look up the class contract to see when we can expect that object will be frozen or not. Even today we can emulate freezing easily (e.g. we can add a method MyClass.freeze() that would cause all setters or other mutators to throw an exception). If we have arrays then probably we should look up the contract of the source we've got the array from. If there's none then not only we're unsure whether the array is frozen but also we're unsure whether someone overwrites our changes to that array. In any case, without a contract we're in a bad situation. > ?when is it useful?? I've mentioned potential internal (JVM-level) performance improvements in the previous post, but we can leave them aside for now and focus on more mainstream things. Freezing arrays would reduce defensive copying and would make them more safe and thus (especially if frozen arrays have a separate type) more high level in perception. Right now several array-wrapping immutable collections or collection-like types do defensive copying when accepting or returning contents in arrays. For example code `new String(array)` always copies the array. There's no method `String.takeMyArrayWithoutCopyingIPromiseItsImmutable(array)`. Similarly when doing `myString.toCharArray` a new (copied) array is returned. There's no method `myString.asImmutableCharArray()` that would expose the array directly without defensive copying. Same thing goes for immutable collections libraries. They tend to always defensively copy the arrays they wrap since there's no guarantee of immutability. With frozen arrays we could have following code: ```java // builds new frozen array and wraps it var immutableArrayWrapperFromLibraryA = libraryA.ArrayWrapper.build(1, 2, 3); // O(1) operation, no defensive copy, still safe var exposedFrozenArray = immutableArrayWrapperFromLibraryA.exposeInnerArray(); // O(1) operation, no defensive copy, still safe var immutableArrayWrapperFromLibraryB = libraryB.ArrayWrapper.from(exposedFrozenArray); ``` We could go further and (when frozen arrays have a separate type) treat frozen arrays like any other immutable collection and safely pass them around unwrapped. Regards, Piotr wt., 29 wrz 2020 o 21:58 John Rose napisa?(a): > On Sep 29, 2020, at 11:30 AM, Piotr Tarsa wrote: > > > > ...Do you think freezing objects could make sense for Java? > > Short answer: Maybe, eventually. But not like JavaScript. > > You mention race conditions as a potential problem. One > way to manage that would be to tie the new object states to > the existing state transitions involving the synchronization > monitor. That opens up a large design conversation about > how to extend Java?s (rather antiquated) locking intrinsics > to support more kinds of anti-race design patterns. > > The biggest problem is building a user model that answers > questions like, ?when is it useful?? and ?who has privileges > to freeze an object?? and ?what happens when there?s a mix > of frozen and unfrozen objects in a workload?? And of course, > ?are frozen objects the same type as their ordinary siblings, > or somehow a different type?? There are no easy answers > here, simply because any eventual design has to work well > with millions of existing APIs and programs. I *do* think > there are probably ?hard? answers out there. > > Currently, Project Panama is experimenting with confinement > models for native (C-heap) data structures. We are learning a lot in > this exercise. When things settle down, I think we might > transfer some of our learnings across to Java heap data > structures. Note that confinement is a useful generalization > of freezing, because both confinement and freezing make > useful statements about who can and cannot modify an > object field. A confined field is mutable only by one (or > a limited set) of threads. A frozen field is mutable by > no threads at all. When passing mutable data between > threads, it is (arguably) useful to be able ?park? the data > in the confined-to-no-thread state while it is queued for > processing, having been originally confined-to-sender-thread > and eventually (after dequeueing) confined-to-receiver-thread > for further processing. Arguably. My point here is that, > not only does freezing all by itself raise difficult design > questions (as well as implementation questions which > are frankly easy by comparison), but freezing also raises > the question of ?what is the correct set of primitives > for race control?, since freezing is not a lone primitive, > but rather one of a set of possible ones. > > Another variation on the ?freeze? theme is lazy fields. > The JDK uses lazy evaluation internally in many places, > but the language does not provide all the ways we might > wish to express lazily evaluated fields. (So we?ve had to > invent off-label mechanisms like @Stable.) The point > of a lazy field is it starts out with no value and then > acquires its value at some use point, and freezes that > value at the same time. > > The generalization which covers all of these cases > (as well as today?s existing regular and final fields) is > being able to write stories about the mutability state of > a field, saying when it can be modified and by who, > and how the mutability state can be changed (if at all). > There are many possible such stories; I?ve identified > the ones which seems promising to me above. > > HTH > > ? John From james.laskey at oracle.com Mon Oct 5 18:11:07 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 5 Oct 2020 15:11:07 -0300 Subject: Resigning as OpenJDK Nashorn Project Lead Message-ID: <433322AD-67F5-4BB2-A727-1CCD7A452C95@oracle.com> I hereby resign as Nashorn Project Lead. Nashorn [1] started in 2010 as a small JavaScript prototype to fill in for the discontinued JavaFX compiler project [2] and as a testing ground for Java's "new" invoke dynamic instructions [3]. Though Nashorn became somewhat a niche tool, it found itself playing important roles in many important projects [4]. Nashorn was deprecated in JDK 11 [5] was removed from the OpenJDK in JDK 15 [6]. Moving forward, it is hoped that Nashorn may continue on as a standalone library in maven central. According to the bylaws, the lead of the sponsoring group (Vladimir Kozlov from the HotSpot group) needs to assign a new project lead [7]. I recommend the nomination of Attila Szegedi [8] for this role. Attila was a significant contributor to Nashorn, beginning with the introduction of the dynalink library[9], through to the introduction of optimistic typing. Nashorn will be in good hands. I can't recommend him enough. Thank you. -- JIm [1] http://openjdk.java.net/jeps/174 [2] https://www.infoworld.com/article/2077746/javafx-compiler-released.html [3] https://www.jcp.org/en/jsr/detail?id=292 [4] https://www.infoq.com/news/2015/01/nashorn-at-netflix/ [5] https://openjdk.java.net/jeps/335 [6] https://openjdk.java.net/jeps/372 [7] http://openjdk.java.net/bylaws#project-lead [8] https://github.com/szegedi [9] https://openjdk.java.net/jeps/276 From amitmishra.hcl at gmail.com Tue Oct 6 05:44:18 2020 From: amitmishra.hcl at gmail.com (Amit Mishra) Date: Tue, 6 Oct 2020 11:14:18 +0530 Subject: download link Message-ID: Hi, Do we have link to download java-11-openjdk-11.0.5.10-1.static.jdk.openjdkportable.x86_64 javac is present in this directory. Regards, Amit M. From christoph.dreis at freenet.de Tue Oct 6 10:17:51 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Tue, 06 Oct 2020 12:17:51 +0200 Subject: How to contribute after the move to GitHub? In-Reply-To: References: <90E9F9FD-7ACD-4263-8F89-64414D4C1275@freenet.de> Message-ID: Hi Severin, > Particularly this: > https://wiki.openjdk.java.net/display/SKARA/#Skara-GettingStarted thanks for the link, that answered some more questions, but one is still unclear to me. I've contributed before and signed the OCA back then, but the tooling doesn't recognize me as a contributor now [1]. It isn't really clear if I need to sign the OCA again - which seems weird - or if I fall into the "Author" category already that needs to open a JDK ticket - although I don't have a JDK account. How should I proceed? Thanks, Christoph [1] - https://github.com/openjdk/jdk/pull/510 From david.holmes at oracle.com Tue Oct 6 12:24:18 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Oct 2020 22:24:18 +1000 Subject: How to contribute after the move to GitHub? In-Reply-To: References: <90E9F9FD-7ACD-4263-8F89-64414D4C1275@freenet.de> Message-ID: Hi Christoph, On 6/10/2020 8:17 pm, Christoph Dreis wrote: > Hi Severin, > >> Particularly this: >> https://wiki.openjdk.java.net/display/SKARA/#Skara-GettingStarted > > thanks for the link, that answered some more questions, but one is still unclear to me. > > I've contributed before and signed the OCA back then, but the tooling doesn't recognize me as a contributor now [1]. > It isn't really clear if I need to sign the OCA again - which seems weird - or if I fall into the "Author" category already that needs to open a JDK ticket - although I don't have a JDK account. > > How should I proceed? Just add the comment /signed as directed. There's a one-time verification process that needs to be done. Cheers, David > Thanks, > Christoph > > [1] - https://github.com/openjdk/jdk/pull/510 > > > From dalibor.topic at oracle.com Tue Oct 6 15:18:47 2020 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 6 Oct 2020 17:18:47 +0200 Subject: How to contribute after the move to GitHub? In-Reply-To: References: <90E9F9FD-7ACD-4263-8F89-64414D4C1275@freenet.de> Message-ID: On 06.10.2020 12:17, Christoph Dreis wrote: > Hi Severin, > >> Particularly this: >> https://wiki.openjdk.java.net/display/SKARA/#Skara-GettingStarted > > thanks for the link, that answered some more questions, but one is still unclear to me. > > I've contributed before and signed the OCA back then, but the tooling doesn't recognize me as a contributor now [1]. > It isn't really clear if I need to sign the OCA again - which seems weird - or if I fall into the "Author" category already that needs to open a JDK ticket - although I don't have a JDK account. > > How should I proceed? You've got mail. ;) cheers, dalibor topic > > Thanks, > Christoph > > [1] - https://github.com/openjdk/jdk/pull/510 > > > -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From dbhole at redhat.com Tue Oct 6 20:22:04 2020 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 6 Oct 2020 16:22:04 -0400 Subject: download link In-Reply-To: References: Message-ID: <20201006202203.GE7292@redhat.com> * Amit Mishra [2020-10-06 01:45]: > Hi, > > Do we have link to download > java-11-openjdk-11.0.5.10-1.static.jdk.openjdkportable.x86_64 > > javac is present in this directory. > Hi Amit, That filename looks like it is a portable JDK download of the Red Hat OpenJDK build. It is available via the Red Hat Customer Portal if you are a Red Hat customer[1]. If you are not a Red Hat customer, you can download a portable OpenJDK 11 from AdoptOpenJDK[2,3]. 1: https://access.redhat.com/ 2: https://adoptopenjdk.net/index.html 3: https://adoptopenjdk.net/upstream.html Deepak > Regards, > Amit M. > From samuel_thomas at brown.edu Wed Oct 7 14:10:55 2020 From: samuel_thomas at brown.edu (Samuel Thomas) Date: Wed, 7 Oct 2020 10:10:55 -0400 Subject: Testing OpenJDK14 Hotspot Garbage Collection with GDB Message-ID: Hello, I am relatively new to working with the OpenJDK framework and am writing to seek help with a task. I am currently attempting to compile and run some of the garbage collection tests within the OpenJDK14 library. In particular, I am in ${HOME}/jdk14/test/hotspot/gtest/ and would like to run the gtestMain.cpp. However, I run into the issue of not having the header files available. I?ve copied them into this directory from other locations, but I am wondering a few questions in particular. 1) Is this the way in which these tests were to be performed, or did I miss something in the configuration of OpenJDK14? 2) What is the protocol for testing the Parallel GC application from the test repository? Even better would be if there is existing documentation for how to run these tests. I appreciate the help! Best, Sam Thomas From jesper.wilhelmsson at oracle.com Wed Oct 7 14:34:54 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 7 Oct 2020 16:34:54 +0200 Subject: Testing OpenJDK14 Hotspot Garbage Collection with GDB In-Reply-To: References: Message-ID: <1CE07DDD-63DF-445D-ABEC-78F56D98CCAD@oracle.com> Hi Sam There is a section about how to run tests in need of being written in the OpenJDK Developers' Guide. I'd like to provide this section in order to help you. Let's work off list to make sure the documentation gets updated with what you need. Cheers, /Jesper > On 7 Oct 2020, at 16:10, Samuel Thomas wrote: > > Hello, > > I am relatively new to working with the OpenJDK framework and am writing to seek help with a task. I am currently attempting to compile and run some of the garbage collection tests within the OpenJDK14 library. In particular, I am in > > ${HOME}/jdk14/test/hotspot/gtest/ > > and would like to run the gtestMain.cpp. However, I run into the issue of not having the header files available. I?ve copied them into this directory from other locations, but I am wondering a few questions in particular. > > 1) Is this the way in which these tests were to be performed, or did I miss something in the configuration of OpenJDK14? > > 2) What is the protocol for testing the Parallel GC application from the test repository? Even better would be if there is existing documentation for how to run these tests. > > I appreciate the help! > > Best, > Sam Thomas From fw at deneb.enyo.de Sun Oct 11 12:21:00 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 11 Oct 2020 14:21:00 +0200 Subject: core-libs-dev email delivery Message-ID: <878scdx8b7.fsf@mid.deneb.enyo.de> We used to have a problem where hotspot-dev mail did not get delivered to list subscribers. Is it possible that a similar issue now affects core-libs-dev? I don't receive mail on two separate mail accounts, with completely different infrastructure on my end. The last message I received is: From: Brian Goetz Subject: Re: 8251989: Unified Hex formatting and parsing utility To: Roger Riggs , core-libs-dev at openjdk.java.net Date: Mon, 28 Sep 2020 13:48:22 -0400 (1 week, 5 days, 18 hours ago) Message-ID: <2d6a44f3-a307-beba-deb7-48b26f7e1afa at oracle.com> I tried to resubscribe in case I got unsubscribed by accident, but I did not receive a confirmation message or the usual Mailman privacy alert for a second subscription attempt. From aph at redhat.com Sun Oct 11 12:57:38 2020 From: aph at redhat.com (Andrew Haley) Date: Sun, 11 Oct 2020 13:57:38 +0100 Subject: core-libs-dev email delivery In-Reply-To: <878scdx8b7.fsf@mid.deneb.enyo.de> References: <878scdx8b7.fsf@mid.deneb.enyo.de> Message-ID: <10dde48c-80d1-914c-86c5-a56c284c5d23@redhat.com> On 11/10/2020 13:21, Florian Weimer wrote: > We used to have a problem where hotspot-dev mail did not get delivered > to list subscribers. Is it possible that a similar issue now affects > core-libs-dev? I don't receive mail on two separate mail accounts, > with completely different infrastructure on my end. The last message > I received is: > > From: Brian Goetz > Subject: Re: 8251989: Unified Hex formatting and parsing utility > To: Roger Riggs , core-libs-dev at openjdk.java.net > Date: Mon, 28 Sep 2020 13:48:22 -0400 (1 week, 5 days, 18 hours ago) > Message-ID: <2d6a44f3-a307-beba-deb7-48b26f7e1afa at oracle.com> > > I tried to resubscribe in case I got unsubscribed by accident, but I > did not receive a confirmation message or the usual Mailman privacy > alert for a second subscription attempt. I had a similar problem last week, but it turned out the subscription reply had been filtered in an unexpected way. AFAIK the system is working. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From fw at deneb.enyo.de Sun Oct 11 13:57:15 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 11 Oct 2020 15:57:15 +0200 Subject: core-libs-dev email delivery In-Reply-To: <10dde48c-80d1-914c-86c5-a56c284c5d23@redhat.com> (Andrew Haley's message of "Sun, 11 Oct 2020 13:57:38 +0100") References: <878scdx8b7.fsf@mid.deneb.enyo.de> <10dde48c-80d1-914c-86c5-a56c284c5d23@redhat.com> Message-ID: <87o8l8x3us.fsf@mid.deneb.enyo.de> * Andrew Haley: > On 11/10/2020 13:21, Florian Weimer wrote: >> We used to have a problem where hotspot-dev mail did not get delivered >> to list subscribers. Is it possible that a similar issue now affects >> core-libs-dev? I don't receive mail on two separate mail accounts, >> with completely different infrastructure on my end. The last message >> I received is: >> >> From: Brian Goetz >> Subject: Re: 8251989: Unified Hex formatting and parsing utility >> To: Roger Riggs , core-libs-dev at openjdk.java.net >> Date: Mon, 28 Sep 2020 13:48:22 -0400 (1 week, 5 days, 18 hours ago) >> Message-ID: <2d6a44f3-a307-beba-deb7-48b26f7e1afa at oracle.com> >> >> I tried to resubscribe in case I got unsubscribed by accident, but I >> did not receive a confirmation message or the usual Mailman privacy >> alert for a second subscription attempt. > > I had a similar problem last week, but it turned out the subscription > reply had been filtered in an unexpected way. AFAIK the system is working. Hmm. My case seems to be different: I don't see any mail whatsoever involving core-libs-dev. For me, it's really like the other hotspot-dev issue. From sgehwolf at redhat.com Mon Oct 12 14:18:40 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 12 Oct 2020 16:18:40 +0200 Subject: core-libs-dev email delivery In-Reply-To: <87o8l8x3us.fsf@mid.deneb.enyo.de> References: <878scdx8b7.fsf@mid.deneb.enyo.de> <10dde48c-80d1-914c-86c5-a56c284c5d23@redhat.com> <87o8l8x3us.fsf@mid.deneb.enyo.de> Message-ID: Hi Florian, On Sun, 2020-10-11 at 15:57 +0200, Florian Weimer wrote: > * Andrew Haley: > > > On 11/10/2020 13:21, Florian Weimer wrote: > > > We used to have a problem where hotspot-dev mail did not get delivered > > > to list subscribers. Is it possible that a similar issue now affects > > > core-libs-dev? I don't receive mail on two separate mail accounts, > > > with completely different infrastructure on my end. The last message > > > I received is: > > > > > > From: Brian Goetz > > > Subject: Re: 8251989: Unified Hex formatting and parsing utility > > > To: Roger Riggs , core-libs-dev at openjdk.java.net > > > Date: Mon, 28 Sep 2020 13:48:22 -0400 (1 week, 5 days, 18 hours ago) > > > Message-ID: <2d6a44f3-a307-beba-deb7-48b26f7e1afa at oracle.com> > > > > > > I tried to resubscribe in case I got unsubscribed by accident, but I > > > did not receive a confirmation message or the usual Mailman privacy > > > alert for a second subscription attempt. > > > > I had a similar problem last week, but it turned out the subscription > > reply had been filtered in an unexpected way. AFAIK the system is working. > > Hmm. My case seems to be different: I don't see any mail whatsoever > involving core-libs-dev. For me, it's really like the other hotspot-dev > issue. I seem to have the same issue :-/ Thanks, Severin From thomas.stuefe at gmail.com Mon Oct 12 14:29:28 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Oct 2020 16:29:28 +0200 Subject: core-libs-dev email delivery In-Reply-To: References: <878scdx8b7.fsf@mid.deneb.enyo.de> <10dde48c-80d1-914c-86c5-a56c284c5d23@redhat.com> <87o8l8x3us.fsf@mid.deneb.enyo.de> Message-ID: Same here. Difficult to find mails which are not crossposted but only went to core-libs-dev. One example missing for me is: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/069454.html Cheers, Thomas On Mon, Oct 12, 2020 at 4:19 PM Severin Gehwolf wrote: > Hi Florian, > > On Sun, 2020-10-11 at 15:57 +0200, Florian Weimer wrote: > > * Andrew Haley: > > > > > On 11/10/2020 13:21, Florian Weimer wrote: > > > > We used to have a problem where hotspot-dev mail did not get > delivered > > > > to list subscribers. Is it possible that a similar issue now affects > > > > core-libs-dev? I don't receive mail on two separate mail accounts, > > > > with completely different infrastructure on my end. The last message > > > > I received is: > > > > > > > > From: Brian Goetz > > > > Subject: Re: 8251989: Unified Hex formatting and parsing utility > > > > To: Roger Riggs , > core-libs-dev at openjdk.java.net > > > > Date: Mon, 28 Sep 2020 13:48:22 -0400 (1 week, 5 days, 18 hours ago) > > > > Message-ID: <2d6a44f3-a307-beba-deb7-48b26f7e1afa at oracle.com> > > > > > > > > I tried to resubscribe in case I got unsubscribed by accident, but I > > > > did not receive a confirmation message or the usual Mailman privacy > > > > alert for a second subscription attempt. > > > > > > I had a similar problem last week, but it turned out the subscription > > > reply had been filtered in an unexpected way. AFAIK the system is > working. > > > > Hmm. My case seems to be different: I don't see any mail whatsoever > > involving core-libs-dev. For me, it's really like the other hotspot-dev > > issue. > > I seem to have the same issue :-/ > > Thanks, > Severin > > From aph at redhat.com Mon Oct 12 16:24:15 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 12 Oct 2020 17:24:15 +0100 Subject: core-libs-dev email delivery In-Reply-To: References: <878scdx8b7.fsf@mid.deneb.enyo.de> <10dde48c-80d1-914c-86c5-a56c284c5d23@redhat.com> <87o8l8x3us.fsf@mid.deneb.enyo.de> Message-ID: On 12/10/2020 15:29, Thomas St?fe wrote: > Difficult to find mails which are not crossposted but only went to > core-libs-dev. One example missing for me is: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/069454.html OK, so I don't have that one either. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From tim.bell at oracle.com Mon Oct 12 17:38:42 2020 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 12 Oct 2020 10:38:42 -0700 Subject: core-libs-dev email delivery (is broken for external subscribers) In-Reply-To: <878scdx8b7.fsf@mid.deneb.enyo.de> References: <878scdx8b7.fsf@mid.deneb.enyo.de> Message-ID: <1d35ad95-a21d-d0a7-57cf-f5d1f05913d5@oracle.com> On 2020-10-11 05:21, Florian Weimer wrote: > We used to have a problem where hotspot-dev mail did not get delivered > to list subscribers. Is it possible that a similar issue now affects > core-libs-dev? I don't receive mail on two separate mail accounts, > with completely different infrastructure on my end. I reproduced this issue with my external mailbox. My corporate internal mailbox receives core-libs-dev messages OK. This does appear to be a repeat of the earlier issue with hotspot-dev. I filed an internal problem report and I will escalate. Until this issue is resolved, the workaround is to keep an eye on the message archive at: https://mail.openjdk.java.net/pipermail/core-libs-dev/ Tim From thomas.stuefe at gmail.com Mon Oct 12 19:36:35 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Oct 2020 21:36:35 +0200 Subject: core-libs-dev email delivery (is broken for external subscribers) In-Reply-To: <1d35ad95-a21d-d0a7-57cf-f5d1f05913d5@oracle.com> References: <878scdx8b7.fsf@mid.deneb.enyo.de> <1d35ad95-a21d-d0a7-57cf-f5d1f05913d5@oracle.com> Message-ID: Thank you, Tim! On Mon 12. Oct 2020 at 19:38, Tim Bell wrote: > On 2020-10-11 05:21, Florian Weimer wrote: > > We used to have a problem where hotspot-dev mail did not get delivered > > to list subscribers. Is it possible that a similar issue now affects > > core-libs-dev? I don't receive mail on two separate mail accounts, > > with completely different infrastructure on my end. > > I reproduced this issue with my external mailbox. My corporate internal > mailbox receives core-libs-dev messages OK. > > This does appear to be a repeat of the earlier issue with hotspot-dev. > I filed an internal problem report and I will escalate. > > Until this issue is resolved, the workaround is to keep an eye on the > message archive at: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/ > > Tim > From fweimer at redhat.com Tue Oct 13 08:58:20 2020 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 13 Oct 2020 10:58:20 +0200 Subject: core-libs-dev email delivery (is broken for external subscribers) In-Reply-To: <1d35ad95-a21d-d0a7-57cf-f5d1f05913d5@oracle.com> (Tim Bell's message of "Mon, 12 Oct 2020 10:38:42 -0700") References: <878scdx8b7.fsf@mid.deneb.enyo.de> <1d35ad95-a21d-d0a7-57cf-f5d1f05913d5@oracle.com> Message-ID: <87eem2y02b.fsf@oldenburg2.str.redhat.com> * Tim Bell: > On 2020-10-11 05:21, Florian Weimer wrote: >> We used to have a problem where hotspot-dev mail did not get delivered >> to list subscribers. Is it possible that a similar issue now affects >> core-libs-dev? I don't receive mail on two separate mail accounts, >> with completely different infrastructure on my end. > > I reproduced this issue with my external mailbox. My corporate > internal mailbox receives core-libs-dev messages OK. > > This does appear to be a repeat of the earlier issue with > hotspot-dev. I filed an internal problem report and I will escalate. > > Until this issue is resolved, the workaround is to keep an eye on the > message archive at: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/ Thanks! FYI, jdk-dev seems to have the same issue. Would you please make sure that it is also covered by the ticket? Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill From piotr.tarsa at gmail.com Sat Oct 17 11:10:32 2020 From: piotr.tarsa at gmail.com (Piotr Tarsa) Date: Sat, 17 Oct 2020 13:10:32 +0200 Subject: Idea: guaranteed object-level immutability, like in JavaScript's Object.freeze() In-Reply-To: References: Message-ID: Hello again :) Recently I've found an interesting case of sharing pseudo-frozen arrays in JDK itself. First let me repeat the email fragment about usefulness of frozen arrays: > ?when is it useful?? > I've mentioned potential internal (JVM-level) performance improvements in > the previous post, but we can leave them aside for now and focus on more > mainstream things. > Freezing arrays would reduce defensive copying and would make them more > safe and thus (especially if frozen arrays have a separate type) more high > level in perception. Right now several array-wrapping immutable collections > or collection-like types do defensive copying when accepting or returning > contents in arrays. For example code `new String(array)` always copies the > array. There's no method > `String.takeMyArrayWithoutCopyingIPromiseItsImmutable(array)`. Similarly > when doing `myString.toCharArray` a new (copied) array is returned. There's > no method `myString.asImmutableCharArray()` that would expose the array > directly without defensive copying. Same thing goes for immutable > collections libraries. They tend to always defensively copy the arrays they > wrap since there's no guarantee of immutability. With frozen arrays we > could have following code: > ```java > // builds new frozen array and wraps it > var immutableArrayWrapperFromLibraryA = > libraryA.ArrayWrapper.build(1, 2, 3); > // O(1) operation, no defensive copy, still safe > var exposedFrozenArray = > immutableArrayWrapperFromLibraryA.exposeInnerArray(); > // O(1) operation, no defensive copy, still safe > var immutableArrayWrapperFromLibraryB = > libraryB.ArrayWrapper.from(exposedFrozenArray); > ``` > We could go further and (when frozen arrays have a separate type) treat > frozen arrays like any other immutable collection and safely pass them > around unwrapped. The thing I've found in JDK is https://bugs.openjdk.java.net/browse/JDK-8156071 and then https://bugs.openjdk.java.net/browse/JDK-8254090 (probably there are more examples, but I wasn't digging). There is a tricky and fragile machinery dedicated to sharing "effectively frozen" arrays (called "shared secrets" IIUC) inside the Java collections library. With explicitly frozen arrays such machinery wouldn't be needed. Instead collections could just check (in factory methods) if an input array is frozen and then share it instead of doing defensive copy or throwing exceptions (like in the second linked OpenJDK issue). That would be safer, easier and more general (it seems to me that "shared secrets" work for a few select helper methods inside JDK, they aren't a general mechanism). Regards, Piotr sob., 3 pa? 2020 o 16:58 Piotr Tarsa napisa?(a): > Thanks for your response. > > > The biggest problem is building a user model that answers > questions like, ?when is it useful?? and ?who has privileges > to freeze an object?? and ?what happens when there?s a mix > of frozen and unfrozen objects in a workload?? And of course, > ?are frozen objects the same type as their ordinary siblings, > or somehow a different type?? There are no easy answers > here, simply because any eventual design has to work well > with millions of existing APIs and programs. I *do* think > there are probably ?hard? answers out there. > > These are interesting questions. I'll try to answer them. > > > ?who has privileges to freeze an object?? > > That could probably be determined by the class of an object. Today we have > class and class members access scopes (public, protected, package private > and private) and the same could apply to freezing, i.e. there could be an > class level annotation e.g. @AllowFreezing.PackagePrivate (also since Java > 15 got Sealed Classes we could implement Sealed Freezing Permits). Access > scopes are used to determine who can change object state so it seems > sensible that it could extend also to freezing. > > There are special kinds of objects though - arrays. They don't have state > management (encapsulation) built-in, i.e. one cannot subclass an array to > add some checks on e.g. mutation or achieve that in other ways without > wrapping that array in a wrapper object. Since they don't have > encapsulation then at least creating a frozen copy of them should always be > safe. Today we can clone any array we have a reference to, so making a > frozen copy shouldn't introduce any additional risk. Making a frozen copy > of an array should also be safe after introducing inline types from Project > Valhalla. Inline types are immutable by design, so freezing doesn't affect > them at all. > > > ?are frozen objects the same type as their ordinary siblings, or somehow > a different type?? > > In the case of arrays I'm not sure. Sharing mutable arrays is risky as > they don't have any encapsulation (mentioned previously) and also (because > they are covariant) mutating then is unsafe in general case (mixing > mutability with covariance can result in array store exceptions). Therefore > they need to be handled with care anyway. OTOH there was a proposal (long > time ago) to develop Arrays 2.0 for Java so if that introduces new syntax > (or hierarchy of types) for arrays then there could be something new to > describe frozen arrays. > > For other types of objects (i.e. the ones defined through classes) the > answer is: definitely the same type. If the privileges for freezing an > object are set on class level then freezing is an explicitly allowed (and > thus managed) operation on a given type (assuming the access scopes allow > freezing). > > > ?what happens when there?s a mix of frozen and unfrozen objects in a > workload? > > If we have objects that are not arrays then freezing is controlled by > objects' class so we need to look up the class contract to see when we can > expect that object will be frozen or not. Even today we can emulate > freezing easily (e.g. we can add a method MyClass.freeze() that would cause > all setters or other mutators to throw an exception). > > If we have arrays then probably we should look up the contract of the > source we've got the array from. If there's none then not only we're unsure > whether the array is frozen but also we're unsure whether someone > overwrites our changes to that array. In any case, without a contract we're > in a bad situation. > > > ?when is it useful?? > > I've mentioned potential internal (JVM-level) performance improvements in > the previous post, but we can leave them aside for now and focus on more > mainstream things. > > Freezing arrays would reduce defensive copying and would make them more > safe and thus (especially if frozen arrays have a separate type) more high > level in perception. Right now several array-wrapping immutable collections > or collection-like types do defensive copying when accepting or returning > contents in arrays. For example code `new String(array)` always copies the > array. There's no method > `String.takeMyArrayWithoutCopyingIPromiseItsImmutable(array)`. Similarly > when doing `myString.toCharArray` a new (copied) array is returned. There's > no method `myString.asImmutableCharArray()` that would expose the array > directly without defensive copying. Same thing goes for immutable > collections libraries. They tend to always defensively copy the arrays they > wrap since there's no guarantee of immutability. With frozen arrays we > could have following code: > ```java > // builds new frozen array and wraps it > var immutableArrayWrapperFromLibraryA = > libraryA.ArrayWrapper.build(1, 2, 3); > // O(1) operation, no defensive copy, still safe > var exposedFrozenArray = > immutableArrayWrapperFromLibraryA.exposeInnerArray(); > // O(1) operation, no defensive copy, still safe > var immutableArrayWrapperFromLibraryB = > libraryB.ArrayWrapper.from(exposedFrozenArray); > ``` > We could go further and (when frozen arrays have a separate type) treat > frozen arrays like any other immutable collection and safely pass them > around unwrapped. > > > Regards, > Piotr > > wt., 29 wrz 2020 o 21:58 John Rose napisa?(a): > >> On Sep 29, 2020, at 11:30 AM, Piotr Tarsa wrote: >> > >> > ...Do you think freezing objects could make sense for Java? >> >> Short answer: Maybe, eventually. But not like JavaScript. >> >> You mention race conditions as a potential problem. One >> way to manage that would be to tie the new object states to >> the existing state transitions involving the synchronization >> monitor. That opens up a large design conversation about >> how to extend Java?s (rather antiquated) locking intrinsics >> to support more kinds of anti-race design patterns. >> >> The biggest problem is building a user model that answers >> questions like, ?when is it useful?? and ?who has privileges >> to freeze an object?? and ?what happens when there?s a mix >> of frozen and unfrozen objects in a workload?? And of course, >> ?are frozen objects the same type as their ordinary siblings, >> or somehow a different type?? There are no easy answers >> here, simply because any eventual design has to work well >> with millions of existing APIs and programs. I *do* think >> there are probably ?hard? answers out there. >> >> Currently, Project Panama is experimenting with confinement >> models for native (C-heap) data structures. We are learning a lot in >> this exercise. When things settle down, I think we might >> transfer some of our learnings across to Java heap data >> structures. Note that confinement is a useful generalization >> of freezing, because both confinement and freezing make >> useful statements about who can and cannot modify an >> object field. A confined field is mutable only by one (or >> a limited set) of threads. A frozen field is mutable by >> no threads at all. When passing mutable data between >> threads, it is (arguably) useful to be able ?park? the data >> in the confined-to-no-thread state while it is queued for >> processing, having been originally confined-to-sender-thread >> and eventually (after dequeueing) confined-to-receiver-thread >> for further processing. Arguably. My point here is that, >> not only does freezing all by itself raise difficult design >> questions (as well as implementation questions which >> are frankly easy by comparison), but freezing also raises >> the question of ?what is the correct set of primitives >> for race control?, since freezing is not a lone primitive, >> but rather one of a set of possible ones. >> >> Another variation on the ?freeze? theme is lazy fields. >> The JDK uses lazy evaluation internally in many places, >> but the language does not provide all the ways we might >> wish to express lazily evaluated fields. (So we?ve had to >> invent off-label mechanisms like @Stable.) The point >> of a lazy field is it starts out with no value and then >> acquires its value at some use point, and freezes that >> value at the same time. >> >> The generalization which covers all of these cases >> (as well as today?s existing regular and final fields) is >> being able to write stories about the mutability state of >> a field, saying when it can be modified and by who, >> and how the mutability state can be changed (if at all). >> There are many possible such stories; I?ve identified >> the ones which seems promising to me above. >> >> HTH >> >> ? John > > From linzang at tencent.com Tue Oct 20 07:19:41 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Tue, 20 Oct 2020 07:19:41 +0000 Subject: [openjdk bot] keep adding duplicated message in PR Message-ID: <2c15422c348ea10808fbc65d6012cb8b06e0575c.camel@tencent.com> Dear All, May I ask your help to tell is there anything I did wrong for updating a PR at https://github.com/openjdk/jdk/pull/25 on git? The "openjdk bot" keep adding same comments in this PR like following: ============================================================= Hi @openjdk[bot], thanks for making a comment in an OpenJDK project! All comments and discussions in the OpenJDK Community must be made available under the OpenJDK Terms of Use. If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please Use "Add GitHub user openjdk[bot] for the summary. If you are not an OpenJDK Author, Committer or Reviewer, simply check the box below to accept the OpenJDK Terms of Use for your comments. I agree to the OpenJDK Terms of Use for all comments I make in a project in the OpenJDK GitHub organization. Your comment will be automatically restored once you have accepted the OpenJDK Terms of Use. ========================================================= what should I do to stop this? Thanks for any kind of help. BRs, Lin From david.holmes at oracle.com Tue Oct 20 07:24:03 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Oct 2020 17:24:03 +1000 Subject: [openjdk bot] keep adding duplicated message in PR In-Reply-To: <2c15422c348ea10808fbc65d6012cb8b06e0575c.camel@tencent.com> References: <2c15422c348ea10808fbc65d6012cb8b06e0575c.camel@tencent.com> Message-ID: <43d7f4a5-5b34-0ffb-f766-7842121d4542@oracle.com> Hi Lin, We've noticed the bots talking to themselves as well and it has been reported internally. :) Cheers, David On 20/10/2020 5:19 pm, linzang(??) wrote: > Dear All, > May I ask your help to tell is there anything I did wrong for > updating a PR at https://github.com/openjdk/jdk/pull/25 on git? > The "openjdk bot" keep adding same comments in this PR like > following: > ============================================================= > Hi @openjdk[bot], thanks for making a comment in an OpenJDK project! > > All comments and discussions in the OpenJDK Community must be made > available under the OpenJDK Terms of Use. If you already are an OpenJDK > Author, Committer or Reviewer, please click here to open a new issue so > that we can record that fact. Please Use "Add GitHub user openjdk[bot] > for the summary. > > If you are not an OpenJDK Author, Committer or Reviewer, simply check > the box below to accept the OpenJDK Terms of Use for your comments. > > I agree to the OpenJDK Terms of Use for all comments I make in a > project in the OpenJDK GitHub organization. > Your comment will be automatically restored once you have accepted the > OpenJDK Terms of Use. > ========================================================= > > what should I do to stop this? > > Thanks for any kind of help. > > BRs, > Lin > From mbien42 at gmail.com Sat Oct 24 22:13:31 2020 From: mbien42 at gmail.com (Michael Bien) Date: Sun, 25 Oct 2020 00:13:31 +0200 Subject: Feedback after first Contribution Message-ID: <8604e05a-d1f3-bbdf-cbc7-7cbe34a4aee9@gmail.com> Hello, earlier this week I made my first contribution and wanted to leave some feedback from the POV of an external contributor. First let me explain what I did to get it integrated: Since the bugfix itself was trivial, I created a pull request right away (I signed the OCA before that) before discussing anything on a dev list, since I wanted to use the code as basis for the discussion. The bot (which is pretty cool) quickly pointed out that the PR didn't have an issue assigned to it. I figured the only way to get an issue for me would be to either ask on the mailing list or to paste the paragraphs of the PR into the small boxes of the bug report system, while linking back to the PR to make it clear that a fix exists. A week later i could prefix the PR with the issue ID which made the bot happy. At this point the first automated mail landed on the (correct) dev list which triggered the actual reviewing process - pretty cool. suggestions: 1) I feel there should be a faster path from a PR to a JBS issue. Maybe there could be a command which would let the bot generate a draft issue? Pasting the paragraphs into the customer bug form really felt like i was wasting someone's time knowing that the bug reviewer will probably try to reproduce the bug. 2) The guide should mention somewhere that the commits will get squashed in the end to a single commit using the issue as title. So that the contributor can just keep adding commits during the review process without having to bother with git push -f or a clean history. 3) The bot really didn't want to add me as a contributor :) There might be a bug somewhere: https://github.com/openjdk/jdk/pull/248#issuecomment-713021764 best regards, michael . . . https://mbien.dev From magnus.ihse.bursie at oracle.com Mon Oct 26 08:33:50 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 26 Oct 2020 09:33:50 +0100 Subject: Feedback after first Contribution In-Reply-To: <8604e05a-d1f3-bbdf-cbc7-7cbe34a4aee9@gmail.com> References: <8604e05a-d1f3-bbdf-cbc7-7cbe34a4aee9@gmail.com> Message-ID: <3c5ba41a-f043-0571-4451-09c41d947994@oracle.com> Hi Michael, On 2020-10-25 00:13, Michael Bien wrote: > Hello, > > earlier this week I made my first contribution and wanted to leave > some feedback from the POV of an external contributor. > > First let me explain what I did to get it integrated: > > Since the bugfix itself was trivial, I created a pull request right > away (I signed the OCA before that) before discussing anything on a > dev list, since I wanted to use the code as basis for the discussion. > > The bot (which is pretty cool) quickly pointed out that the PR didn't > have an issue assigned to it. I figured the only way to get an issue > for me would be to either ask on the mailing list or to paste the > paragraphs of the PR into the small boxes of the bug report system, > while linking back to the PR to make it clear that a fix exists. > > A week later i could prefix the PR with the issue ID which made the > bot happy. At this point the first automated mail landed on the > (correct) dev list which triggered the actual reviewing process - > pretty cool. > > suggestions: > > 1) I feel there should be a faster path from a PR to a JBS issue. > Maybe there could be a command which would let the bot generate a > draft issue? Pasting the paragraphs into the customer bug form really > felt like i was wasting someone's time knowing that the bug reviewer > will probably try to reproduce the bug. > > 2) The guide should mention somewhere that the commits will get > squashed in the end to a single commit using the issue as title. So > that the contributor can just keep adding commits during the review > process without having to bother with git push -f or a clean history. > > 3) The bot really didn't want to add me as a contributor :) There > might be a bug somewhere: > https://github.com/openjdk/jdk/pull/248#issuecomment-713021764 Thank you for reporting your experiences, in such a constructive tone. This is all very new to us, and there are certainly road bumps that need to be flattened. Some may be easy to fix, and other may be harder. But getting feedback about what's the pain points of a new contributor certainly helps us understand where there are work left to do. /Magnus > > best regards, > > michael > > . . . > > https://mbien.dev > > From mbien42 at gmail.com Mon Oct 26 13:55:41 2020 From: mbien42 at gmail.com (Michael Bien) Date: Mon, 26 Oct 2020 14:55:41 +0100 Subject: Feedback after first Contribution In-Reply-To: <3c5ba41a-f043-0571-4451-09c41d947994@oracle.com> References: <8604e05a-d1f3-bbdf-cbc7-7cbe34a4aee9@gmail.com> <3c5ba41a-f043-0571-4451-09c41d947994@oracle.com> Message-ID: <89b7a9ce-30ea-bcb8-eb9b-eb50da270fbc@gmail.com> On 26.10.20 09:33, Magnus Ihse Bursie wrote: > Hi Michael, > > On 2020-10-25 00:13, Michael Bien wrote: >> Hello, >> >> earlier this week I made my first contribution and wanted to leave >> some feedback from the POV of an external contributor. >> >> First let me explain what I did to get it integrated: >> >> Since the bugfix itself was trivial, I created a pull request right >> away (I signed the OCA before that) before discussing anything on a >> dev list, since I wanted to use the code as basis for the discussion. >> >> The bot (which is pretty cool) quickly pointed out that the PR didn't >> have an issue assigned to it. I figured the only way to get an issue >> for me would be to either ask on the mailing list or to paste the >> paragraphs of the PR into the small boxes of the bug report system, >> while linking back to the PR to make it clear that a fix exists. >> >> A week later i could prefix the PR with the issue ID which made the >> bot happy. At this point the first automated mail landed on the >> (correct) dev list which triggered the actual reviewing process - >> pretty cool. >> >> suggestions: >> >> 1) I feel there should be a faster path from a PR to a JBS issue. >> Maybe there could be a command which would let the bot generate a >> draft issue? Pasting the paragraphs into the customer bug form really >> felt like i was wasting someone's time knowing that the bug reviewer >> will probably try to reproduce the bug. >> >> 2) The guide should mention somewhere that the commits will get >> squashed in the end to a single commit using the issue as title. So >> that the contributor can just keep adding commits during the review >> process without having to bother with git push -f or a clean history. >> >> 3) The bot really didn't want to add me as a contributor :) There >> might be a bug somewhere: >> https://github.com/openjdk/jdk/pull/248#issuecomment-713021764 > Thank you for reporting your experiences, in such a constructive tone. > This is all very new to us, and there are certainly road bumps that > need to be flattened. Some may be easy to fix, and other may be > harder. But getting feedback about what's the pain points of a new > contributor certainly helps us understand where there are work left to > do. no problem :) -michael > > /Magnus >> >> best regards, >> >> michael >> >> . . . >> >> https://mbien.dev >> >> > From neugens.limasoftware at gmail.com Tue Oct 27 16:34:00 2020 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 27 Oct 2020 17:34:00 +0100 Subject: FOSDEM 2021 and Java DevRoom Message-ID: Hi all, I hope this email finds you well. As you probably know, the next edition of FOSDEM will be a fully online conference and the CFP is now open for the DevRoom to register and will close in just a couple of days. I've been thinking a lot about this, and I don't think the format suits us well. One of the most important aspects of the Java DevRoom is the face to face meetings and discussions that happen in the corridors and during the dinner, the content has a rather fair share of significance (otherwise we wouldn't do it!) of course, but the human contact the value of our DevRoom in particular (in a context as fantastic as FOSDEM) is what has made Java progress over the years, tied relationships and created new sources of discussion. There's of course also the aspect of helping the conference deliver great content, after all we have been part of FOSDEM for years, it wasn't just a place where to go for our own stuff detached from the rest, and for that I am grateful to the organisers. For this reason, rather than unilaterally decide about this and in the spirit of Open Source I would like some comments. For full transparency, I do think we should pass this round. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From neugens.limasoftware at gmail.com Thu Oct 29 14:51:50 2020 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 29 Oct 2020 15:51:50 +0100 Subject: FOSDEM 2021 and Java DevRoom In-Reply-To: <85CC6666-01AD-49D9-9E34-96C897190648@jfree.org> References: <85CC6666-01AD-49D9-9E34-96C897190648@jfree.org> Message-ID: Hi David, I have contrasting feelings here. I think if a real time communication setup is maintained where an exchange between public and presenters is possible then there may be some reason to do it, on the other hand it does feel like just adding a presentation on YouTube otherwise. From what I heard, the conference organisers are trying to implement a chat system but I don't really have many details. Sometimes I wonder if one shouldn't just use YouTube live event feature and have a rolling conference the whole year ;) Also, I'm not sure I have the strength to sit the whole weekend in front of a computer enabling such a conference with the kids around the house to be honest, but I'll be happy to help if there's willingness to do it and some other volunteers want to help organise it. Cheers, Mario Il giorno mar 27 ott 2020 alle ore 20:12 David Gilbert ha scritto: > > Hi Mario / All, > > I haven?t participated so much in FOSDEM the last few years, so discount my opinion appropriately? > > Perhaps this is an chance to make the best of a bad situation and use the virtual conference to try to bring in some people that wouldn?t otherwise have attended and/or presented. My suggestions: I would be interested to hear more from the people behind: > > - https://openjfx.io > - https://www.knime.com/ > > There?s fantastic work being done in these projects. I?m sure others know of great open source work being done on top of the Java platform. We could reach out and ask these people to present. > > Best regards, > > David > > > On 27 Oct 2020, at 17:34, Mario Torre wrote: > > > > Hi all, > > > > I hope this email finds you well. > > > > As you probably know, the next edition of FOSDEM will be a fully > > online conference and the CFP is now open for the DevRoom to register > > and will close in just a couple of days. > > > > I've been thinking a lot about this, and I don't think the format > > suits us well. One of the most important aspects of the Java DevRoom > > is the face to face meetings and discussions that happen in the > > corridors and during the dinner, the content has a rather fair share > > of significance (otherwise we wouldn't do it!) of course, but the > > human contact the value of our DevRoom in particular (in a context as > > fantastic as FOSDEM) is what has made Java progress over the years, > > tied relationships and created new sources of discussion. > > > > There's of course also the aspect of helping the conference deliver > > great content, after all we have been part of FOSDEM for years, it > > wasn't just a place where to go for our own stuff detached from the > > rest, and for that I am grateful to the organisers. > > > > For this reason, rather than unilaterally decide about this and in the > > spirit of Open Source I would like some comments. > > > > For full transparency, I do think we should pass this round. > > > > Cheers, > > Mario > > > > -- > > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > > Proud GNU Classpath developer: http://www.classpath.org/ > > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > > > Please, support open standards: > > http://endsoftpatents.org/ > > _______________________________________________ > > java-devroom mailing list > > java-devroom at lists.fosdem.org > > https://lists.fosdem.org/listinfo/java-devroom > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/