Announcement: PMLC version 3

[pml-lang]

Today I'm excited to announce the public availability of PML version 3.0.0.

This is another important milestone, and the biggest news is that PMLC has been completely rewritten in Java. PPL is no more used.

The goal was to enable PMLC to better evolve as an open-source project. Everything has been set up to empower Java developers to participate in the development and improvement of PMLC.

Moreover, the PMLC source code is now more modular, featuring many under-the-hood improvements that will be highly beneficial in the future.

There are also some new features (e.g. standalone binaries for Windows and Linux), and a few features that needed to be (temporarily) disabled. For more information please have a look at the Changelog or visit the website.

PML is now ready to take off.

Please help to share the word!

Enjoy!

[tajmone]

Great to see PML 3 released! ❤️

So now I will rush to release the new Sublime PML update I've been working on, then uninstall PML 2.3.0 and setup my machine for PML 3.0 — I'll have to migrate to a newer Java version (I've Java 12 on my machine), so I'll need to check that the few Java tool that I use daily are compatible with the new Java version required for PML before installing it.

Of course, I could just install the PML standalone executable version for Windows, and keep my current machine-wide Java version, but I'll still have to uninstall PML 2.3.0, right? i.e. since its executable name remains the same and having both versions along with each other would result in name resolution clashes, so that only one of the two will match the pmlc invocation.

Java Migration Questions

From my preliminary research based on the PML Changelog early draft, and the docs of the third party tool I need, it seems that the latter work with any Java version >= Java 10, so I guess that it should be fine. Otherwise, I could just download the PML for Windows standalone package with the bundled Java, but I was thinking that it would be best for me to go for PML as Java .jar files, since I might now and then be needing to switch from one PML version to another — e.g. older ones for projects that I haven't yet updated, and the latest for the Sublime PML work, etc. — since migrating all of the PML project to v3.0.0 might require some time (especially the PML Playground, which consists of multiple projects packed together, many of which are out of synch regarding the PML version they relate to).

So, which approach do you advise for me? the Win standalone package, or the .jar files + installing Java?

As for Java, are you aware whether apps written for Java 10 can also be run with later versions of Java? I have no idea how Java backward compatibility works with Java and the JDK.

The PML websites mentions:

you need to install Java version 17 or later.

Should I then stick to version 17 or install the latest version? i.e. in view of contributions also to the PMLC source repository. (I believe the latest version right now is Java 18 — v17 being an LTS release, v18 not).

For some reasons, the Java website still offers Java 8 as the default download version, and reaching the Java 17 download page requires some navigation through the (ultra-confusing) maze of cross-links and mysterious acronyms (SE vs JDK vs JMC), each version and acronym having a dedicated long explanatory page that make you think you'll have to give up all daily activities just to understand which version you should install, which files you need and where to download them, and how to correctly setup everything.

So, I might be pestering you a little bit more for some help on the correct setup, since it's a big machine-wide change that could also affect my usage of other Java tools I need for daily work. I thought that instead of writing you a private email I could ask here, so the instructions remains as a useful reference for others who might find themselves in the same predicament I'm currently facing.

[pml-lang]

So, which approach do you advise for me?

There are at least three options:

1. Use the standalone version and rename pmlc.exe to pmlc_3_0_0.exe (or maybe pmlc_latest.exe). You could do the same with new versions in the future (e.g. pmlc_3_1_0.exe, pmlc_3_3_2.exe, etc.) and keep all versions in a single directory, and just change the name of the called exe if you want to switch the version in a given context. Note: You can rename the exe; it will still work.

2. Install the latest version of Java (must at least be version 17 for PMLC) and disable (or remove) your old Java version 12. All your exiting Java applications should still work, because you are upgrading from version 12.

   Note: If you were still using Java version 8, then there could be problems with your existing Java applications, because Java version 9 introduced modules, which resulted in some incompatibility issues for pre-9 Java applications. But upgrading from 12 to 17 or 18 should be fine.

   Note: If you use PMLC's jar files distribution, you could also rename file bin\pmlc.bat to bin\pmlc_3_0_0.bat to keep different PMLC versions and use them as needed.

3. Install the latest version of Java (must at least be version 17 for PMLC) and keep version 12 installed. You can have different versions of Java coexist on your machine. However, in that case you must ensure that the right version is used for each application. This can be done with OS environment variables or by changing the OS PATH in OS scripts that call the application, or by hard-coding the correct Java path in OS script files.

   I would recommend this approach only if:

   • you decide not to use the standalone PMLC binary

   • and you encounter problems with an existing application that doesn't run on the latest Java version (for whatever strange reason).

Of course, I could just install the PML standalone executable version for Windows, and keep my current machine-wide Java version, but I'll still have to uninstall PML 2.3.0, right?

No, you can keep PML 2.3.0. You just need to ensure that the right version is called in your different contexts.

Should I then stick to version 17 or install the latest version?

Installing the latest Java version is always recommended and fine for PMLC.

are you aware whether apps written for Java 10 can also be run with later versions of Java?

Yes, should be fine, as explained above.

[tajmone]

Note: If you were still using Java version 8, then there could be problems with your existing Java applications, because Java version 9 introduced modules, which resulted in some incompatibility issues for pre-9 Java applications.

No, that was the case in the past, in fact I had to wait that all my tools migrated to Java 9 before I could make the leap, but eventually they all did (mostly at the same time, since they were part of the same ecosystem). But I do remember that the bump from Java 8 to 9 was a big deal, due to breaking changes and also due to incompatibilities with Gradle.

Use the standalone version and rename pmlc.exe to pmlc_3_0_0.exe

That wouldn't work for me since I need to use it for repositories maintenance, so their toolchains will be using the default binary filenames. The only alternative I can think of is creating a custom script that allows me to pick which version to use by adding its path to the system/User PATH.

But since I'll also be building PMLC from source, I definitely need to install Java separately in order to be able to run the local builds.

I should probably settle to have the latest PMLC release added to the sys PATH, so it's the default, and for any work with older or custom versions just create a script that overrides that path by adding its own path before all others — that usually works for me. So, even with repositories, I'd only need to update the Sys PATH before launching the toolchain, since then that CMD or Bash session will see first the other PMLC version.

Installing the latest Java version is always recommended and fine for PMLC.

Great, that's also the recommended strategy from Oracle, due to security patches and all (although they still promote Java 8 on the main page, but that's life I guess).

