X-CGP-ClamAV-Result: CLEAN X-VirusScanner: Niversoft's CGPClamav Helper v1.25a (ClamAV 0.103.6/26757) X-Junk-Score: 0 [] X-KAS-Score: 0 [] Return-Path: Received: from mail-03.1984.is ([93.95.224.70] verified) by post.selbstdenker.com (CommuniGate Pro SMTP 6.3.14) with ESMTPS id 29106530 for webobjects-dev@wocommunity.org; Thu, 22 Dec 2022 02:08:06 +0100 Received-SPF: none receiver=post.selbstdenker.com; client-ip=93.95.224.70; envelope-from=hugi@karlmenn.is Received: from localhost by mail-03.1984.is with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p8A3l-00FFkM-I4 for webobjects-dev@wocommunity.org; Thu, 22 Dec 2022 01:07:45 +0000 From: Hugi Thordarson Content-Type: multipart/alternative; boundary="Apple-Mail=_01AE994E-49A0-4541-8263-B682E3DCFE18" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [WO-DEV] Java 17? Half or Full? Date: Thu, 22 Dec 2022 01:07:45 +0000 References: To: WebObjects & WOnder Development In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3696.120.41.1.1) --Apple-Mail=_01AE994E-49A0-4541-8263-B682E3DCFE18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You can also just go ahead and use JDK 17 with WO which works fine (as = previously pointed out by Ramsey). - hugi PS: Regarding the other stuff=E2=80=A6 Look deep into your soul while = unzipping a WO jar to cleverly avoid Apple's licensing and ask your = inner child: "Is this really what you wanted to do with your life". I think most of us are here for one or both of these reasons: 1) We have a lot of value tied up in existing software. 2) We love the WO way of doing things (and rightfully so) For many if not most, solving (1) is relatively easy (if you're not too = deep into D2W or the murkier parts of EOF). I've migrated dozens of = projects away from WO and Wonder. Cayenne tends to be a huge part of = that in some projects, and surprisingly easy to migrate to from EOF. (2) has certainly been more of a problem. I can't ditch the WO part of = WO. I've been working towards that through = https://www.fermentedshark.com/ , = which I'm not sure will ever amount to much, but I'd rather work on = something new than just perpetuate my WO problem. What I'm trying to say is=E2=80=A6 For years we've been something of a = cargo cult without a plane in sight. Changing that mentality is pretty = hard, but I can attest to the fact that doing so and checking out the = world outside beyond those old crates is extremely rewarding. We should = be making something new, not holding onto the old. Or, of course, you could just modify apple's jar files. > On 21 Dec 2022, at 22:23, patrick xeotech.com = wrote: >=20 >=20 > I am would like to propose an idea regarding this issue. My proposed = idea is loosely technical, is merely meant to illustrate the idea.=20 >=20 > First a little about me. Some of you that know me, know that I am not = a developer. I am like a musical producer that doesn=E2=80=99t write or = play music. I understand most parts of a project but couldn=E2=80=99t = start one on my own. I have a couple of commercial WO applications that = are deployed and am actively continuing development with the help of = some of you on this list.=20 >=20 > Fact: WO is governed by a massive license agreement and the concern is = how to update the WO development without stepping over a decompiling = landmine. In the old days to join the Apple Developer Program you had to = sign a very strict NDA to become part of the program, and pay $500. = Somewhere around 2010 Apple decided to open-source WebObjects and made = betas of 5.5.x sources available for a couple months on the developer = DVDs. They never continued this and instead pulled WebObjects = completely.=20 >=20 > As a non-lawyer, I am going to make certain assumptions and draw some = conclusions. Therefore take everything I say with the largest grain of = salt you can find. While many parts of the Apple NDA may apply to the = development pipeline, once a product is out in the public domain, not = sure if the NDA remains in effect. Parts of it likely will remain in = effect but certainly not all of it. Also an intellectual property in the = United States can only be prosecuted for a certain number of years and = after that it is free for all. Not sure about the timeline, but sure = looks like Apple is running out of time. That still leaves the = decompiling issue. Every company decompiles or deconstructs a competitor = product and tries to figure out how to make it without violating the = intellectual property protection. The difficulty is for the offended = party (Apple) to be able to prove it. >=20 > All that legal stuff sounds like a big pill to swallow, is complicated = and certainly expensive. What if I can show you a way where we can skip = over both issues, do our updates without having to worry about the = lawyers and remain faithful (legally) to Apple? >=20 > What if, upon installing WOnder an included script can run through the = WO class files, it unzips the jar files, includes, excludes or replaces = whatever it needs to be updated? This script will run by the individual = user upon downloading and installing the WOnder framework, i.e. no = distribution? This idea has a chance of working If, based on one of the = earlier posts, that said that there is no need to decompile, but rather = unzip. If true, then I think this idea has a good chance of working.=20 >=20 > What do you all think? >=20 >=20 > Best Regards, >=20 > Patrick Abuzeni, MD > Tel: 305-444-2888 >=20 > www.xeoTECH.com >=20 > The information transmitted is intended only for the person or entity = to which it is addressed and may contain confidential and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon, this information by persons or = entities other than the intended recipient is prohibited. If you = received this information in error, please contact the sender and delete = the message and material from all computers. >=20 >> On Dec 10, 2022, at 10:42 AM, Aaron Rosenzweig > wrote: >>=20 >> This is both a topic for both pure NeXT/Apple WO as well as a WOnder.=20= >>=20 >> Your WO deployments, are they on Java 17? Are they half or full Java = 17? Please chime in.=20 >>=20 >> In our case, at present, we are developing and deploying on a Java 17 = VM but using Java 1.8 (version 8) compliance. I call this =E2=80=9CJava = 17 Half" >>=20 >> Definitions: >> Java 17 Half -> Developing and deploying on Java 17 but using Java = 1.8 compliance. >> Java 17 Full -> Not only using a Java 17 VM but also targeting v17 = compliance and using JPMS (Java Package Management System) which was = introduced with Java 9.=20 >>=20 >> PHB -> =E2=80=9CSo I was golfing with my buddies and found out they = are all using Java 17 *sealed* classes. This is so cool and will = revolutionize our codebase. I want you to start using it immediately. It = was introduced with Java 17. I=E2=80=99m so glad we are on a 17 VM.=E2=80=9D= =20 >>=20 >> Me -> =E2=80=9CCan=E2=80=99t do it=E2=80=9D >>=20 >> PHB -> =E2=80=9CWhy not? You told me we went to Java 17 over a year = ago.=E2=80=9D >>=20 >> Me -> =E2=80=9CWe did and are on Java 17, but we compile for Java = 1.8=E2=80=9D >>=20 >> PHB -> =E2=80=9CThat=E2=80=99s no good. We need to be fully modern. = We need to be able to use new constructs as they emerge. Why are we = compiling for Java 1.8 ? Is it a problem with WOnder?=E2=80=9D >>=20 >> Me -> =E2=80=9CBecause our core frameworks are closed source, from = NeXT/Apple, our hands are somewhat tied. That=E2=80=99s part of the = problem. The other part is that class loading changed dramatically with = Java 9 onward and broke a lot of things for many people. Because we = leverage so much from Apple and WOnder, we pretty much are stuck. Our = frameworks are stuck in java 8 compliance and therefore so are we=E2=80=9D= =20 >>=20 >> Definitions: >> Old Class loader -> Java 1.8 (version 8) and older.=20 >> New Class loader -> Java 9 and newer.=20 >>=20 >> The new class loader tries to avoid =E2=80=9CJar Hell=E2=80=9D but = that=E2=80=99s something we actually enjoyed about the old class loader. = What Oracle saw as a weakness and sought to fix, Sun saw as a strength. = It=E2=80=99s causing us trouble right now with going Java 17 Full. = Here=E2=80=99s an example.=20 >>=20 >> Consider a jar named =E2=80=9Canimals_v1.jar=E2=80=9D that has = classes for birds and other creatures. Imagine that there is also a = newer =E2=80=9Canimals_v2.jar=E2=80=9D Let me diagram them below in = pseudocode: >>=20 >> animals_v1.jar: >> com.acme.Duck.speak() >>=20 >> animals_v2.jar: >> com.acme.Duck.speak() >> com.acme.Duck.hasFeathers() >>=20 >> Suppose you are using the old class loader and somehow had both jars = in your class path. It matters which jar is first because the first one = wins when there are multiple definitions in the class path for = =E2=80=9Ccom.acme.Duck=E2=80=9D. You could have a situation where things = compile but at runtime there=E2=80=99s a failure because we can=E2=80=99t = ask =E2=80=9ChasFeathers()=E2=80=9D and it=E2=80=99s situations like = these that Oracle considered a design flaw or =E2=80=9CJar Hell.=E2=80=9D=20= >>=20 >> In our case, we considered this functionality of the old class loader = a strength. As long as we are careful, we can avoid the pitfalls but = also do clever patching of closed source Apple frameworks like so: >>=20 >> Apple java frameworks: >> com.apple.NSArray >>=20 >> WOnder java frameworks: >> com.apple.NSArray >>=20 >> By putting WOnder=E2=80=99s frameworks first in the class path, and = being careful to not remove needed functionality of NSArray, we can = =E2=80=9Coverwrite=E2=80=9D Apple's implementation with an improved one = while letting the rest of Apple=E2=80=99s code work directly with our = NSArray replacement. Unfortunately this breaks the new class loader. = It=E2=80=99s not allowed. Cannot have NSArray defined in more than one = named place. Even if we take WOnder out of the equation, we still have = problems with Apple=E2=80=99s JavaXML framework where it redefines W3C = and DOM objects that java.xml named module natively defines in modern = Java.=20 >>=20 >> If we want to compile for modern java on new VMs what can we do? = I=E2=80=99m no expert, so correct me if I=E2=80=99m wrong, but I=E2=80=99m= trying to make sense of what our options are. There is no easy path. = There is no set of simple VM arguments or anything magic that takes a = small amount of effort. We=E2=80=99d have to do something like = TreasureBoat where we take ownership of the private libraries. We = can=E2=80=99t surgically replace a few objects in the private libraries = anymore by class path ordering and I don=E2=80=99t think Aspect-Oriented = Programming nor Dependency Injection can save us here either. We also = now have conflicts in pure Apple libraries with what is currently = built-into Java.=20 >>=20 >> How long are we ok using modern VMs but compiling for 1.8? =E2=80=9COK=E2= =80=9D meaning functional but not allowed to use new Java language = features.=20 >>=20 >> 2026 is when Amazon stops supporting 1.8 JVMs >> 2030 is when Oracle stops supporting 1.8 JVMs >>=20 >> I could not determine when javac compliance level support might be = dropped for Java 1.8 on modern VMs. That said, I guess it would be at = least until 2030 when Oracle no longer provides 1.8 VM support. It might = last longer than that=E2=80=A6 perhaps 2040. Hard to say. Lots of people = are struggling with JPMS (Java Modules) in similar situations as us. = Such as this quote: "Your program might even have a dep on some jar that = was compiled under jdk4 and the author and source are nowhere to be = found (or went out of business a decade ago)... and suddenly it breaks = under java9. Things like that are largely what prevented mass adoption = of jdk9 immediately.=E2=80=9D >>=20 >> We might be able to be creative by taking jars from multiple = frameworks, putting them in one modularized framework, and exposing = something for a modern java app. I=E2=80=99m not clear that would work = but maybe. I think there are Apple frameworks which conflict with named = module java.xml which likely cannot be worked around. This guy did = something like this for his legacy frameworks (not WO): = https://stackoverflow.com/questions/53245628/jdk9-automatic-modules-and-sp= lit-packages-dependencies = =20 >>=20 >> In closing, I don=E2=80=99t think it=E2=80=99s possible without = rewriting closed-source Apple libraries and also rewriting WOnder to = target compliance level beyond 1.8. Is there anyone building with = compliance level beyond 1.8?=20 >> ############################################################# >> This message is sent to you because you are subscribed to >> the mailing list >. >> To unsubscribe, E-mail to: > >> To switch to the DIGEST mode, E-mail to = > >> To switch to the INDEX mode, E-mail to = > >> Send administrative queries to = > >>=20 >=20 --Apple-Mail=_01AE994E-49A0-4541-8263-B682E3DCFE18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
You can also just go ahead and use JDK 17 with WO which works = fine (as previously pointed out by Ramsey).

- hugi


PS:

Regarding the other stuff=E2=80=A6 Look deep into your soul = while unzipping a WO jar to cleverly avoid Apple's licensing and ask = your inner child: "Is this really what you wanted to do with your = life".

I think = most of us are here for one or both of these reasons:

1) We have a lot of = value tied up in existing software.
2) We love the = WO way of doing things (and rightfully so)

