Community
Participate
Working Groups
In previous bugs regarding optional dependencies focus was on tolerating of those that are missing in the target platform, good. At the other end of the spectrum there's a risk of (unexpected) runtime failures if those optional dependencies are accidentally used in non-optional parts of my Java code. I suggest that PDE should define access rules to flag optionally accessible packages as discouraged. This gives users a chance to make an informed decision between avoiding the possibly-missing package or guarding that code section with error handling / fall back solutions. Ideally the resulting "discouraged" warnings should mention optionality as the root cause, but I haven't checked if such information can be transported via access rules. To make this a premium feature, optionality should be traced all the way through transitive (re-exported) dependencies, i.e., if any segment in the transitive dep path is optional, the target package should be discouraged.
If people agree on the idea, I might try to implement this during the 4.12 time frame.
>> a risk of (unexpected) runtime failures if those optional dependencies are >> accidentally used in non-optional parts of my Java code. Can you please attach a sample project/s demonstrating this problem?
Optional dependencies are also used for compile-time dependencies like Nullability or OSGi annotations. Implementing this feature via access rules would falsely flag those.
(In reply to Julian Honnen from comment #3) > Optional dependencies are also used for compile-time dependencies like > Nullability or OSGi annotations. Implementing this feature via access rules > would falsely flag those. We could possibly exempt annotations from this validation, OK? Unless those are retention=RUNTIME which makes them mandatory :)
