feat: Upgrade to Java 11 and module system

[palexdev]

Make Playwright finally easy to use in modular projects

This will also require the update of workflows to use at least JDK11

@yuri-s This PR is the right one, fixes the one I closed #1165

[yury-s]

This will also require the update of workflows to use at least JDK11

According to your comment from the original PR it will break Java 8 clients. According to the JetBrains' survay most of the people are still on Java 8, we cannot break them at the moment. We need to find a way to add module support without breaking existing clients.

[palexdev]

According to the lastest JetBrains Statistics Java 8 is still predominant but its usage is rapidly decreasing in favor of JDK 11 and 17

I'd also like to find a way to add modules support because currently it's almost impossible to use Playwright in such projects. The first solution that comes to my mind would be to have a separate artifact for JDK11+, but from a "maintaining" perspective I don't know how much feasible it is

[GuillaumeTaffin]

Hi, I would add some points that I find interesting on this topic

1. A vast majority of Java devs use Spring/Spring Boot According to the stats you shared, we see that it's obviously the case. Well, Spring Boot 3 was release at the end of 2022 and it enforces the use of Java 17. Hence I personally think that it will encourage even more organizations to move forward to latest versions of the JDK.

2. Playwright is a relatively new player According to the release dates I just looked, playwright-java began in 2020. This is a personal thought, but I think that organizations that are still stuck with java 8 today are more likely to be companies that already had their "UI testing suite" long before playwright came into the game. I feel it's less likely that that kind of organization decided to move to playwright. In other words, organizations that choose playwright might probably be the "good students" of that world, that try new technologies and stay up-to-date. This means that they might have already migrated - or even started - to new versions of the JDK. Once again, this is my personal understanding of the java world - where I daily worked in a big banking company that tries to stay up-to-date - and this would need to be measured against the set of "real users of playwright-java". I think it's important to keep in mind that the Jetbrains's stats measure the "java community" not the "playwright-java users community". The figures could be quite different for that particular subset of people IMHO

[anthonyvdotbe]

It's possible to have both, module descriptors and compatibility with Java SE 8, by using multi-release JARs: you compile all sources with Java SE 8 and compile the module descriptors with Java SE 9+. See e.g. slf4j's configuration and the module descriptor for slf4j-api (note that it's under src/main/java9 instead of src/main/java).

[blutorange]

Until this gets resolved properly, can we perhaps add a Automatic-Module-Name to the manifest, see http://branchandbound.net/blog/java/2017/12/automatic-module-name/

Without an explicit name, the compiler will warn when attempting to use this library. That manifest entry is safe and you can also reserve the module name for this project.

E.g.

<configuration>
  <archive>
    <manifestEntries>
      <Automatic-Module-Name>playwright.driver.bundle</Automatic-Module-Name>
    </manifestEntries>
  </archive>
</configuration>

[helpermethod]

Hi,

just to chime in: You can still support Java 8 while providing Java 9 modules without Multi-Release JARs by using the Moditect Maven Plugin.