search

ebarlas / microhttp

Fast, scalable, self-contained, single-threaded Java web server
MIT License
539 stars 54 forks source link

Change source baseline to be Java 8 #2

Closed filiphr closed 2 years ago

filiphr commented 2 years ago

Change the source baseline to be Java 8.

The IntelliJ support for using different source versions in source and test is still not available in their latest 2021.3 release. However, there is an open issue IDEA-85478, which seems to have gained some traction and there is something working in the 2022.1 EAP (I tested it and it works good).

Almost all changes are due changing the convenience of the usage. However, the change in the ByteTokenizer might affect the performance, a multi release jar could be used here to in order to not lose any performance on Java 9+.

rbygrave commented 2 years ago

Is there a need to go back to Java 8? Why not just leave it at 17 or maybe can we keep a 17 based branch? People building and deploying new services could easily adopt 17 if they are not already?

ebarlas commented 2 years ago

@rbygrave , @filiphr reached out about the idea earlier. He's working on a project that is stuck on Java 8, though I don't know the details. I recommended a PR that we can discuss, so here it is. But the volume of code added is hard to overlook and I'm already starting to miss the Java features being taken away. Maybe a Java 8 branch would be workable, @filiphr? I don't anticipate very much churn in the codebase.

filiphr commented 2 years ago

Is there a need to go back to Java 8? Why not just leave it at 17 or maybe can we keep a 17 based branch? People building and deploying new services could easily adopt 17 if they are not already?

I am working on a Java 8 project and we can't use Java 17 for our tests only. I had an idea that MicroHttp can be used as a replacement of OKHttp MockWebServer for testing purposes.

But the volume of code added is hard to overlook and I'm already starting to miss the Java features being taken away. Maybe a Java 8 branch would be workable, @filiphr? I don't anticipate very much churn in the codebase.

I agree @ebarlas. The amount of code that was added to support Java 8 was something that was hurting me once I saw it. We can close this PR for now. Having a Java 8 only branch (if it is also published) is also workable. However, before that is done I would wait a bit in order for the main to stabilise.