Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Support a true "java8" option #5864

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

Merged
wing328 merged 9 commits into swagger-api:master from Randgalt:add-java8-option
Jun 29, 2017
Merged

Conversation

@Randgalt
Copy link
Contributor

@Randgalt Randgalt commented Jun 17, 2017
edited
Loading

PR checklist

  • Read the contribution guidelines.
  • Ran the shell/batch script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates)
  • Filed the PR against the correct branch: master for non-breaking changes and 2.3.0 branch for breaking (non-backward compatible) changes.

Description of the PR

The "dateLibrary" option for java, sadly, sets a mustache value "java8". This change updates this so that "java8" in the mustache libraries means what it should mean - use all java8 classes. In this case, there's no need for the third party Base64 library as java8's JDK has this built in. In my view, the "dateLibrary" value "java8" should be deaprecated but that should be a separate PR.

The "dateLibrary" option for java, sadly, sets a mustache value "java8". This change updates this so that "java" in the mustache
libraries means what it should mean - use all java8 classes. In this case, there's no need for the third party Base64 library
as java8's JDK has this built in. In my view, the "dateLibrary" should be deprecated but that should be a separate PR.
if(additionalProperties.containsKey(JAVA8_MODE)) {
setJava8Mode(Boolean.parseBoolean(additionalProperties.get(JAVA8_MODE).toString()));
if ( java8Mode ) {
additionalProperties.put("java8", "true");
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, maybe also put the false value in the other case? (Or just additionalProperties.put("java8", java8Mode.toString());)

By the way, why are you using "java8" here and not JAVA8_MODE?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well - it was used below. I'll change it.

Copy link
Contributor

ePaul commented Jun 17, 2017

You indicated in the PR comment that you updated the samples, but I don't see any changed samples. Are there no changes?

Copy link
Contributor Author

You indicated in the PR comment that you updated the samples

I ran the script - maybe I did something wrong? I'll check.

Copy link
Contributor

cbornet commented Jun 17, 2017

Can you check if it's not already fixed on branch 2.3.0 ? A jsr310 flag was introduced to distinguish dates and jdk.

Copy link
Contributor Author

@cbornet I checked branch 2.3.0 and I see threetenbp but that's still only applies to the dateLibrary. This PR is focused on using Java8 classes everywhere. In this instance, there's no need for the 3rd party Base64 library as that's builtin to Java 8 now.

This PR also "takes ownership" of the java8 mustache variable. IMO that should not have been used to denote which dateLibrary you want to use.

Copy link
Contributor

cbornet commented Jun 18, 2017

Copy link
Contributor Author

@cbornet I guess I'm not conveying the point of this PR. This is not about the date library. This is for Java8 classes in general. Base64 is part of the Java 8 JDK now. There is no longer any need to import a third party library for this purpose.

Copy link
Contributor

cbornet commented Jun 19, 2017

@Randgalt OK. Then I don't think we need yet another option (we already have too many) there should be only "java8" option for which we can use Base64

Copy link
Contributor Author

@cbornet this not a new option. This PR takes the "java8" mustache variable that is set by dateLibrary and uses it to mean what it implies: use java8 classes where needed. The only thing new is a CLI option to set "java8" - this is needed because it no longer makes sense to have "java8" set by dateLibrary (that part should be deprecated).

Copy link
Contributor

cbornet commented Jun 19, 2017

@Randgalt oh right, I misread your PR 😄 !
Then LGTM

clientCodegen.setUseBeanValidation(Boolean.valueOf(JavaClientOptionsProvider.PERFORM_BEANVALIDATION));
times = 1;
clientCodegen.setUseBeanValidation(Boolean.valueOf(JavaClientOptionsProvider.PERFORM_BEANVALIDATION));
times = 1;
Copy link
Contributor

Choose a reason for hiding this comment

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

This duplication looks wrong. I guess you wanted to check for JAVA_8?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Doh - copy/paste error. I'll fix it.

Copy link
Contributor Author

Second time. Not sure what to do:

[ERR!] GitHub API: GitHub rate limit reached.
 To increase the limit use GitHub authentication.
 See: https://github.com/DefinitelyTyped/tsd#tsdrc

Copy link
Contributor

wing328 commented Jun 27, 2017

@Randgalt I've restarted the Travis job. If it's still failing, I'll test locally.

Randgalt reacted with thumbs up emoji

Copy link
Contributor Author

ping

Copy link
Contributor

wing328 commented Jun 29, 2017

Test results after sample update are good: https://circleci.com/gh/swagger-api/swagger-codegen/518

@wing328 wing328 merged commit b2efb70 into swagger-api:master Jun 29, 2017
@wing328 wing328 added this to the v2.2.3 milestone Jun 29, 2017
Copy link
Contributor

wing328 commented Jun 29, 2017
edited
Loading

@Randgalt PR merged into master. Thanks for your contribution.

I wonder if you can make the same enhancement to 2.3.0 branch as I got some merge conflicts syncing master into 2.3.0.

Copy link
Contributor Author

@wing328 sure

Copy link
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer

@ePaul ePaul ePaul left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

v2.2.3

Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /