4 ms·

> but I could bet that most people will fix the issue by simply adding the "all-on" switch to the command line Definitely this. This is a dev experience proble

by usrusr 2y ago

> but I could bet that most people will fix the issue by simply adding the "all-on" switch to the command line Definitely this. This is a dev experience problem. > Unless maybe JDK 23 comes with some tool to print a catalogue of the annotation processors found in the classpath, with their respective purpose and documentation, so that developers can make an educated guess about what they need or don't need. My thoughts on as to how a solution to the dev-x problem might look like go in the same direction: have a way to provide a file with an accept list, another file with a deny list (vetoing accept list entries when matching both) and, this would be the key devx feature, a mode to automatically populate the accept list file from the full scan. Teams who'd be tempted to run the "all-on" mode could keep it running on auto-populate accept file, put the auto-populated accept file in versioning and see additions to the processor zoo in commits. And de-trusting a processor (or speeding up the build) would be as easy as copying a line to the deny file. Minor improvement that would probably come up at some point: the auto-generated accept file should better not automatically exclude entries exluded by the deny file so that replacing the deny with a subset from accept remains a straight-forward option, but chances are you might encounter some situations where some dev environments have a processor that other build environments don't have (this would not exist in a perfect world..) and that would cause undesirable changes to the auto-generated accept file. So you'd want a stronger deny option that forbids already during the scan, either with some special syntax in the deny file or (better I think) an optional file for "even higher priority deny". As to auto-generating documentation for the educated guess: clearly a trade-off between content and conciseness. My vote would be offering a way for processors that want to be helpful (or misleading, in the attack scenario!) to supply text for trailing line comments in the auto-generated accept file. For teams who do want to use the auto option. (trailing line comments are such an under-utilized magic compromise for conciseness/volume conflicts, probably because they aren't for readers running their editors with auto-wrap)

giamma 2y ago
With respect to auto-generating documentation, I was thinking about the possibility for annotation processors implementors to add javadoc comments or yet another annotation to their processor that JDK could use to dump a list of processors found in the classpath as a table with some information. > javac <other parameters> -proc:info some.library.Proccessor: scans classes annotated <whatever> and produces a file in META-INF/services for <some.library> to be able to load your implementation via ServiceLocator some.otherlibrary.OtherProcessor: ..... With that table creating your inclusion/exclusion files would be easier
pron 2y ago
> My thoughts on as to how a solution to the dev-x problem might look like go in the same direction: have a way to provide a file with an accept list, another file with a deny list I'm not involved with this particular change so I'm not familiar with its details, but when it comes to other changes restricting operations that involve extra risk (such as JEPs 260 and 472) the operations are enabled on a per-module basis and, as always, any part of the command line configuration can be easily put into configuration "@files". One thing to keep in mind is that such configurations should be kept simple because when things become complicated misconfiguration becomes common. Another thing is that restriction should be the default, especially in situations where most people don't need to disable it. Otherwise things may creep in without the application owner's knowledge (this is like transitioning between high and low entropy; it's always better to start at low entropy, as going in the other direction requires energy).

by usrusr 2y ago

giamma 2y ago

With respect to auto-generating documentation, I was thinking about the possibility for annotation processors implementors to add javadoc comments or yet another annotation to their processor that JDK could use to dump a list of processors found in the classpath as a table with some information. > javac <other parameters> -proc:info some.library.Proccessor: scans classes annotated <whatever> and produces a file in META-INF/services for <some.library> to be able to load your implementation via ServiceLocator some.otherlibrary.OtherProcessor: ..... With that table creating your inclusion/exclusion files would be easier

pron 2y ago

> My thoughts on as to how a solution to the dev-x problem might look like go in the same direction: have a way to provide a file with an accept list, another file with a deny list I'm not involved with this particular change so I'm not familiar with its details, but when it comes to other changes restricting operations that involve extra risk (such as JEPs 260 and 472) the operations are enabled on a per-module basis and, as always, any part of the command line configuration can be easily put into configuration "@files". One thing to keep in mind is that such configurations should be kept simple because when things become complicated misconfiguration becomes common. Another thing is that restriction should be the default, especially in situations where most people don't need to disable it. Otherwise things may creep in without the application owner's knowledge (this is like transitioning between high and low entropy; it's always better to start at low entropy, as going in the other direction requires energy).