X-CGP-ClamAV-Result: CLEAN X-VirusScanner: Niversoft's CGPClamav Helper v1.25a (ClamAV 0.103.6/26745) X-Junk-Score: 0 [] X-KAS-Score: 0 [] Return-Path: Received: from mail-qt1-f181.google.com ([209.85.160.181] verified) by selbstdenker.ag (CommuniGate Pro SMTP 6.3.14) with ESMTPS id 29049634 for webobjects-dev@wocommunity.org; Fri, 09 Dec 2022 22:50:35 +0100 Received-SPF: pass receiver=post.selbstdenker.com; client-ip=209.85.160.181; envelope-from=recurve@cocoanutstech.com Received: by mail-qt1-f181.google.com with SMTP id s9so4424158qtx.6 for ; Fri, 09 Dec 2022 13:50:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chatnbike.com; s=chatnbike; h=references:to:in-reply-to:subject:date:mime-version:message-id:from :from:to:cc:subject:date:message-id:reply-to; bh=HX6bShPyQr2cZftC+nfkKVlTCIGqbh5wTZMcCipocCg=; b=YqfKtmmPQ+BcF704PzKW8tGSRKSDxPc/CPuEQUWobiGxR+oUfJDDauURJ/uu7EUqxN Ecllpv2Yvsm7PLHqWVRuNlj22QsUgWzC8JlhnL8A6m6InJus5r3fLON6Sdqg2X9D0GXh n73NPzGz8VN/lFXT7iBHbB/6E7ifIlg1byIb0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:in-reply-to:subject:date:mime-version:message-id:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HX6bShPyQr2cZftC+nfkKVlTCIGqbh5wTZMcCipocCg=; b=uK+EfgHOEVXp0PXQYl2BpWPW+xPPJSGhuEXsEf4vofFJZCuFmewP7sNfeCONgwTgiA nk5VGE5CWgKuAoBhKAntmLAK48MYVPvdP4VWn7h8opy3tKzwLQtGTm/Mv8UrEIxqQMGM Wv0V6JU6O2MENTEnMIe7eqzYiMo7SqZlT6gACszu/xvyG3yqn/iCF/8FvXMSFU7mn4S6 qh4k8V051hoou6KL3HqGe6tQrwXKMyQIcTavOeXXttLrih9z5reUIenGeDVgehTrGeOH f2pqX75/vEYjUEntVno5GAl+/ETbTUzkFwq4DPS0YUubOj92bYmgTL88rdezSp1c8t6x oX8w== X-Gm-Message-State: ANoB5pnzzWeh7q2dnuegoZ6k0b+7YEa5AaEeB2NX1RPax/Sdb8bgwWg8 dh0s2pNZ4WItD/xo2aKnL8CvAb1yD82gmqikWG4= X-Google-Smtp-Source: AA0mqf6rzeOzzWviFso7h8O+omwMGx2q/Io1YOPvOpX8niRrZDlyZ9ie8CmXrrFJOLkKhPrPnPqYng== X-Received: by 2002:ac8:111a:0:b0:3a5:7396:f296 with SMTP id c26-20020ac8111a000000b003a57396f296mr9796958qtj.44.1670622614999; Fri, 09 Dec 2022 13:50:14 -0800 (PST) Return-Path: Received: from smtpclient.apple (pool-173-79-19-72.washdc.fios.verizon.net. [173.79.19.72]) by smtp.gmail.com with ESMTPSA id v5-20020a05620a440500b006f474e6a715sm706922qkp.131.2022.12.09.13.50.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Dec 2022 13:50:14 -0800 (PST) From: Aaron Rosenzweig Message-Id: <0DE387BE-1D71-4BCA-82DC-F3428511EFA2@chatnbike.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EF815741-DE0F-4FC8-BEA8-CCD6319723D5" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Date: Fri, 9 Dec 2022 16:50:14 -0500 Subject: Part 2: duplication in frameworks: ERExtensions, javaeoaccess In-Reply-To: To: WebObjects & WOnder Development References: X-Mailer: Apple Mail (2.3696.120.41.1.1) --Apple-Mail=_EF815741-DE0F-4FC8-BEA8-CCD6319723D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This issue might be solved like explained here: = https://stackoverflow.com/questions/53245628/jdk9-automatic-modules-and-sp= lit-packages-dependencies = We could possibly make a framework that includes ERExtensions along with = the Apple frameworks and treat that as a single module. It's not exactly the same situation. In the stackoverflow case, they had = the same package path but different objects in each. We have not only the same package path, but also the same Object. Am I barking up the wrong tree? Any advice on how to reach Java 17 = compliance for compiling?=20 > On Dec 9, 2022, at 4:37 PM, Aaron Rosenzweig = wrote: >=20 > The package com.webobjects.eoaccess is defined in both: ERExtensions, = javaeoaccess >=20 > javaeoaccess is a framework from NeXT/Apple.=20 >=20 > I believe ERExtensions recreated a distinctly apple package name so = that we could replace Apple's _EOExpressionArray with a new one from = Wonder.=20 >=20 > This worked because if we load ERExtensions before = JavaEOAccess.framework=E2=80=A6 in the class path, the first one wins. = Old JVMs would happily take the first. While this is risky, it worked as = long as we were careful (and sort of knew what Apple was doing). We did = things like this because we didn=E2=80=99t own JavaEOAccess and = basically =E2=80=9Cpatched it=E2=80=9D because we wanted an improvement = that Apple didn=E2=80=99t provide. We could do better than Apple and = this is how we did it, while letting the rest of the Apple plumbing = continue working with particular object replacements.=20 >=20 > This cannot work past Java 1.8 can it? If we are targeting Java 17 = compliance, we are then using JPMS (Java Package Module System) aka = =E2=80=9CJava Modules=E2=80=9D which won=E2=80=99t accept this type of = patch.=20 >=20 > In my application project, I created a module-info.java and placed = these lines in it: >=20 > requires ERExtensions; > requires javaeoaccess; >=20 > We need both lines right? But this results in the the following = unsurprising error: > The package com.webobjects.eoaccess is accessible from more than one = module: ERExtensions, javaeoaccess >=20 > What am I missing? Are we stuck? Without being able to update the = Apple jars directly, the old hacks cannot work in the new word of Java = Modules. We=E2=80=99ve done this in many places including NSArray. Are = we stuck living in Java 1.8 compliance with Java 17? --Apple-Mail=_EF815741-DE0F-4FC8-BEA8-CCD6319723D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = issue might be solved like explained here: https://stackoverflow.com/questions/53245628/jdk9-automatic-mod= ules-and-split-packages-dependencies

