Is it worth starting a confluence page to start documenting what is necessary when upgrading between JDK versions?
Assume it would have have to consider things like: 1. Update project property files to identify jdk requirements (i.e. target, resource, release) 2. Update (ant) build scripts where applicable 3. Update build testing to account for JDK specific testing where applicable 4. Update dependencies (i.e. if compiled to a specific JDK version, may require updated dependencies) 5. If JDK depreciates/removes a given API, recommend raising a issue to plan for eventual rework to address this (i.e. replace with new API or new dependencies) 6. If any updates impact Netbeans APIs, update api version files 7. Update documentation pages to identify compatible JDK to Netbeans (assume this may be implied on a given release page but not sure a "compatibility specific page" exists and/or is needed to track this to account for JDK for build and JDK supported in Netbeans,etc.) 8. Account for nb-javac updates as applicable 9. Update any hints/autocompletions (may be addressed by other places lib nb-javac) to help in adding/refactoring with new JDK support 10. Start introducing JDK version specific functionality as needed (i.e. with JDK 8 add lambdas, JDK 9 add modules, records, etc.) where applicable (note: when introducing new feature this will impact above jdk properties mentioned earlier) I'm sure there is more (including the details) but it seems a good place to start to make doing so in the future a little easier. Eric Eric Bresie [email protected] On Sat, Jan 15, 2022 at 4:15 AM Neil C Smith <[email protected]> wrote: > On Sat, 15 Jan 2022 at 05:25, Jaroslav Tulach <[email protected]> > wrote: > > út 11. 1. 2022 v 13:54 odesílatel Neil C Smith <[email protected]> > > > Anyone know if there's a non-hacky way to exclude a module from being > > > included at all if building the IDE on JDK 8? > > > > There was an agreement to require JDK-11 to build NetBeans code. > > I know! :-) However, unfortunately there are a few edge cases in > release-related tasks, not to mention tests right now, that make > dropping the ability to build on JDK 8 a little problematic. > > I was hoping to get something in NetBeans 13 that requires --release > 11, but that will have to wait until 14 now. Too close to branch > anyway. > > > Our tests shall continue to run on JDK-8. There was no consensus to move > > away from JDK-8 when running tests, as far as I can tell. > > Build on 11, test on 11, 17 and 8 - IMO in that order of priority > though. JDK 8 was where required and infrastructure can handle it. > That might mean moving some identified testing to a daily thing, > manual trigger or path based triggers. There are ASF resource > limitations to consider across GitHub, Travis and Jenkins here. > > > The ideal setup is shown at > > > https://github.com/apache/netbeans/blob/master/.github/workflows/ensure-jdk8.yml > > Yes, I've seen, and thanks for that. Although there are other > potential ways to do this I'm exploring too. I started looking at > updating testing, but waylaid by other things. Hopefully between > 13-rc1 and 13-rc2 we can get some additional changes in, in case > there's anything to pick up before release. > > > E.g. build with JDK-11, but test on JDK-8. That's what needs to happen to > > all CI jobs, before one can use `--release 11`. > > Yes, that was the thing I was hoping we had a way to short circuit. > Which I guess we have if we did something like > org.openide.util.enumerations and leave the jar empty. May even be > benefits in the short term to taking that approach. > > Best wishes, > > Neil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
