When using the —release option my understanding is that the compiler only exposes JDK classes for the target release, so you can’t accidentally reference newer Java API classes and methods. However, when running the tests you would still be using the newer JDK instead of the target JDK. The only way I know how to limit that is via toolchains.
Ralph > On Jun 9, 2019, at 10:11 AM, Matt Sicker <[email protected]> wrote: > > The IntelliJ ticket is certainly a good idea. I was thinking it might be a > simpler setup to compile with anything 9+ and a verifier on API usage, > though who knows if that will introduce other issues. > > On Sun, Jun 9, 2019 at 12:05, Ralph Goers <[email protected]> > wrote: > >> That would mean abandoning Java’s multi-version support. I’m not in favor >> of that as I believe once we are building with Java 9+ things should be >> able to get simpler. I will trust builds once you can use -release as a >> build option. >> >> I would suggest opening a ticket with Intellij to get them to recognize >> and support the toolchains plugin. >> >> Ralph >> >>> On Jun 9, 2019, at 9:54 AM, Matt Sicker <[email protected]> wrote: >>> >>> One potential fix could be to extract the version specific code into its >>> own support library that we only need to release once in a while. That >>> would at least minimize the workarounds required in the main repo. That’s >>> what we’ve done in Jenkins so far at least (which also has several native >>> code bindings packaged similarly). >>> >>> On Sun, Jun 9, 2019 at 11:21, Matt Sicker <[email protected]> wrote: >>> >>>> Kind of funny that I have an old todo task about investigating the >>>> possibility of a mono repo for Log4j to make things easier. We might be >>>> reaching the limits of Maven and/or IDEs here. I’d suggest going back to >>>> revisit the multiple repos idea, but that doesn’t handle the multiple >> JDK >>>> problem. I’m thinking of investigating what Spring Framework is doing to >>>> support this nowadays. >>>> >>>> On Sat, Jun 8, 2019 at 17:45, Volkan Yazıcı <[email protected]> >>>> wrote: >>>> >>>>> For the records, the very same frustration was my initial driver to >> start >>>>> working on log4j2-logstash-layout as a separate project. (That said, >> this >>>>> path led other advantages for the plugin.) I think this awkwardly high >>>>> entry barrier repels many potential contributors. Sometimes you just >> want >>>>> to fix a one liner, but end up throwing the towel once you figure out >> the >>>>> project does not even build properly in your IDE. Just my 2 cents... >>>>> >>>>> On Sat, Jun 8, 2019 at 10:33 PM Matt Sicker <[email protected]> wrote: >>>>> >>>>>> The maven config has gotten so complicated now that IntelliJ no longer >>>>>> knows how to compile anything or run tests. I've tried using Java 8 as >>>>>> a default JDK, but that leads to errors because IntelliJ doesn't >>>>>> recognize the java9 modules as using a different JDK. I tried manually >>>>>> changing those modules, but then I get some javac error with no error >>>>>> message. >>>>>> >>>>>> Next, I tried using Java 12 as the default JDK, but then came across >>>>>> an issue in a test that I fixed in master. Now I'm stuck trying to get >>>>>> the log4j-jmx-gui module to compile in Java 12 because jconsole.jar is >>>>>> now jdk.jconsole.jmod, and I can't find any docs on using maven to >>>>>> generate any JPMS stuff. >>>>>> >>>>>> To be clear, this all builds perfectly fine from the command line >>>>>> using maven directly. >>>>>> >>>>>> -- >>>>>> Matt Sicker <[email protected]> >>>>>> >>>>> >>>> -- >>>> Matt Sicker <[email protected]> >>>> >>> -- >>> Matt Sicker <[email protected]> >> >> >> -- > Matt Sicker <[email protected]>
