If you could put together a plan on our Wiki, that would be great. List all these items in a table, the files impacted, and a column for people to assign the task to themselves.
Gj On Fri, 5 Feb 2021 at 18:04, Eric Bresie <[email protected]> wrote: > I wanted to restate up front again, given the level of effort and resource > available, this is a long term activity not an overnight thing. > > Possible Benefit includes: > > 1. Sure there are other (1) that could provide other justification but > 2. Given the Java Cadence Lifecycle (LTS and interim versions) eventual > Java 8 will be deprecated and no longer officially supported unless > switch > dependencies to other sources and using older version > 3. Ability to leverage newer functionality with new release (a good > example was when using Java 8 was introduced, it was then possible to > leverage Streams and Lambdas to provide performance improvements [i.e. > more > integrated with multi core/process multithreading] > 4. By utilization of newer version, this may provide possible > resolution of netbeans issues with root causes associated with Java > issues > 5. Allows to stay in sync with the rest of the Java Library ecosystems, > i.e. allow newer dependency usages that provide newer java compatible > built > versions (i.e. module versions vs older no module versions) > 6. Allows usage of update with dependency security updates > 7. Allows usage of newer dependency bug fixes > 8. Addresses a wealth of "deprecated API" warnings > 9. Address a wealth of "source version" compatibility issues [ I recall > going forward source version was to start support backwards compatible > for > 1-2 source versions back after which something may not work whole > [assuming > use of newer version) > > Some additional tips below (2), (3), (4). > > References > (1) > > https://stackoverflow.com/questions/58992368/is-there-any-valid-point-upgrading-java-8-to-java-11 > (2) https://www.infoq.com/articles/upgrading-java-8-to-12/ > (3) > https://blogs.oracle.com/java-platform-group/upgrading-major-java-versions > (4) > > https://blogs.oracle.com/java-platform-group/upgrading-major-java-versions-technical > > > On Fri, Feb 5, 2021 at 10:24 AM Geertjan Wielenga > <[email protected]> wrote: > > > Stability is also a thing. Resources too, unless you’re volunteering? > > > > Gj > > > > On Fri, 5 Feb 2021 at 17:19, Randamuna Namae <[email protected]> wrote: > > > > > > What is the benefit of this? > > > > > > Project health. Bit rot <https://en.wikipedia.org/wiki/Software_rot> > is > > a > > > thing. > > > > > > Cheers > > > > > > On Fri, Feb 5, 2021 at 12:19 PM Geertjan Wielenga > > > <[email protected]> wrote: > > > > > > > What is the benefit of this? > > > > > > > > Gj > > > > > > > > On Fri, 5 Feb 2021 at 16:12, Eric Bresie <[email protected]> wrote: > > > > > > > > > Question on the Netbeans project's plan for moving forward towards > > > > > introducing and utilizing features with newer Java versions. > > > > > > > > > > I understand the basic expectations at present are mainly build on > > Java > > > > 8, > > > > > while being possible to build (with applicable flags or jdk > settings) > > > for > > > > > newer java versions. > > > > > > > > > > At what point do we need to take the plunge and start actually > using > > > some > > > > > of the new features for Java 9 and beyond? > > > > > > > > > > When compiling with new java, I see > > > > > > > > > > 1. references to deprecated or removed interfaces so assume that > > is > > > > one > > > > > thing that would have to be addressed. > > > > > 2. I see references to "source versions" (I saw one expecting > > server > > > > > version 1.4) which also show up. As I understand it, at some > > point > > > > the > > > > > general behavior in some of that will be to only support a few > jdk > > > > > version > > > > > back so assume this might be a case for other needed changes > [what > > > > > makes it > > > > > a specific version and is it as simple as changing the source > > > version > > > > in > > > > > the project details or build scripts]? > > > > > > > > > > Assume doing so would require changes like > > > > > > > > > > 1. Any "JDK" specific build details might have to be addressed > > > > > 2. Address depreciation and source version differences > > > > > 3. Find existing code which are candidates for refactoring with > > > newer > > > > > java features involved > > > > > 4. Maybe leverage some JDK tools or utilizing netbeans Java > > > > "refactoring > > > > > hints" for suggestions (i.e. changing loops to lambdas, utilized > > > newer > > > > > file > > > > > interfaces, etc.) > > > > > 5. Any dependency libraries would have to be updated with > > compatible > > > > > versions. This does have the added benefit of utilizing newer > > > > versions > > > > > in > > > > > these as well which may include performance, security, or bug > fits > > > > > benefits > > > > > as well. > > > > > 6. Update any documentation (i.e. build/runtime environments) > > > > > > > > > > Given the recent javadocs build issues requiring newer jdk, it may > > mean > > > > the > > > > > time is coming sooner rather than later. > > > > > > > > > > I know this would be a major bit of work but I wanted to raise the > > > > > question. > > > > > > > > > > Eric Bresie > > > > > [email protected] > > > > > > > > > > > > > > >
