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 <geertjan.wiele...@googlemail.com.invalid> wrote: > Stability is also a thing. Resources too, unless you’re volunteering? > > Gj > > On Fri, 5 Feb 2021 at 17:19, Randamuna Namae <ioniv...@gmail.com> 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 > > <geertjan.wiele...@googlemail.com.invalid> wrote: > > > > > What is the benefit of this? > > > > > > Gj > > > > > > On Fri, 5 Feb 2021 at 16:12, Eric Bresie <ebre...@gmail.com> 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 > > > > ebre...@gmail.com > > > > > > > > > >