We = could possibly make a framework that includes ERExtensions along with = the Apple frameworks and treat that as a single module.

It's not exactly the same situation. In = the stackoverflow case, they had the same package path but = different objects in each.

We have not only = the same package path, but also the same Object.

Am I barking up the wrong tree? Any = advice on how to reach Java 17 compliance for compiling? 


On Dec 9, 2022, at 4:37 PM, Aaron Rosenzweig <aaron@chatnbike.com>= wrote:

The package com.webobjects.eoaccess is defined in both: = ERExtensions, javaeoaccess

javaeoaccess is = a framework from NeXT/Apple.

I believe = ERExtensions recreated a distinctly apple package name so that we could = replace Apple's _EOExpressionArray with a new one from Wonder.

This worked because if we load ERExtensions = before JavaEOAccess.framework=E2=80=A6 in the class path, the first one = wins. Old JVMs would happily take the first. While this is risky, it = worked as long as we were careful (and sort of knew what Apple was = doing). We did things like this because we didn=E2=80=99t own = JavaEOAccess and basically =E2=80=9Cpatched it=E2=80=9D because we = wanted an improvement that Apple didn=E2=80=99t provide. We could do = better than Apple and this is how we did it, while letting the rest of = the Apple plumbing continue working with particular object replacements. =

This cannot work past Java 1.8 can it? If = we are targeting Java 17 compliance, we are then using JPMS (Java = Package Module System) aka =E2=80=9CJava Modules=E2=80=9D which won=E2=80=99= t accept this type of patch.

In my = application project, I created a module-info.java and placed these lines = in it:

requires ERExtensions;
requires javaeoaccess;

We need = both lines right? But this results in the the following unsurprising = error:
The package com.webobjects.eoaccess is accessible = from more than one module: ERExtensions, javaeoaccess

What am I missing? Are we stuck? Without being able to update = the Apple jars directly, the old hacks cannot work in the new word of = Java Modules. We=E2=80=99ve done this in many places including NSArray. = Are we stuck living in Java 1.8 compliance with Java 17? =

= --Apple-Mail=_EF815741-DE0F-4FC8-BEA8-CCD6319723D5--