int x, b, abc;)
Assuming that hidden classes (#2886) don't affect anything (I don't think it does, but I don't entirely understand the JEP), we can then formally tick javaparser off as supporting java 15... which would be rather nice! :D
After that, it's just records to go for java 16 support :)
@Betty-Wong However, I think it is useful to share experiences that were problematic.
Well, "problematic" for you. But why should I consider your personal interaction with somebody "problematic" for me? The whole thing is very novel to me. I use a lot of different open source tools in my work and the truth is that I almost never have any idea at all of the personalities of the various people who created those things. I honestly just never gave it much thought. To me, it is a very strange idea that I should decide on the tool stack to use in a project because of an opinion about a person I don't know, expressed by another person whom I also don't know. That, of course, is why I asked you whether you had any technical grounds for telling people not to even consider using JavaCC21. That's the question I'm interested in but you didn't answer it.
I use a lot of different open source tools in my work and the truth is that I almost never have any idea at all of the personalities of the various people who created those things.
Ditto. For the most part, the vast vast vast majority of people involved in open source are friendly -- OR, at the absolute least, civil. Being noticably offensive is (thankfully) the extremely rare exception within successful projects.
I think Linus Torvalds with the Linux kernel project is the only exception I can recall and that's only front of mind because it was in the headlines a short while back that he'd been forced to tone it down.
I wholly agree with you that the personality of the creators/maintainers of a project should normally not be noticeable.
... Which makes it extremely remarkable and a bit of a novelty when such offensive individuals make it onto the radar.
It is disappointing and shameful when someone is notable because of the way they interact rather than their technical ability.
Imagine, hypothetically, a project you use that is, on a technical consideration, extremely appealing... BUT it is extremely noticable that the maintainer is particularly hostile and offensive in reply to even the slightest bit of disagreement or (perceived) provocation.
Imagine if it then escalated to the point where absolutely foul language and hateful abusive emails are being sent, despite repeated requests to tone it down and pleas to keep it friendly/civil.
Imagine if it then escalated to the point that this individual actually goes ahead and registers domain names out of spite and continues the barrage of personal threats/insults.
For what reason would anybody continue to engage with somebody who is consistently like this and is consistently hard work to communicate with (e.g. one line email being returned with multiple essays, the content of which is often vile and offensive personal attacks)??
Most of us join open source communities (and then STAY) for the community. We do it for fun and gratification. There is (typically) no monetary reward. If it's not fun, don't do it. If you're snowed under at work or with family or whatever "real world" obligations and commitments you have -- whatever pays the bills and makes you happy absolutely MUST take priority. That is ever more relevant given the current global pandemic.
THAT is the reason several of us have such strong opinions about the project, despite being able to appreciate its progress on a technical level.
(I am inclined to think of this being analogous to boycotting a clothing company because of the vile views of it's owners re: oppressing LGBT rights or promoting child labour or bullying or some other horrid and offensive behaviour ---- even if the quality of the clothing (software) is technically amazing, I'm not going to shop there (use the software)... and if I feel particularly strongly I'll spread the word and encourage others to boycott that particular range of products (software) irrespective of how technically awesome it is)
@Nullableannotations? Specifically I'm curious about whether it's possible to create a custom annotation that "extends" another (thus creating a single place that it can be swapped out/changed), but general thoughts/comments/experiences would be welcomed :)
Optional. I introduced that a few years back, and I often wondered if it was a good decision. I think, by now, that I would prefer to replace all
Optionals with some kind of annotation. The only drawback is that you can't do fancy map/ifpresent stuff anymore.
Optionalusage and parameter null-checks did completely, 100% stamp out all null-pointer related issues. And there were a lot!