I'm really looking forward to setup the new PMLC v3.0, I was waiting in trepidation for this major update.

Thank you for all the help! If I have any doubts left I might knock on your door again, but I think I'm fine from here on.

[tajmone]

Installation Went Fine

Just wanted to let you know that the migration from Java 12 to 17 went great, and that my other Java tools are working just fine.

The biggest part of the work was manually deleting the Java 12 environment variables left behind after uninstalling it, since older Java versions didn't handle these vars. But the new Java 17 doesn't need users to fiddled any more with these vars (PATH entries, JAVA_HOME, etc.) since the new MSI installer takes care of all that (there are also less such entries now).

Anyhow, as with every Java installation and update, I keep nodes of every operation that goes with them.

As for PMLC, I've opted for the following approach: I have a dedicate folder for PMLC .jar files, organized into subfolders where pmlc/latest/ is the one added to the Sys PATH by default, to ensure that the latest version is always globally available.

In the future, if I need to access older versions, I'll just add them to other subfolders (e.g. pmlc/3.0.0/) and only need to add that path at the beginning of the PATH env-var to ensure that it will take precedence over the latest version. This way, my toolchains will still work via CMD or Bash, I only need to tweak the PATH var when I open the session.

Now I have a lot of migration work to do, especially with the PML Playground.

P.S. — I think that the Java setup instructions could do with some more details, especially considering that PML users are not necessarily programmers nor Java users. Unfortunately the Oracle Java documentation is still very verbose and confusing for newbies.

[tajmone]

P.S. 2 — I finally went for Java 17 instead of v18, because the former is an LTS, so it will receive updates up to 2024, whereas Java 18 will reach its EOL in September, so I'd have to migrate to v19. Right now, I'd rather have an LTS version so I don't have to worry about constant updates. When the next stable LTS release is out I'll migrate to that probably.

[pml-lang]

the migration from Java 12 to 17 went great

Awesome! Thanks for letting me know.

the Java setup instructions could do with some more details

Yes, but that would be a bit challenging to do, because there are many ways to install Java (depending on the OS, the JDK distro chosen, the license, etc.), and such instructions risk to get quickly out of date.

I finally went for Java 17

That's ok. I do not intend to use a newer Java version for PMLC in the near future.

[tajmone]

PML 3 Release Assets?

I've noticed that release v3.0.0 only provides archives with the source code in its Assets.

Aren't you also going to add to each release the different distribution packages that are available from the downloads pages? i.e. the .jar files, the OS-specific standalone binaries, etc.?

Having direct access to these distribution files in their release assets would be a convenient way to access older versions, when needed, and act an historical archive without having to create one.

Ideally, the same scripts you use to create those distribution files could be added to a CI service to generate them and attach them to each release, whenever a new release is created, so the whole process is automated.

NOTE — Beware that editing past releases (e.g. to add such assets in the future, retrospectively) could affect the order in which releases are shown in the repository. From what I've understood, releases are sorted based on their last-modified date, not by their tags.

I'm not 100% sure if the tag/release creation date prevails or not, but I'm aware that fiddling with old releases can lead to messing up their order of appearance.

[pml-lang]

add to each release the different distribution packages

The jar files distribution was added already, together with the sources (file pmlc-3.0.0.zip).
I've now added the Windows and Linux standalone executables.

could be added to a CI service to generate them and attach them to each release, whenever a new release is created, so the whole process is automated.

Yes, that needs to be done.

fiddling with old releases can lead to messing up their order of appearance.

Good to know. Thanks.