For many if not most, solving (1) is = relatively easy (if you're not too deep into D2W or the murkier parts of = EOF). I've migrated dozens of projects away from WO and Wonder. Cayenne = tends to be a huge part of that in some projects, and surprisingly easy = to migrate to from EOF.

(2) has certainly been more of a problem. I can't ditch the = WO part of WO. I've been working towards that through https://www.fermentedshark.com/ , which I'm not sure = will ever amount to much, but I'd rather work on something new than just = perpetuate my WO problem.

What I'm trying to say is=E2=80=A6 For years we've been = something of a cargo cult without a plane in sight. Changing that = mentality is pretty hard, but I can attest to the fact that doing so and = checking out the world outside beyond those old crates is extremely = rewarding. We should be making something new, not holding onto the = old.

Or, of = course, you could just modify apple's jar files.


On 21 Dec 2022, at 22:23, patrick xeotech.com <patrick@xeotech.com>= wrote:

=
= I am would like to propose an idea regarding this issue. My proposed = idea is loosely technical, is merely meant to illustrate the = idea. 

= First a little about me. Some of you that know me, know that I am not a = developer. I am like a musical producer that doesn=E2=80=99t write or = play music. I understand most parts of a project but couldn=E2=80=99t = start one on my own. I have a couple of commercial WO applications that are deployed and am actively continuing development with the help = of some of you on this list. 

= Fact: WO is governed by a massive license agreement and the concern is = how to update the WO development without stepping over a decompiling = landmine. In the old days to join the Apple Developer Program you had to = sign a very strict NDA to become part of the program, and pay $500. Somewhere around 2010 Apple decided to = open-source WebObjects and made betas of 5.5.x sources available for a = couple months on the developer DVDs. They never continued this and = instead pulled WebObjects completely. 

= As a non-lawyer, I am going to make certain assumptions and draw some = conclusions. Therefore take everything I say with the largest grain of = salt you can find. While many parts of the Apple NDA may apply to the = development pipeline, once a product is out in the public domain, not sure if the NDA remains in effect. Parts of it = likely will remain in effect but certainly not all of it. Also an = intellectual property in the United States can only be prosecuted for a = certain number of years and after that it is free for all. Not sure about the timeline, but sure looks like Apple is = running out of time. That still leaves the decompiling issue. Every = company decompiles or deconstructs a competitor product and tries to = figure out how to make it without violating the intellectual property protection. The difficulty is for the offended party (Apple) = to be able to prove it.

= All that legal stuff sounds like a big pill to swallow, is complicated = and certainly expensive. What if I can show you a way where we can skip = over both issues, do our updates without having to worry about the = lawyers and remain faithful (legally) to Apple?

= What if, upon installing WOnder an included script can run through the = WO class files, it unzips the jar files, includes, excludes or replaces = whatever it needs to be updated? This script will run by the individual = user upon downloading and installing the WOnder framework, i.e. no distribution? This idea has a chance of working If, = based on one of the earlier posts, that said that there is no need to = decompile, but rather unzip. If true, then I think this idea has a good = chance of working. 

= What do you all think?


Best Regards,

Patrick Abuzeni, MD
Tel: 305-444-2888

www.xeoTECH.com

The information transmitted is intended only for the person or = entity to which it is addressed and may contain confidential = and/or privileged material. Any review, retransmission, = dissemination or other use of, or taking of any action in = reliance upon, this information by persons or entities other than the intended = recipient is prohibited. If you received this information = in error, please contact the sender and delete the message and = material from all computers.

On Dec 10, 2022, at 10:42 AM, Aaron Rosenzweig <aaron@chatnbike.com>= wrote:

This is both a topic for both pure NeXT/Apple WO as well = as a WOnder.

Your WO deployments, are they on Java 17? Are they half or full Java 17? = Please chime in.

In our case, at present, we are developing and deploying on a Java 17 VM = but using Java 1.8 (version 8) compliance. I call this =E2=80=9CJava 17 = Half"

Definitions:
Java 17 Half -> Developing and deploying on Java 17 but using Java = 1.8 compliance.
Java 17 Full -> Not only using a Java 17 VM but also targeting v17 = compliance and using JPMS (Java Package Management System) which was = introduced with Java 9.

PHB -> =E2=80=9CSo I was golfing with my buddies and found out they = are all using Java 17 *sealed* classes. This is so cool and will = revolutionize our codebase. I want you to start using it immediately. It = was introduced with Java 17. I=E2=80=99m so glad we are on a 17 VM.=E2=80=9D=

Me -> =E2=80=9CCan=E2=80=99t do it=E2=80=9D

PHB -> =E2=80=9CWhy not? You told me we went to Java 17 over a year = ago.=E2=80=9D

Me -> =E2=80=9CWe did and are on Java 17, but we compile for Java = 1.8=E2=80=9D

PHB -> =E2=80=9CThat=E2=80=99s no good. We need to be fully modern. = We need to be able to use new constructs as they emerge. Why are we = compiling for Java 1.8 ? Is it a problem with WOnder?=E2=80=9D

Me -> =E2=80=9CBecause our core frameworks are closed source, from = NeXT/Apple, our hands are somewhat tied. That=E2=80=99s part of the = problem. The other part is that class loading changed dramatically with = Java 9 onward and broke a lot of things for many people. Because we leverage so much from Apple and WOnder, we pretty much are stuck. Our = frameworks are stuck in java 8 compliance and therefore so are we=E2=80=9D=

Definitions:
Old Class loader -> Java 1.8 (version 8) and older.
New Class loader -> Java 9 and newer.

The new class loader tries to avoid =E2=80=9CJar Hell=E2=80=9D but = that=E2=80=99s something we actually enjoyed about the old class loader. = What Oracle saw as a weakness and sought to fix, Sun saw as a strength. = It=E2=80=99s causing us trouble right now with going Java 17 Full. = Here=E2=80=99s an example.

Consider a jar named =E2=80=9Canimals_v1.jar=E2=80=9D that has classes = for birds and other creatures. Imagine that there is also a newer = =E2=80=9Canimals_v2.jar=E2=80=9D Let me diagram them below in = pseudocode:

animals_v1.jar:
com.acme.Duck.speak()

animals_v2.jar:
com.acme.Duck.speak()
com.acme.Duck.hasFeathers()

Suppose you are using the old class loader and somehow had both jars in = your class path. It matters which jar is first because the first one = wins when there are multiple definitions in the class path for = =E2=80=9Ccom.acme.Duck=E2=80=9D. You could have a situation where things compile but at runtime there=E2=80=99s a failure because we can=E2=80=99t= ask =E2=80=9ChasFeathers()=E2=80=9D and it=E2=80=99s situations like = these that Oracle considered a design flaw or =E2=80=9CJar Hell.=E2=80=9D

In our case, we considered this functionality of the old class loader a = strength. As long as we are careful, we can avoid the pitfalls but also = do clever patching of closed source Apple frameworks like so:

Apple java frameworks:
com.apple.NSArray

WOnder java frameworks:
com.apple.NSArray

By putting WOnder=E2=80=99s frameworks first in the class path, and = being careful to not remove needed functionality of NSArray, we can = =E2=80=9Coverwrite=E2=80=9D Apple's implementation with an improved one = while letting the rest of Apple=E2=80=99s code work directly with our = NSArray replacement. Unfortunately this breaks the new class loader. It=E2=80=99s not = allowed. Cannot have NSArray defined in more than one named place. Even = if we take WOnder out of the equation, we still have problems with = Apple=E2=80=99s JavaXML framework where it redefines W3C and DOM objects that java.xml named module natively defines in modern Java.

If we want to compile for modern java on new VMs what can we do? I=E2=80=99= m no expert, so correct me if I=E2=80=99m wrong, but I=E2=80=99m trying = to make sense of what our options are. There is no easy path. There is = no set of simple VM arguments or anything magic that takes a small amount of effort. We=E2=80=99d have to do something like TreasureBoat = where we take ownership of the private libraries. We can=E2=80=99t = surgically replace a few objects in the private libraries anymore by = class path ordering and I don=E2=80=99t think Aspect-Oriented = Programming nor Dependency Injection can save us here either. We also now have = conflicts in pure Apple libraries with what is currently built-into = Java.

How long are we ok using modern VMs but compiling for 1.8? =E2=80=9COK=E2=80= =9D meaning functional but not allowed to use new Java language = features.

2026 is when Amazon stops supporting 1.8 JVMs
2030 is when Oracle stops supporting 1.8 JVMs

I could not determine when javac compliance level support might be = dropped for Java 1.8 on modern VMs. That said, I guess it would be at = least until 2030 when Oracle no longer provides 1.8 VM support. It might = last longer than that=E2=80=A6 perhaps 2040. Hard to say. Lots of people are struggling with JPMS (Java Modules) in similar = situations as us. Such as this quote: "Your program might even have a = dep on some jar that was compiled under jdk4 and the author and source = are nowhere to be found (or went out of business a decade ago)... and suddenly it breaks under java9. Things like that = are largely what prevented mass adoption of jdk9 immediately.=E2=80=9D

We might be able to be creative by taking jars from multiple frameworks, = putting them in one modularized framework, and exposing something for a = modern java app. I=E2=80=99m not clear that would work but maybe. I = think there are Apple frameworks which conflict with named module java.xml which likely cannot be worked around. This guy = did something like this for his legacy frameworks (not WO): = https://stackoverflow.com/questions/53245628/jdk9-automatic-modules-and-sp= lit-packages-dependencies

In closing, I don=E2=80=99t think it=E2=80=99s possible without = rewriting closed-source Apple libraries and also rewriting WOnder to = target compliance level beyond 1.8. Is there anyone building with = compliance level beyond 1.8?
#############################################################
This message is sent to you because you are subscribed to
 the mailing list <webobjects-dev@wocommunity.org>.
To unsubscribe, E-mail to: <webobjects-dev-off@wocommunity.org>
To switch to the DIGEST mode, E-mail to <webobjects-dev-digest@wocommunity.org>
To switch to the INDEX mode, E-mail to <webobjects-dev-index@wocommunity.org>
Send administrative queries to  <webobjects-dev-request@wocommunity.org>



= --Apple-Mail=_01AE994E-49A0-4541-8263-B682E3DCFE18--