Add useOptionalForGetters option for Java 8 java.util.Optional on getters

[holsky]

This is just a draft - I would like to get some comments from you on the initial direction. Would it work this way or am I on the wrong track?
And is there a good reason why there are no tests for PropertyRule? (If not I'd implement a few happy path tests).
Fixes #342

[holsky]

and well - can you think of a way to implement this without breaking java 7 compatibility? :-)

[joelittlejohn]

I think there are ways :) I haven't had a chance to look through this yet,
but I believe there would be ways to achieve this using Code Model without
directly introducing a dependency on Java 8 in the plugin (slightly awkward
but still possible).
On 2 May 2015 20:35, "Holger Schmeisky" [email protected] wrote:

and well - can you think of a way to implement this without breaking java
7 compatibility? :-)

—
Reply to this email directly or view it on GitHub
#344 (comment)
.

[joelittlejohn]

This PR is incomplete and stale. I'm closing this as I don't believe it's going to be completed, but we can use these changes for reference in the future.

[EitZei]

@joelittlejohn I would really appreciate this feature and would be willing to work the get it included. What did you feel was missing from the earlier pull request?

[joelittlejohn]

@EitZei Do you have some thoughts about how to implement this without breaking Jav 7 compatibility?

[joelittlejohn]

Maybe we should cut a 1.0 version of this library for Java 8 and drop Java 7 support going forward. There are a load of things we would do differently in the generated code if we were target Java 8 and later I think. Many modern Java constructs can't be supported by CodeModel though (the library we use to create .java files) so maybe we should also try to move to something else.

I've recently found https://github.com/square/javapoet but I'm also not sure how well this library supports either Java 7 or Java 8 constructs.

[joelittlejohn]

@EitZei If you really do need this feature (and soon), you should consider building your own version of jsonschema2pojo that has this PR merged.

[EitZei]

To my limited understanding this PR is already Java 7 compatible after the https://github.com/joelittlejohn/jsonschema2pojo/pull/344/files/8b5a566c514d81f7976747db6468904265cd3e96..HEAD amendment which makes the dependency to java.util.Optional to be just a String reference.

[joelittlejohn]

Ha, you're right. I actually didn't notice that update to the PR.

[EitZei]

Given this information would you be willing to merge this PR?

[joelittlejohn]

Yes, I think this can be merged. I might change the config property name here but other than that I think this can be included in the next release.

[joelittlejohn]

There's a bit more required here. This currently only supports the older required syntax of specifying a boolean inside the property schema. Before we support this we'll have to also support the newer syntax of specifying an array of property names (that are required properties) in the object schema.

[holsky]

Nice to get a visit from the past. I completely forgot how the traversal works, but I would either

1. access the parent node and get the required fields and check if this one is contained or
2. pass the required fields down as a parameter maybe in the jclass

which one do you think is better?

[holsky]

@joelittlejohn I copied the approach from NotRequiredRule to just loop through the required list.

I did not include this in ScalaGen, is your goal to have feature parity?

[holsky]

@joelittlejohn let's not make the same mistake twice :) when do you think you will have a chance to look at it?

[holsky]

oh no @joelittlejohn it's happening again :) is there anything I can do to help you merge this?

[joelittlejohn]

Let's do this 👍

[EitZei]

Awesome work @holsky and @joelittlejohn! Any plans on making a new release?

[joelittlejohn]

@EitZei the awesome work is all @holsky 😄

Another major change that has been merged recently is the move away from commons-lang to 'native' Java implementations of toString, equals and hashCode. I think I'll release an alpha/beta soon because I'm slightly concerned that some of the recent changes may have some unexpected consequences.