Hy, You are right on the decompiling-part. But the licence also states that you are not allowed to distribute the jars on your own. Only Apple is allowed to distribute them. But it seems Apple does not care anymore about WebObjects.
For this module-test one could also do a manual approach, because there are no updates on WebObjects anymore: Just unzip all WoJars and copy all relevant classfiles/Resourcefiles together in a directory. In an own project write a module-info-file for the wo-packages and add the required dummyfiles so that your module-info compiles to a classfile. Then throw this to the WO-classfiles and use commandline to build the jar. Not sure how hard this is todo, but it may be possible and would enable to use WebObjects in new java-module-projects as long as the new Java-VMs are backwards compatible to the bytecode of the old classfiles. Best Regards, Wolfgang Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Ray Kiddy <r...@ganymede.org> Sent: Sunday, December 11, 2022 12:13:42 AM To: Wolfgang Hartmann <halbei...@hotmail.com>; WebObjects-Dev List <webobjects-dev@lists.apple.com> Subject: Re: AW: Java 17? Half or Full? These are great ideas. How hard do you think it would be to implement them? By the way, you point out that the WO license does not allow you to decompile the jars. I would suggest that unzipping the jar files to get a individual class files is not "decompiling" anything. If one is decompiling the class files to get at some version of the java files as written by Apple, that would be "decompiling". Have I asked a lawyer about this? I only ask a question of a lawyer if I want to be told what I cannot do. I do not need to ask about something that I can do. cheers - ray On 12/10/22 12:53, Wolfgang Hartmann via Webobjects-dev wrote: > Hello, > > That the WO-Jars are closed source makes it really hard to move to the > new Java-Module-System. But I had a similar problem once and was able to > solve it. Maybe this can help here. But that requirement did not involve > My requirement was: > > * I wanted to deploy a Java-Background-Service (a small WebApp with > REST-Interfaces) on Windows Desktop-Machines > * I wanted to have a single "exe" to start and the app should run. > Using the Java-Module-System it's possible to create an exe with the > own code, all dependencies and a stripped-down mini-Java-VM with > just the required parts. So you get an "exe" with around 20 MB which > can run on any Windows without the requirement that Java is installed > * This "exe" was distributed and started by Windows-Group-Policies > (That was the reason for this "one exe deployment") > > I was able to do this with the following approach: > > * Own Java-Maven-Project with my code. The project was built as > maven-"fat-jar" (so all class-files in one big jar) > * All project-dependencies were regular maven-dependencies. Most of > the dependencies were not in Java-Module-Format. And very important > here: You are just able to use Java-Module-Build when your code and > ALL your dependencies are in module-format!! > * I then provided an own "java-module-file" for alle my code AND all > the code of the project-dependencies (listing of all packages, ... > Basically all the stuff the Java-Module-System requires) > * My fat-jar-build throw this all together and builded a new jar which > contained my class-files, all dependency-class-files and a > java-module-info and therefore was a valid java-module-jar which I > could bundle as an exe-file > > So what to do with WebObjects? (Important: This is just an idea, I did > not try to do this!) > > * Creating a new Project "WebObject-JavaModule" > * List all WebObjects-Jars as Maven-Dependencies > * Build-Target as "fat jar" > o Filter all classes which do not belong to WebObjects because > they are provided by the Java-VM or by other dependencies > o Filter all classes where ProjectWonder provides an > improved/patched version > * Write a java-module-file for all the remaining WebObjects-Class-Files > * Build this as "fat jar" and use this instead of the "old > webobjects-jars" in your projects or Wonder-Projects > * Now all Wonder-Projects could be updated to Java-Module-Format (As > long as all the other depencies of them are also in Module-Format) > > But be aware of licence-restrictions: The WebObjects-Jars are > distributed with the WebObjects-Licence. The licence states that it is > not allowed to decompile the Jars and maybe this new > "WebObjects-JavaModule" could be seen as derivative work and could be > legally not allowed to exists. > > Best Regards, > Wolfgang > > ------------------------------------------------------------------------ > *Von:* Aaron Rosenzweig via Webobjects-dev <webobjects-dev@lists.apple.com> > *Gesendet:* Samstag, 10. Dezember 2022 16:36 > *An:* WebObjects-Dev List <webobjects-dev@lists.apple.com> > *Betreff:* Java 17? Half or Full? > 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 “Java 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 -> “So 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’m so glad we are on a 17 VM.” > > Me -> “Can’t do it” > > PHB -> “Why not? You told me we went to Java 17 over a year ago.” > > Me -> “We did and are on Java 17, but we compile for Java 1.8” > > PHB -> “That’s 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?” > > Me -> “Because our core frameworks are closed source, from NeXT/Apple, > our hands are somewhat tied. That’s 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” > > 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 “Jar Hell” but that’s 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’s causing us > trouble right now with going Java 17 Full. Here’s an example. > > Consider a jar named “animals_v1.jar” that has classes for birds and > other creatures. Imagine that there is also a newer “animals_v2.jar” 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 > “com.acme.Duck”. You could have a situation where things compile but at > runtime there’s a failure because we can’t ask “hasFeathers()” and it’s > situations like these that Oracle considered a design flaw or “Jar Hell.” > > 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’s frameworks first in the class path, and being > careful to not remove needed functionality of NSArray, we can > “overwrite” Apple's implementation with an improved one while letting > the rest of Apple’s code work directly with our NSArray replacement. > Unfortunately this breaks the new class loader. It’s 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’s 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’m no > expert, so correct me if I’m wrong, but I’m 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’d > have to do something like TreasureBoat where we take ownership of the > private libraries. We can’t surgically replace a few objects in the > private libraries anymore by class path ordering and I don’t 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? “OK” 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… 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.” > > 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’m 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-split-packages-dependencies > > <https://stackoverflow.com/questions/53245628/jdk9-automatic-modules-and-split-packages-dependencies> > > In closing, I don’t think it’s 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? > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/ray%40ganymede.org > > This email sent to r...@ganymede.org
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
