sdedic commented on PR #5609:
URL: https://github.com/apache/netbeans/pull/5609#issuecomment-1476890956
let me share my overall opinion on this. In the *current state* of the
codebase, we *need_ nb-javac*. As JDK codebase continues to evolve, newer
versions of nbjavac are eventually released. Given there's *automated process*
for building nb-javac out of *upstream sources*, it's rather straightforward to
prepare a new build. We *are using* nbjavac to analyse user's sources AND we +-
support analysis by Javac itself given the IDE runs on the "correct" JDK.
I think we really want to ensure that "running on correct JDK" and "running
on possible JDK" (that implies nb-javac to supply the targetted JDK behaviour)
gives the same results, or *at least* does not fail, if the user switches
nb-javac for javac (or vice-versa). From this point of view, **I fully
support** integrating the PR and eventually running the tests **when a new
version of nb-javac** is included. I would assume that maintainer will continue
to update nbjavac as JDK team releases newer versions. Until that cooperation
works, we can easily keep the test.
There were several opinions voiced in the thread
> @mbien: nb-javac is optional if NB is run on the right JDK
I need to remind: people who *use NetBeans* to produce code (as opposed to
people *developing NetBeans*), and also people *using NetBeans as tooling
platform* have very different *business* requirements that require them to run
on just specific JDKs (even the IDE), and have hard requirements for the
tooling platform's environment (i.e. build machines in company cluster may have
some restrictions). I want to emphasize, is that it does not matter if that
requirement (for those groups of our users) is 'technically sound' or not -
they may exist for purely business, legal or security reasons - which may be
even silly, but impossible to revert from the developer seat.
If we *require* our users to "run on the right JDK" - such groups of people
may be forced to simply drop NetBeans completely and look for other options. If
we're lucky, mandating 'just the newest JDK' will be an unneccessary PITA. We
do not have that much 'spare users' that we can just throw these groups over
the board just because it makes NetBeans development more pleasant. Oracle's
Graal/Cloud team may be also affected by such approach.
So the assumption that 'everyone can use any JDK' so NB "runs on the correct
JDK" is IMHO wrong. I feel that the discussion emphasizes the importance of
development "our common pet project" (Apache NetBeans) too much and optimizes
for it, while deprioritizing our *users*. I happen to be
- NetBeans IDE developer,
- NetBeans IDE-based application developer: the Apache NB language server,
for example, but also the IdealGraphVisualizer from Graal is based on NetBeans
IDE *including* java support
- NetBeans platform - based application developer (my incubating personal
project).
Even as IGV maintainer, I often needed to compile+patch NB platform to trace
bugs, or even develop patches or small features for NB in order to make my
*real* project successful -- I do that routinely with maven and gradle (while
developing NetBeans). In all situations, having the *flexibility* to work with
development environment dictated by my business, rather than "obey NetBeans
dictate" is very helpful and makes dev's life a lot easier as there are other
pieces included with their own limitations. I will cover this in a separate
discussion related to "drop JDK8".
I believe that maintaining a bundled, well-tested compiler is a benefit for
those user groups with "strange requirements" - as long as the nb-javac keeps
releasing updated versions after its upstream releases. Now it does, so we
should act accordingly. At the same time, we can just plan for an exit
strategy, which may be fairly simple. We do not need to play what-if games
*now* to block a thing that would, for example, alert us when a problematic
change happens in some future JDK javac version.
>> @jlahoda : One advantage of having a firm compiler during build is less
dependence on specifics of the compile-time JDK.
> @matthiasblaesing: I think this is an academic discussion. If we can't
build with the current JDK, it is a bug that must be fixed.
I don't think this is not an academic discussion: I agree that when we
detect that our codebase is not compilable with new JDK, we should address that
SOON. But I do not see that as a valid argument for or against the discussed
change, rather as an unrelated test and policy that we should establish anyway.
As jlahoda noted, usage of "most updated" but bundled javac *allows* modern
optional modules to be written when the author decides he does not need (want)
to support older JDKs. In particular modules that require e.g. JDK17 APIs to
run. Doing so *without* nb-javac would require everyone working on NB codebase
to upgrade to JDK17 ... which is not an option (see above).
> @mbien : I do fear that this PR here is just bootstrapping the option for
a future switch to frgaal with the argument
It might. But a 'fear that something might happen' should not cause to block
a change just because "it might be extended in the future, maybe". You/we
should be aware of such extension may happen. Rejecting a purely 'piecemeal'
approach is a valid position, if it is the (only/major) supportive "argument"
if such proposal comes in the future.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
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
