From duke at openjdk.org  Mon Feb  3 21:40:12 2025
From: duke at openjdk.org (Nicolai Parlog)
Date: Mon, 3 Feb 2025 21:40:12 GMT
Subject: [amber-docs] RFR: Update and restructure JEP list
Message-ID: <ht9mGRa1WvpeeJKMu1vxHGs2aOFbPBtJ0FQEIZdaDd4=.eb18d65b-6f0d-4b4c-963a-039b00367605@github.com>

Update and restructure JEP list

-------------

Commit messages:
 - Add JEP 458
 - Update and restructure JEP list

Changes: https://git.openjdk.org/amber-docs/pull/25/files
  Webrev: https://webrevs.openjdk.org/?repo=amber-docs&pr=25&range=00
  Stats: 22 lines in 1 file changed: 4 ins; 16 del; 2 mod
  Patch: https://git.openjdk.org/amber-docs/pull/25.diff
  Fetch: git fetch https://git.openjdk.org/amber-docs.git pull/25/head:pull/25

PR: https://git.openjdk.org/amber-docs/pull/25

From duke at openjdk.org  Tue Feb  4 15:43:59 2025
From: duke at openjdk.org (Nicolai Parlog)
Date: Tue, 4 Feb 2025 15:43:59 GMT
Subject: [amber-docs] RFR: Update and restructure JEP list [v2]
In-Reply-To: <ht9mGRa1WvpeeJKMu1vxHGs2aOFbPBtJ0FQEIZdaDd4=.eb18d65b-6f0d-4b4c-963a-039b00367605@github.com>
References: <ht9mGRa1WvpeeJKMu1vxHGs2aOFbPBtJ0FQEIZdaDd4=.eb18d65b-6f0d-4b4c-963a-039b00367605@github.com>
Message-ID: <wFUDqH64pACxEZx922m9XVboNRwsUpdiJCzX5fq_pRQ=.75da26e5-c03d-411a-9d6f-45f399ff3d31@github.com>

> Update and restructure JEP list

Nicolai Parlog has updated the pull request incrementally with one additional commit since the last revision:

  Add preview JEPs as list

-------------

Changes:
  - all: https://git.openjdk.org/amber-docs/pull/25/files
  - new: https://git.openjdk.org/amber-docs/pull/25/files/3d71700c..4c097611

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=amber-docs&pr=25&range=01
 - incr: https://webrevs.openjdk.org/?repo=amber-docs&pr=25&range=00-01

  Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/amber-docs/pull/25.diff
  Fetch: git fetch https://git.openjdk.org/amber-docs.git pull/25/head:pull/25

PR: https://git.openjdk.org/amber-docs/pull/25

From duke at openjdk.org  Tue Feb  4 15:43:59 2025
From: duke at openjdk.org (duke)
Date: Tue, 4 Feb 2025 15:43:59 GMT
Subject: [amber-docs] RFR: Update and restructure JEP list
In-Reply-To: <ht9mGRa1WvpeeJKMu1vxHGs2aOFbPBtJ0FQEIZdaDd4=.eb18d65b-6f0d-4b4c-963a-039b00367605@github.com>
References: <ht9mGRa1WvpeeJKMu1vxHGs2aOFbPBtJ0FQEIZdaDd4=.eb18d65b-6f0d-4b4c-963a-039b00367605@github.com>
Message-ID: <DSRzykjMEILqlFMLvptyrKxEHqOtzC3wil8VfwxqWWU=.de2ba329-ab57-4aea-83a7-f6d0cc2639ff@github.com>

On Mon, 3 Feb 2025 09:57:58 GMT, Nicolai Parlog <duke at openjdk.org> wrote:

> Update and restructure JEP list

@nipafx 
Your change (at version 4c097611005cd4834dc661a86fc98c39d5af6018) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/amber-docs/pull/25#issuecomment-2634350962

From duke at openjdk.org  Tue Feb  4 15:54:18 2025
From: duke at openjdk.org (Nicolai Parlog)
Date: Tue, 4 Feb 2025 15:54:18 GMT
Subject: [amber-docs] Integrated: Update and restructure JEP list
In-Reply-To: <ht9mGRa1WvpeeJKMu1vxHGs2aOFbPBtJ0FQEIZdaDd4=.eb18d65b-6f0d-4b4c-963a-039b00367605@github.com>
References: <ht9mGRa1WvpeeJKMu1vxHGs2aOFbPBtJ0FQEIZdaDd4=.eb18d65b-6f0d-4b4c-963a-039b00367605@github.com>
Message-ID: <cYPeDPwmynMPymp_Af-mtZz5dB8nvitfdohPOxb2KPQ=.2612727e-58ba-4943-b713-aafee97112e7@github.com>

