Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JDK9 and JDK7 build fixes #2

Merged
merged 6 commits into from
Mar 3, 2018
Merged

JDK9 and JDK7 build fixes #2

merged 6 commits into from
Mar 3, 2018

Conversation

javabrett
Copy link
Member

This incorporates the two upstream PRs:

The JDK7 build originally failed due to the non-availability of Oracle JDK7 in Travis Trusty, and OpenJDK7's missing crypto. This hacks its way around that. The JDK7 build is less important but may as well keep it for now and remove it later as required.

JDK9 changes require fixing the internal-package access. Please review that change heavily.

@henrik242 @wolfs @boris-petrov @woldie PTAL if you can and let me know if you can review.

@javabrett javabrett requested a review from henrik242 March 2, 2018 23:45
Copy link
Collaborator

@henrik242 henrik242 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I already use this patch in production, so yes, approved

@henrik242 henrik242 merged commit e25e8c9 into master Mar 3, 2018
@henrik242 henrik242 deleted the jdk9 branch March 3, 2018 00:09
@javabrett
Copy link
Member Author

@henrik242 my usual preference is for regular merge-commits, not rebase/squash/ff - thoughts?

@henrik242
Copy link
Collaborator

My preference is definitely to rebase. It gives a clean linear history and the commit log doesn't get cluttered with merge commits. But I'm pragmatic if you disagree :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants