[GitHub] [netbeans] sdedic commented on pull request #5609: nb-javac: "Eat your own dog food" testing

["sdedic (via GitHub)" <gi...@apache.org>]

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: notifications-unsubscribe@netbeans.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists