Re: Lets talk about JDK 8 (new year edition)
On 08.02.23 02:54, Neil C Smith wrote: On Tue, 7 Feb 2023 at 21:39, Michael Bien wrote: However, I got the feeling, sooner or later someone will want to have the platform again at a lower bytecode level than the rest of the IDE. I hope I am wrong and this never happens again. If this happens we can deal with this later, this isn't relevant for the immediate JDK 11 step since it is supposed to finally sync everything. Again? That is not the situation now. now am confused... we have tests on 8 and 11. We build on 11 with bytecode level set to 8. Some modules set it to 11. IDE runtime requirements say JDK 11. VSCodeEx dl page says it runs on 8 and later (but this thread showed that 11 wouldn't be a problem - which is excellent). What I hope from this discussion that there won't be any 8s in that paragraph above at some point in future. That is what I mean by "in sync". -mbien - 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
Re: Lets talk about JDK 8 (new year edition)
On Tue, 7 Feb 2023 at 21:39, Michael Bien wrote: > However, I got the feeling, sooner or later someone will want to have > the platform again at a lower bytecode level than the rest of the IDE. > I hope I am wrong and this never happens again. If this happens we can > deal with this later, this isn't relevant for the immediate JDK 11 step > since it is supposed to finally sync everything. Again? That is not the situation now. > platform to me is whatever comes out if you build: > ant -Dcluster.config=platform Platform applications are not limited to using the platform cluster. There are multiple platform applications I'm aware of that use modules from other clusters. Including one, possibly soon two, of my own. The distinction of platform vs rest of the IDE doesn't make sense to me, unless we decide to stop publishing the full range of modules as a framework for third parties to consume. > On 07.02.23 12:11, Neil C Smith wrote: > > https://github.com/apache/netbeans/blob/master/nbbuild/default.xml#L126 > > almost. > > once this is picked up everywhere and not every module sidelines it by > defining it's own source/target it would be covered by a property like > that yes. True, I realise this is a little more complicated. It just makes sense to me to concentrate module-specific settings for modules that need to opt out of JDK 11 bytecode level than opt in to it. > This has to be used for 'release' and not for source/target unless the > boot cp is set for example. The custom compiler ant task handles some of > it but not everything uses this task. Yes. Definitely something that needs looking at. Best wishes, Neil - 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
Re: Lets talk about JDK 8 (new year edition)
just to clarify: - I am for moving to 11 asap, and once we are there, to the next LTS as soon it makes sense (tests have to work etc). - I am for keeping everything in sync if possible since I am a big fan of keeping things simple. However, I got the feeling, sooner or later someone will want to have the platform again at a lower bytecode level than the rest of the IDE. I hope I am wrong and this never happens again. If this happens we can deal with this later, this isn't relevant for the immediate JDK 11 step since it is supposed to finally sync everything. platform to me is whatever comes out if you build: ant -Dcluster.config=platform On 07.02.23 12:11, Neil C Smith wrote: On Tue, 7 Feb 2023 at 00:46, Michael Bien wrote: there is no default configuration for source/target yet - that was just an idea. I thought that was covered by this? https://github.com/apache/netbeans/blob/master/nbbuild/default.xml#L126 almost. once this is picked up everywhere and not every module sidelines it by defining it's own source/target it would be covered by a property like that yes. This has to be used for 'release' and not for source/target unless the boot cp is set for example. The custom compiler ant task handles some of it but not everything uses this task. but NB will be probably there after 1-2 more PRs I hope. best regards, michael - 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
Re: tests question
Unit tests! Some examples here: https://netbeans.apache.org/tutorials/nbm-test.html On 7/2/23 10:40, name name2 wrote: Hello What type of tests do i need to make before PR? ant: test/test-basic/test-platform/other? - 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
Re: PRs and squashing
On 23/02/07 3:29 AM, Neil C Smith wrote: On Mon, 6 Feb 2023 at 17:28, Ernie Rael wrote: Here's my understanding: squashing and force pushing to a PR branch, in particular one that I opened, does not run into issues. Yes, you're all good. Note that by default, every committer has write access to your PR branch too. Yeah, I discovered that a while ago in a different project; quite a surprise, disconcerting. I leave the default, like a trust building exercise ;-) -ernie - 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
Re: Usage of DateTimeFormatter forbidden
Hi name name2, The statement that "Usage of DateTimeFormatter forbidden" is not correct. On 7/2/23 18:59, name name2 wrote: Hello https://github.com/apache/netbeans/pull/5445 SDT deprecated by fact of existing new java.time By SDT I understand that you mean SimpleDateFormat. The fact that you don't like SimpleDateFormat does not mean it's deprecated (nor that we "forbid" the usage of DateTimeFormatter, nor that we're going to change it everywhere in such a huge codebase). SDT isnt thread safe and required ThreadLocal. The most part of code is The fact that you've seen a "static SimpleDateFormat" somewhere does not mean that there's a thread issue. The static field can be used in a thread safe manner (on a single thread, for instance). Your evaluation of the problem is non existing. without TL or created new objects every request. Its doesnt effective and right way. Also TL required a lot of memory as i know and are not desirable because they complicate the logic. As explained in other threads, NetBeans is both an IDE and a platform. You can't change public APIs happily. All PRs that change the public NetBeans API (including the one you refer to) without previous discussion on the mailing list will be rejected. Also, as explained by other people in some other PRs, the advice to you is to discuss potential problems in the mailing list _before_ actually submitting PRs. By discussing I mean explaining a potential problem, not complaining because your PRs have been closed. Finally note that this is an open source project, not a programming contest where you're expected to show the world how well you program in Java. We're happy to have good Java programmers submitting PRs, but we also expect contributions to contribute value, to solve problems and to improve NetBeans, understanding what the problem is dinamically (more than statically), and not changing things because of personal preferences. Cheers, Antonio - 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
Re: Usage of DateTimeFormatter forbidden
Hi, Am Dienstag, dem 07.02.2023 um 20:59 +0300 schrieb name name2: > Hello > > https://github.com/apache/netbeans/pull/5445 > > SDT deprecated by fact of existing new java.time > SDT isnt thread safe and required ThreadLocal. The most part of code is > without TL or created new objects every request. Its doesnt effective and > right way. Also TL required a lot of memory as i know and are not desirable > because they complicate the logic. SimpleDateFormat is perfectly fine when you deal with java.util.Date. The formatter is also save if only accessed from a single thread. I would agree to switch if you'd need to introduce a ThreadLocal, but there is no evidence to suggest this. So i agree, that the referenced PR introduces noice without much benefit. Greetings Matthias - 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
Usage of DateTimeFormatter forbidden
Hello https://github.com/apache/netbeans/pull/5445 SDT deprecated by fact of existing new java.time SDT isnt thread safe and required ThreadLocal. The most part of code is without TL or created new objects every request. Its doesnt effective and right way. Also TL required a lot of memory as i know and are not desirable because they complicate the logic.
Re: PRs and squashing
On Mon, 6 Feb 2023 at 17:28, Ernie Rael wrote: > There were some comments about squash/merge and how github/git commands > have issues going directly to main. I got confused because I missed the > "to main" versus "to PR branch" distinction. Yes, sorry if I added to that confusion. The squash and merge UI in GitHub causes us a number of problems. Aside - the squash and rebase options should probably be disabled in .asf.yaml My comment was that committers squashing and merging locally and pushing directly to master causes us a bunch of different problems. Resolving merge conflicts is the same too - GitHub UI can cause problems / doing locally and pushing directly to master can cause problems. Ideally everything goes through the PR branch. > Here's my understanding: squashing and force pushing to a PR branch, in > particular one that I opened, does not run into issues. Yes, you're all good. Note that by default, every committer has write access to your PR branch too. I tend not to force push to other people's PR branches without checking first though! :-) > And from my perspective, as someone who never pushes to master, I can > ignore issues relating to peculiarities around local squash and merge > pushed directly to master. Yep! Best wishes, Neil - 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
Re: Issue management issues (meta-issues?!)
On Tue, 7 Feb 2023 at 01:51, Ernie Rael wrote: > I think "NeedsTriage" has a meaning beyond that someone has made a comment. > How about "NeedsTriage" can only be taken away when either "Bug" or > "FeatureRequest" or ??? is added. "Bug" or "Feature Request" labels are added depending on which form the user fills out. They're not a useful trigger. Adding additional labels might be. Although I sometimes label issues without responding so they're visible to other committers with more knowledge in that area. I agree that need:triage implies more than a comment, but the idea was that the issue ends up in one of 3 states after a committer has commented (or at least considered) - valid, invalid or needs more information. Best wishes, Neil - 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
Re: Lets talk about JDK 8 (new year edition)
On Tue, 7 Feb 2023 at 00:46, Michael Bien wrote: > there is no default configuration for source/target yet - that was just > an idea. I thought that was covered by this? https://github.com/apache/netbeans/blob/master/nbbuild/default.xml#L126 > again: if we can do everything in one go -> even better +1 - we're saying the same thing here. > Platform is a lib, the IDE is a tool/product. The distinction will > likely always cause some friction in runtime requirements. And platform is a cluster. Which is where some confusion is coming from I think? Additional consumers of our APIs, be it in RCP applications or other usages of our Maven libraries, are not necessarily limited to just the platform cluster. The current policy we have on this didn't special case the platform cluster as such, just that all modules requiring JDK 11 are optional (and at the time not required by the VSCode support) > Not a lot would prevent us to require JDK 21 for the IDE once it is out > some time in future (assuming tests work). But I imagine there will be > resistance to do the same for the platform. That depends what you mean? Does this again mix definitions of platform between the cluster and APIs consumed by others? We should have one approach that covers all clusters. Which doesn't mean we couldn't approach JDK 21 in a soft / optional modules way, like we're currently doing with JDK 11. There was a conversation a while back around the VSCode that included something like NetBeans as a collection of tools built on a common framework. I wonder whether we need different words here to describe the collections of APIs (framework?) and the platform cluster? > opt-ins can be trivially removed with search and replace once the > default is bumped. This shouldn't be the reason to stop an IDE module > from requiring JDK 11 for another year. > > We would have to do this anyway since there would be already opt-ins to > remove once we add a default config due to already existing modules > which require JDK 11. > > What is your concern? Why another year? I'm actually suggesting we at least try to bump everything to JDK 11 when NB 18 has branched, so in a couple of months. If anything I'm suggesting we consider bumping to JDK 17 in a year, or at least give ourselves that option. > >> No reason not to try. This is also one of the more time consuming tasks. > >> Since you have to run a full build and then check via a script that none > >> of the class files suddenly starts having their version set to 65. > >> > > Good job we have a test for that already then!here > > it is very rudimentary > > https://github.com/apache/netbeans/pull/5122#issuecomment-1359902237 I meant https://github.com/apache/netbeans/blob/master/platform/o.n.core/test/qa-functional/src/org/netbeans/core/validation/ValidateClassFilesTest.java This runs as part of commit validation IIRC - I had to update it to get our first JDK 11 compiled module PR (disco) to pass - it was hardcoded to JDK 8 before then. Best wishes, Neil - 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
tests question
Hello What type of tests do i need to make before PR? ant: test/test-basic/test-platform/other?
