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

Anyone working on a Java version? #348

Open
shaqq opened this issue Apr 12, 2019 · 7 comments
Open

Anyone working on a Java version? #348

shaqq opened this issue Apr 12, 2019 · 7 comments

Comments

@shaqq
Copy link

shaqq commented Apr 12, 2019

I was planning on making a holidays package that'd work with JVM languages. Do you know of anyone working on something like that? I figured I'd ask before duplicating work.

@ppeble
Copy link
Member

ppeble commented Apr 13, 2019

Nope! As far as I am aware there are no other languages in any form of development outside of the existing ruby version and the golang version that I started but haven't completed.

If this is something you are interested in I would be happy to provide feedback, reviews, answer questions about the definitions, etc etc. Feel free to reach out!

@ppeble
Copy link
Member

ppeble commented Apr 13, 2019

Oops, I should have said this explicitly: if you are writing a package and would like it available under the holidays organization then we can definitely discuss this! I would love for there to be a ruby version, a golang version, a java version, etc that all consume the same core YAML definitions. 😄

@ttwo32
Copy link
Member

ttwo32 commented Apr 14, 2019

@ppeble I agree your thoughts.
This is good challenge!!

@shaqq
Copy link
Author

shaqq commented Apr 15, 2019

@ppeble Yep, that would be amazing! The thing I'm trying to sort out is how to test all the versions against each other to make sure they're all outputting the right holidays. There's some weird things to sort out, because if there's a bug in one, you'd have to fix all of them. Or, at least, make a github issue for the discrepancies? I'm not sure quite yet.

@ppeble
Copy link
Member

ppeble commented Apr 17, 2019

@shaqq I've had similar thoughts! My thinking on this is basically 'each language has to be responsible for itself'. We would have the central definitions and then each language repository would then just do its own thing, update on its own schedule as the maintainer(s) saw fit.

This approach has the benefit of allowing for maximum flexibility...if the golang version went without an update for 6 months but the java and ruby versions were updated multiple times then that is still overall a good thing! But the downside is exactly what you laid out: it would be possible for discrepancies.

One other thing that occurred to me while I was typing this: each language version doesn't need to exactly match the API methods available in the other versions! For example, the ruby repo has core extensions and that idea doesn't really apply in any way to a potential golang version. It could be that v1.0.0 of the golang version has slightly different methods but consumes the same underlying definitions. I personally think that would be just fine!

I actually have a few more ideas on how we can mitigate discrepancies/issues (such as this automated test idea in the definitions repo) but honestly at this early stage simply getting a java version stood up and consuming the definitions would be a huge win. That was my goal with the golang version before my work stalled because of life commitments. I was going to worry about discrepancies only after I had multiple languages consuming them. 😄

@shaqq
Copy link
Author

shaqq commented Apr 17, 2019

@ppeble Yeah, I definitely agree that each language library should be idiomatic to their language conventions and not uniformly dogmatic.

There should be some way, somehow, to output something common amongst all of them. Even if it's just a huge file that's a sequence of strings, like:

{region}, {holiday_name}, {bunch_of_other_things_about_holiday}
// another, and another, and so on...

It's probably better to be something structured, like JSON or something. But as long as we're using the library code to transform the YAML definitions into something else using the library's APIs, we should be able to just compare them in a simple spec and yell if there's a diff. I'm semi-positive we can use Github Checks to make sure this works.

For the Java version.... to be honest, I was just thinking about using JRuby to output a jar. But I gotta futz with it first

@shaqq
Copy link
Author

shaqq commented May 10, 2019

@ppeble Have you been able to figure out how to do custom methods w/ the golang version? Trying to sort out in my head how we'd do it in Java....

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

No branches or pull requests

3 participants