On Mon, 3 Feb 2025 09:57:58 GMT, Nicolai Parlog <duke at openjdk.org> wrote:

> Update and restructure JEP list

This pull request has now been integrated.

Changeset: 138e8c99
Author:    Nicolai Parlog <nicolai at nipafx.dev>
Committer: Gavin Bierman <gbierman at openjdk.org>
URL:       https://git.openjdk.org/amber-docs/commit/138e8c994a8098f26c5333a90713970d9dc42a3c
Stats:     29 lines in 1 file changed: 0 ins; 12 del; 17 mod

Update and restructure JEP list

-------------

PR: https://git.openjdk.org/amber-docs/pull/25

From kfogel at dawsoncollege.qc.ca  Thu Feb  6 16:33:34 2025
From: kfogel at dawsoncollege.qc.ca (Kenneth Fogel)
Date: Thu, 6 Feb 2025 16:33:34 +0000
Subject: Import Question regarding modules
Message-ID: <QB1PPF5DAA3F587ED65FA507CE2A6B89D298DF62@QB1PPF5DAA3F587.CANPRD01.PROD.OUTLOOK.COM>

In preparing for a class tonight that will use the traditional class notation and not the compact (classless), I performed a simple experiment. I had a program that had:
import java.util.Scanner;
The final jar size was 6K.

I replace that import with:
import module java.base;
As expected, the jar for this version was the same size.

Knowing what to import has always been a pain point usually left up to the IDE to figure out. Using java.base allows you to use a text editor to write code and not concern the new student to Java with imports that can quickly become overwhelming if they want to use a collection or LocalDateTime and so on.

What are your thoughts? Was this one of the reasons for modules?

Ken

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250206/b27b3f2e/attachment-0001.htm>

From ekaterina.semenova at jetbrains.com  Mon Feb 10 14:30:14 2025
From: ekaterina.semenova at jetbrains.com (Ekaterina Semenova)
Date: Mon, 10 Feb 2025 16:30:14 +0200
Subject: JEP 492: javac error on a valid code
Message-ID: <CANuPR+MfSkfc_zwUGj5rTU3eGAbrhHSeWjGbWXqTzfoebkdTCA@mail.gmail.com>

Dear Experts,

