Bananeweizen
@bananeweizen.github.io
passionate open-source software developer
https://github.com/Bananeweizen
https://github.com/Bananeweizen
You better would have googled "Yuxi circle" for your fact check. en.wikipedia.org/wiki/Valerie...
Valeriepieris circle - Wikipedia
en.wikipedia.org
July 6, 2025 at 9:51 AM
You better would have googled "Yuxi circle" for your fact check. en.wikipedia.org/wiki/Valerie...
mcuoneclipse.com/2015/03/29/s... gives you another Windows command interpreter without that limit. Not sure if more such projects exist.
Solving the 8192 Character Command Line Limit on Windows
There is a really annoying issue with using command line tools on Windows: the maximum length of the command line passed to cmd.exe is 8192 characters (see So you think this is not a problem for yo…
mcuoneclipse.com
March 7, 2025 at 7:36 AM
mcuoneclipse.com/2015/03/29/s... gives you another Windows command interpreter without that limit. Not sure if more such projects exist.
If you use AssertJ instead of JUnit 5 Assertions, then you can have custom assertions without any static utility class (rather one assertion class per domain class). And OpenRewrite can convert your assertions from one to the other.
January 31, 2025 at 6:53 AM
If you use AssertJ instead of JUnit 5 Assertions, then you can have custom assertions without any static utility class (rather one assertion class per domain class). And OpenRewrite can convert your assertions from one to the other.
Those are good practices, if you can enforce the IDE and CI/CD system will generate the same code, no matter what OS, custom developer settings, IDE version number etc. If you cannot guarantee this, version the generated code and raise an issue to make it reproducible.
January 13, 2025 at 2:56 PM
Those are good practices, if you can enforce the IDE and CI/CD system will generate the same code, no matter what OS, custom developer settings, IDE version number etc. If you cannot guarantee this, version the generated code and raise an issue to make it reproducible.
Didn't work well with company proxy when I tried it a while ago (but the project was very young then). sdkman doesn't really support Windows AFAIK, that's why I also watch this project. Star count is high, and there seem to be quite some Asian users, AFAICS.
January 5, 2025 at 4:18 PM
Didn't work well with company proxy when I tried it a while ago (but the project was very young then). sdkman doesn't really support Windows AFAIK, that's why I also watch this project. Star count is high, and there seem to be quite some Asian users, AFAICS.
Mine only seemed to work after removing the line break. But maybe it was just a matter of timing in the website publishing process of GitHub, so I might be wrong there.
December 31, 2024 at 10:14 AM
Mine only seemed to work after removing the line break. But maybe it was just a matter of timing in the website publishing process of GitHub, so I might be wrong there.
Important: Don't add line breaks in the atproto-did file, or the validation will fail.
December 31, 2024 at 9:51 AM
Important: Don't add line breaks in the atproto-did file, or the validation will fail.
not really knowing your domain, my initial thinking was "why not just stream()"? the value prefix sounds superfluous, unless there are several other fooBarStreams() methods
December 28, 2024 at 8:00 PM
not really knowing your domain, my initial thinking was "why not just stream()"? the value prefix sounds superfluous, unless there are several other fooBarStreams() methods
IMO the number of tails isn't important, assuming CI is automated. It's more important to reduce the number of backported changes. If a library would only fix security issues (like CVEs for itself and its dependencies), that should be very small. Not sure if I ever saw a secur. fix for AssertJ yet.
December 23, 2024 at 2:54 PM
IMO the number of tails isn't important, assuming CI is automated. It's more important to reduce the number of backported changes. If a library would only fix security issues (like CVEs for itself and its dependencies), that should be very small. Not sure if I ever saw a secur. fix for AssertJ yet.
For those who like video more than a long JEP text, nipafx explains this also in www.youtube.com/watch?v=ozUE...
Release Your (Java) Projects Like OpenJDK With Tip & Tail - Inside Java Newscast #79
YouTube video by Java
www.youtube.com
December 23, 2024 at 11:45 AM
For those who like video more than a long JEP text, nipafx explains this also in www.youtube.com/watch?v=ozUE...
Please read openjdk.org/jeps/14. It explains why it's not a good idea to have popular Java libraries all remain on old versions for compatibility with their large user base. It also suggests a way out. I encourage you to upgrade at least to 17 (better 21), so all the new Java features can be used.
JEP 14: The Tip & Tail Model of Library Development
openjdk.org
December 23, 2024 at 11:41 AM
Please read openjdk.org/jeps/14. It explains why it's not a good idea to have popular Java libraries all remain on old versions for compatibility with their large user base. It also suggests a way out. I encourage you to upgrade at least to 17 (better 21), so all the new Java features can be used.
I tend to add <𝚍𝚎𝚏𝚊𝚞𝚕𝚝𝙶𝚘𝚊𝚕>𝚟𝚎𝚛𝚒𝚏𝚢</𝚍𝚎𝚏𝚊𝚞𝚕𝚝𝙶𝚘𝚊𝚕> to all my projects, and document building it with 𝚖𝚟𝚗 without arguments.
December 22, 2024 at 12:09 PM
I tend to add <𝚍𝚎𝚏𝚊𝚞𝚕𝚝𝙶𝚘𝚊𝚕>𝚟𝚎𝚛𝚒𝚏𝚢</𝚍𝚎𝚏𝚊𝚞𝚕𝚝𝙶𝚘𝚊𝚕> to all my projects, and document building it with 𝚖𝚟𝚗 without arguments.
Might have a simple cause: There is absolutely no example in the main part of the AssertJ documentation. It's mentioned one time, but not shown. All other references are release notes. At least that's what I see using browser search on assertj.github.io/doc/
AssertJ - fluent assertions java library
assertj.github.io
December 21, 2024 at 7:36 PM
Might have a simple cause: There is absolutely no example in the main part of the AssertJ documentation. It's mentioned one time, but not shown. All other references are release notes. At least that's what I see using browser search on assertj.github.io/doc/
Thanks for explaining the background, now I understand. And again thanks for pointing to the other junit provider, I was not aware of that library, I only knew the file system implementation itself. Immediately helped to remove some of my selfmade extension code.
December 18, 2024 at 8:43 AM
Thanks for explaining the background, now I understand. And again thanks for pointing to the other junit provider, I was not aware of that library, I only knew the file system implementation itself. Immediately helped to remove some of my selfmade extension code.
Has there been a reason why you chose jimfs in your extension? I had the impression that github.com/marschall/me... is more actively maintained and supports more file related classes, but I might be wrong there.
GitHub - marschall/memoryfilesystem: An in memory implementation of a JSR-203 file system
An in memory implementation of a JSR-203 file system - marschall/memoryfilesystem
github.com
December 17, 2024 at 6:36 PM
Has there been a reason why you chose jimfs in your extension? I had the impression that github.com/marschall/me... is more actively maintained and supports more file related classes, but I might be wrong there.
That fits my experience of pasting URLs in the bluesky web client: immediately afterwards I cannot continue editing a post, because the input field is in LTR mode for no good reason. My workaround is to always add URLs as last action after writing all other text.
December 14, 2024 at 3:34 PM
That fits my experience of pasting URLs in the bluesky web client: immediately afterwards I cannot continue editing a post, because the input field is in LTR mode for no good reason. My workaround is to always add URLs as last action after writing all other text.
Build cache can make a huge difference for larger projects, and it's based on a formal definition of (input, task, output) tuples for all tasks. Neither the build cache extension from Maven itself nor from Develocity for Maven come close to that.
That said, I also prefer Maven.
That said, I also prefer Maven.
December 14, 2024 at 3:28 PM
Build cache can make a huge difference for larger projects, and it's based on a formal definition of (input, task, output) tuples for all tasks. Neither the build cache extension from Maven itself nor from Develocity for Maven come close to that.
That said, I also prefer Maven.
That said, I also prefer Maven.
It would not have helped with that specific issue, but enabling dependabot could reduce some of the update related work, as it also upgrades github action versions. (I've only checked the main asciidoctor repo, so I might be wrong about dependency upgrade automation in your repos)
December 4, 2024 at 9:18 AM
It would not have helped with that specific issue, but enabling dependabot could reduce some of the update related work, as it also upgrades github action versions. (I've only checked the main asciidoctor repo, so I might be wrong about dependency upgrade automation in your repos)
I don't like the "hiding" aspect of the shelving you suggest. Wouldn't it be sufficient to rather have (all) comments being _displayed_ in an order of priority in the review system (instead of order of file names), based on some tags in the comment or similar?
November 28, 2024 at 10:22 AM
I don't like the "hiding" aspect of the shelving you suggest. Wouldn't it be sufficient to rather have (all) comments being _displayed_ in an order of priority in the review system (instead of order of file names), based on some tags in the comment or similar?
Applications with huge dependency trees regularly break on stable updates, because not everything is part of the API/contract. That said, a somewhat similar idea is suggested for all of the Java eco system: openjdk.org/jeps/14
JEP 14: The Tip & Tail Model of Library Development
openjdk.org
November 24, 2024 at 6:38 AM
Applications with huge dependency trees regularly break on stable updates, because not everything is part of the API/contract. That said, a somewhat similar idea is suggested for all of the Java eco system: openjdk.org/jeps/14
I use a mixture of checkstyle IlegalImport/SingleLineRegexp and github.com/gaul/moderni.... modernizer includes premade signatures, but is harder to extend because it requires bytecode signatures, not source code signatures.
GitHub - gaul/modernizer-maven-plugin: Detect uses of legacy Java APIs
Detect uses of legacy Java APIs. Contribute to gaul/modernizer-maven-plugin development by creating an account on GitHub.
github.com
November 22, 2024 at 7:06 AM
I use a mixture of checkstyle IlegalImport/SingleLineRegexp and github.com/gaul/moderni.... modernizer includes premade signatures, but is harder to extend because it requires bytecode signatures, not source code signatures.
Depending on how/what you typically search, "everything" might be a good replacement www.voidtools.com It's instant when searching file names, but slower when searching file content.
voidtools
www.voidtools.com
November 19, 2024 at 3:33 PM
Depending on how/what you typically search, "everything" might be a good replacement www.voidtools.com It's instant when searching file names, but slower when searching file content.
Since it was only generated date time strings contained in some other output, and the date time strings were not relevant, I either just updated the expected value or reduced the assertion to the relevant part. The tips would surely have helped, if my code were about parsing instead.
November 16, 2024 at 5:01 PM
Since it was only generated date time strings contained in some other output, and the date time strings were not relevant, I either just updated the expected value or reduced the assertion to the relevant part. The tips would surely have helped, if my code were about parsing instead.
Now I finally get why some of our unit tests failed when switching to 21. I saw the difference in the space character, but didn't know the root cause. Thanks for teaching me.
November 16, 2024 at 4:50 PM
Now I finally get why some of our unit tests failed when switching to 21. I saw the difference in the space character, but didn't know the root cause. Thanks for teaching me.
That's a great presentation, covering some more than the "usual recommendations". Can you recommend some good introduction to the maven cache configuration (and concepts)? Not fully understanding that config is what lead to my experiments with the cache not being successful.
November 16, 2024 at 7:50 AM
That's a great presentation, covering some more than the "usual recommendations". Can you recommend some good introduction to the maven cache configuration (and concepts)? Not fully understanding that config is what lead to my experiments with the cache not being successful.