Just remove this paragraph, it is describing internal details of a different library.
Also, defaults are never acceptable for production in this case; defaults are for testing and development; con...
Just use the override with defaults for this class; it's not a production class.
In the production classes we'll _always_ set file and folder permissions, which should _not_ have a default outside...
We shouldn't be digging into commons for constants, any constants we need belong in this module.
That said, there should not be defaults for file or folder permissions. Those need to be in config...
That's the rest reviewed.
Let's chat about this code, as there are obviously some gaps in terms of understanding why some things are written the way they were.
That's the rest reviewed.
Let's chat about this code, as there are obviously some gaps in terms of understanding why some things are written the way they were.
All changes to this file are incorrect.
You are re-introducing a severe design flaw by merging the permissions types, and the constants are not supposed to be public _for good reason_.
This is bad practice.
1. Copying a constant to a class attribute is an anti-pattern
1. Using a remote default constant when an overload exists to apply defaults _internally_ to the library is an ...
Generally, prefer to _not_ static import methods. It costs little to write `FileUtilities.readFileBytesUnsafe` and is _much_ easier to read and understand without having to simultaneously retain a...
This file should actually be retained.
These constants are specific to the simulator and should be passed to the methods in common, rather than relying on defaults in that module.
We didn't leave...
This was correct as it stood, there is no reason to reformat the line.
The use of `var` was deliberate to avoid an unnecessary line break.
The only reformatting we should be doing is via `./gradl...
I do not believe this is a good change, generally you had to use a Path to get the File in the first place, and it's better to pass in the Path rather than converting the Path to a File and back to...
Same here, do not try to align descriptions.
For Javadoc, we should use one space after the parameter _name_, and 4 space indentation(only) on subsequent lines.
note, if your IDE is doing this,...
Please, please, please do _not_ start this horrid pattern. There is no reason to use aligned indentation here, and it's ridiculously costly as people have to constantly reformat lines for simple v...
It appears you ran an IDE reformat on these files without disabling a lot of very bad defaults. It's important to keep in mind that most IDEs do not, and often cannot, correctly format the codebas...
It appears you ran an IDE reformat on these files without disabling a lot of very bad defaults. It's important to keep in mind that most IDEs do not, and often cannot, correctly format the codebas...
None of these extensions is likely to remain in place forever. The whole point here is to have a method that accepts parameters for file extensions and offer a sane default via an override. The v...