I noticed that javac throws a compilation error on the following code using
a Java 24 preview feature (JEP 492 (flexible constructor body) :

```
class Outer { private int i; class Sub extends Outer { Sub() { i = 42; //
javac error: java: cannot reference i before supertype constructor has been
called super(); } } }
```

I would expect though the code to be compilable because in this case i
should refer to the containing class private field, not to the superclass
field (because it is private thus inaccessible to the subclass), so it
should be allowed to reference it in the constructor prologue.
Could you please take a look?

Thank you,
Ekaterina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250210/b78c28c2/attachment.htm>

From pavel.rappo at gmail.com  Sun Feb  9 22:26:30 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Sun, 9 Feb 2025 22:26:30 +0000
Subject: Default interface methods aren't considered abstract method
 implementations
In-Reply-To: <CAChcVumja73kp+6rYRNi3Mo7ho1jdLNHKD-LMPzGQBsaYeMQWA@mail.gmail.com>
References: <CAMYVXduar=aDq60-pnYy6TbkSfzuP5iSgLumdjbAwPa9Tr=vzA@mail.gmail.com>
 <CAChcVumja73kp+6rYRNi3Mo7ho1jdLNHKD-LMPzGQBsaYeMQWA@mail.gmail.com>
Message-ID: <CAChcVumBNFs_tFia+RObeChArJ7=urWjDX6CEjj9HjUKSGMMpQ@mail.gmail.com>

Attila,

Come to think of it, we should use some other, more narrowly focused,
mailing list. Apologies to subscribers of this list. Since lambda-dev
is defunct now, perhaps we could use compiler-dev, amber-dev, or
core-libs-dev instead. I'm voting for amber-dev, where Brian mostly
resides these days.

-Pavel

On Sun, Feb 9, 2025 at 10:12?PM Pavel Rappo <pavel.rappo at gmail.com> wrote:
>
> You are not specifically asking Brian, are you? If so, sorry for replying.
>
> My humble take is that the default method is something to use when
> there's nothing else there. When there's something, even if it's
> abstract, we use that. So, a default method is a minimally interfering
> fallback/extension scenario, if you will.
>
> That abstract A.m() effectively replaces default F.m() in C as if
> F.m() were never there. If F.m() were allowed to provide
> implementation for A.m() in C, then some uncompliable code could
> suddenly become compilable and operational at runtime.
>
> -Pavel.
>
> On Sun, Feb 9, 2025 at 9:04?PM Attila Szegedi <szegedia at gmail.com> wrote:
> >
> > Hey folks,
> >
> > I found a somewhat puzzling behavior: default interface methods aren't considered abstract method implementations. Trying to compile this minimal reproducer:
> >
> > ------ C.java ------
> > abstract class A {
> >   abstract void m();
> > }
> >
> > interface F {
> >   default void m() {}
> > }
> >
> > class C extends A implements F {}
> > ------ C.java ------
> >
> > $ javac C.java
> > C.java:9: error: C is not abstract and does not override abstract method m() in A
> > class C extends A implements F {
> > ^
> > 1 error
> >
> > I can accept this being valid according to JLS today (I tried with 11, 21, and 23.) I admit this is one of rare occasions when I didn't go scouring the JLS to figure out what exactly prevents the compiler from accepting F.m() as implementation of A.m() in C. I'm wondering though if this isn't something that could be improved upon in the future. (I'm sure there's a gotcha somewhere. Right, Brian? ;-) )
> >
> > Have a great day,
> >   Attila.

From archie.cobbs at gmail.com  Mon Feb 10 14:58:08 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 10 Feb 2025 08:58:08 -0600
Subject: JEP 492: javac error on a valid code
In-Reply-To: <CANuPR+MfSkfc_zwUGj5rTU3eGAbrhHSeWjGbWXqTzfoebkdTCA@mail.gmail.com>
References: <CANuPR+MfSkfc_zwUGj5rTU3eGAbrhHSeWjGbWXqTzfoebkdTCA@mail.gmail.com>
Message-ID: <CANSoFxt1mPZshxYiwwF3v3cj7S0gB4qh9xvj3GD_X=igg5H=Dg@mail.gmail.com>

Hi Ekaterina,

On Mon, Feb 10, 2025 at 8:30?AM Ekaterina Semenova <
ekaterina.semenova at jetbrains.com> wrote:

> I would expect though the code to be compilable because in this case i
> should refer to the containing class private field, not to the superclass
> field (because it is private thus inaccessible to the subclass), so it
> should be allowed to reference it in the constructor prologue.
> Could you please take a look?
>

Thanks - it looks like the "before supertype constructor has been called"
check is flawed and being too aggressive here. I'll take a look.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250210/7a6beb32/attachment.htm>

From archie.cobbs at gmail.com  Mon Feb 10 19:30:36 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 10 Feb 2025 13:30:36 -0600
Subject: JEP 492: javac error on a valid code
In-Reply-To: <CANSoFxt1mPZshxYiwwF3v3cj7S0gB4qh9xvj3GD_X=igg5H=Dg@mail.gmail.com>
References: <CANuPR+MfSkfc_zwUGj5rTU3eGAbrhHSeWjGbWXqTzfoebkdTCA@mail.gmail.com>
 <CANSoFxt1mPZshxYiwwF3v3cj7S0gB4qh9xvj3GD_X=igg5H=Dg@mail.gmail.com>
Message-ID: <CANSoFxsWFaj5pSpqKX=8F9+Js682305TasjHCOtX_bPLAJb6Mw@mail.gmail.com>

Filed as https://bugs.openjdk.org/browse/JDK-8349754.

Thanks for the bug report!

On Mon, Feb 10, 2025 at 8:58?AM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> Hi Ekaterina,
>
> On Mon, Feb 10, 2025 at 8:30?AM Ekaterina Semenova <
> ekaterina.semenova at jetbrains.com> wrote:
>
>> I would expect though the code to be compilable because in this case i
>> should refer to the containing class private field, not to the superclass
>> field (because it is private thus inaccessible to the subclass), so it
>> should be allowed to reference it in the constructor prologue.
>> Could you please take a look?
>>
>
> Thanks - it looks like the "before supertype constructor has been called"
> check is flawed and being too aggressive here. I'll take a look.
>
> -Archie
>
> --
> Archie L. Cobbs
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250210/41136147/attachment-0001.htm>