I haven't looked too far into what's required yet, and I also have very limited experience with any Java that isn't 8. Based on what I have seen, there appears to be a new "module" based system for organizing packages that might require some changes to how TR is built/structured.
Also apparently there are no more JRE downloads, and instead the runtime is baked into the application. Not sure if/how that will affect TR. I'll look more into it once this Sun library issue is out of the way. But besides what Zach mentioned, I don't foresee any other changes to TR as part of these PRs. -- Joshua Zenn On 9/18/20, 11:34 AM, "Eric Friedrich" <[email protected]> wrote: I think this is a great improvement for Traffic Router. Other than the sun.security, what changes to code structure or syntax should we expect from this PR? I’d echo ocket8888s comment that replacing sun.security should not be grouped together with the Java 11 upgrade. Might be useful to remove sun.security first and then a second one for the Java upgrade --Eric On Fri, Sep 11, 2020 at 6:25 PM ocket 8888 <[email protected]> wrote: > > IMO refactoring to remove sun.security.* usage is enough of its own thing > to warrant its own PR > > I agree, especially since replacing it with a 1:1 package mirror of sorts > doesn't seem like the best way to go about it. From cursory searching it > seems like it java.security is supposed to be a functional > superset/equivalent to sun.security, just not a drop-in replacement. That > could be wrong; I'm not a Java guy, but it sounds as though you should be > able to do whatever you need to do without relying on a specific provider. > > On Fri, Sep 11, 2020 at 1:45 PM Zach Hoffman <[email protected]> wrote: > > > > 2. Use a third-party library. Some third-library parties offer partial > > replacements of the namespace (e.g. BouncyCastle). > > > > For the cases where java.security.* alone is not sufficient, do we need > > anything outside of org.bouncycastle.jce.provider? That's been a > dependency > > since https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/commit/6ebd7a428f__;!!Hit2Ag!hjGng0Fy-U2BXrLwwHz7LlqTpsBotUTbSLJ9gqeDKPX-WgFfJVQwTTyyAlmGUuAq$ , so we > > already have that at our disposal. > > > > > 3. Custom implementation. We could just mirror the functionality of > the > > ‘sun.security.*’ namespace within the ATC codebase. While it gives more > > fine-grained control, the ATC project is now responsible for maintaining > > certificate management code and other things that are irrelevant to the > > main focus of the project. > > > > I'm -1 for rolling our own crypto > > > > IMO refactoring to remove sun.security.* usage is enough of its own thing > > to warrant its own PR before anything Java 11-related. Super excited to > see > > this project, Java 11 will mean new language features and a performance > > boost. > > > > -Zach > > > > > > On Fri, Sep 11, 2020 at 11:52 AM Zenn, Joshua (CCI-Atlanta) < > > [email protected]> wrote: > > > > > Hello! I’ve been working on upgrading ATC Traffic Router to use Java 11 > > > LTS from Java 8. I’ve come across an issue, and it was proposed that it > > be > > > presented here for an official consensus on how to move forward. > > > > > > As of Java 9+ the ‘sun.security.*’ namespace has been made > internal-only, > > > which a fair amount of TR certificate management code relies on. Up > > through > > > Java 8 Oracle has stated that the package was for internal use only, > but > > it > > > was publicly accessible by other namespaces. Based on my research so > > far, I > > > found that other projects have taken one or more of these paths to > > resolve > > > this issue: > > > > > > 1. Hack some compiler options to manually include the > ‘sun.security.*’ > > > internal package again. This is not recommended by Oracle and has the > > > possibility of being broken on any given Java update, but it is the > > fastest > > > to implement and will have the least impact on the codebase. > > > 2. Use a third-party library. Some third-library parties offer > partial > > > replacements of the namespace (e.g. BouncyCastle). The trade-off is > that > > we > > > would lose some fine-grained control over certificate loading (which > > might > > > affect other ATC components). This option may also introduce some > > licensing > > > issues. Finally, this would require an overhaul of the cert part of the > > TR > > > codebase. > > > 3. Custom implementation. We could just mirror the functionality of > > the > > > ‘sun.security.*’ namespace within the ATC codebase. While it gives more > > > fine-grained control, the ATC project is now responsible for > maintaining > > > certificate management code and other things that are irrelevant to the > > > main focus of the project. > > > > > > A great suggestion that was given by Zach Hoffman in Slack was to use > the > > > ‘java.security.*’ namespace. This would resolve some of the missing > > > classes. However, the namespace is not a 1:1 implementation of > > > sun.security.*, so the remaining missing classes would need to be > > resolved > > > using one of the above methods (or any new ideas that can be > suggested). > > > > > > -- > > > Joshua Zenn > > > > > >
