It's too bad there are no NetBeans specific statistics, both IDE and
platform.
It sure would be nice if there were some reference to stats on jdk
version usage
in these deliberations.
What I've seen in reports, the most recent I've found from mid 2022,
even though Java 11 had been available for more than a year. Since
then, the balance has shifted between these two LTS release versions.
More than 48% of applications are now using Java 11 in production (up
from 11.11% in 2020) with Java 8 a close second, capturing 46.45% of
applications using the version in production.
Java 17 has not climbed the charts, but in the handful of months since
its release, it has already surpassed the Java 6, Java 10, and Java 16
releases. [3]
Most reports show 8/11 neck and neck, with expectations that 11/17 continue
to increase share. [2], [3], [4]. Are there more recent reports around?
Something that seems to be missing from the conversation is an /Apache/
/NetBeans Mission Statement/ (or I just haven't seen it). That would include
who are the target users and with what priorities? Professionals,
Hobbyists,
Educators? A more detailed breakdown might be appropriate. And of course
IDE vs Platform considerations.
-ernie
[1]
https://www.stackchief.com/blog/Which%20Version%20of%20Java%20Should%20You%20Use%3F
[2]
https://sdtimes.com/java/report-percentage-of-oracle-jdk-distributions-in-java-ecosystem-drops-significantly/
[3] https://newrelic.com/resources/report/2022-state-of-java-ecosystem
[4]
https://www.infoworld.com/article/3652408/java-8-still-dominates-but-java-17-wave-is-coming-survey.html
On 23/02/08 8:38 PM, Jaroslav Tulach wrote:
NetBeans isn't just an IDE, but it is a framework!
When designing frameworks and libraries that shall be widely adopted it is
important to increase portability as much as possible. If an API can be used
on different systems, different configurations, the amount of users including
such API in their applications grows.
The best way to hurt portability is to depend on a 3rd party API that isn't
portable. Depending on Win32 API is one such example. Of course, writing in
Java (a language designed to write once and run everywhere) greatly increases
portability. However there is another axis hurting portability - the supported
JDK version. Of course, should a library be widely used, it has to support as
oldest JDK as possible. These days it is JDK8 - the primary reason being that
Android supports JDK8 - as such, should a library be aspire to be used on
Android (as well as regular Java), it needs to stick to version eight. Btw.
not that many years ago, Android only supported JDK6 and many libraries had to
stay with JDK6 APIs and language.
Supporting the ancient JDK gives the application writers using such library or
framework a freedom to choose their JDK. The application writers can then run
on oldest or newest JDK. That's the kind of freedom they want. However there's
transitivity of non-portability - the portability of the final application
cannot be bigger than portability of the least portable library used. This
applies also to 3rd party dependencies a framework or library has: again their
non-portability may negatively affect portability of such framework or library.
I was my NetBeans libraries to be as portable as possible and also run on
Android. I want to use `Lookup` & co.
-jt
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail:dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
