java: Make it more clear which exercises can't be implemented for Java

There are a few exercises that can’t be implemented for Java: leap, grains and say. See issue #3 for an explanation of why.

The build will fail if someone tries to open a PR to add them, but apart from that it’s not very obvious that they can’t be added. Therefore we risk someone implementing them before realising they can’t be added. There’s already been several PRs openened and closed for leap.

To avoid that it would be good if we could make it more obvious that these exercises shouldn’t be added for this track. Maybe adding a sentence or two to the contributing guide or something would help? What do you think @exercism/java? 🙂

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 30 (28 by maintainers)

Most upvoted comments

@jmrunkle Thank you for tackling this issue.

There are only three exercises that are affected and this list is not expected to change. I was just wondering if there might be much simpler solutions that might not break the structure of the language tracks and that might not require a change in configlet.

For example (listing of other proposals already mentioned in this issue):

  • How about just pointing out the respective exercises in the CONTRIBUTING file?
  • Or we could pin an issue that lines out those exercises that should not be touched.

What do you think about these simpler solutions?

BTW: All exercises that should not be implemented are listed under “foregone” in the config.json, but this obviously is not enough to point to those exercises for new contributors.

I agree, it would be nice to add them to the contributing guide. Then we would just have to worry about the people who don’t read the contributing guide. Maybe a pull request template would be good for getting information across.

As the justification for not implementing leap, grains, and say in Java has has been mooted, and as all three exercises were removed from foregone in #1713, and since both leap and grains have already been implemented, with say about to be in #1769, I’d say the primary action item on this Issue is to close it.

As you all might guess from the reference - created https://github.com/exercism/exercism/issues/4932

@lemoncurry Thanks for the additional suggestion.

There are only three exercises that are affected and this list is not expected to change.

While that may be the case, we do not know for certain that these 3 will be the only affected exercises - nor are we the only track that may have to contend with this issue (I assume other tracks also may have reasons that they cannot implement a certain set of exercises).

Yes, that is true, of course. But the list hasn’t changed in a long time and I would hesitate to say a global change of the track structure is justified.

How about just pointing out the respective exercises in the CONTRIBUTING file? Or we could pin an issue that lines out those exercises that should not be touched.

I’m not saying that we cannot do any of the other proposals - just that this would be more effective. Every other proposal that I have seen has the downside that a contributor may not notice that the exercise should not be implemented until they have already gone and implemented it. The presence of a single markdown file in an exercise directory that they would want to implement is a much stronger indicator of the fact that they should not implement that exercise and it shows up just-in-time rather than requiring them to read some external source (either the CONTRIBUTING file or a specific issue). Similar to the fact that the “foregone” list in the config is insufficient for this purpose.

Thank you for explaining why you thought a global change in the track structure might be needed. I see your point that the CONTRIBUTING file or the spec. issue about exercises that should not be implemented might be missed.

Also, the modifications to the configlet were not very complicated and I already have a pull request for those changes (exercism/configlet#163).

Although it might not be complicated, do you know if any other repositories, such as eg for the website, or our own scripts for maintaining this track, might be affected by this change in the track structure? Does your proposal then affect all language tracks so that all then need to keep the same structure for those exercises?

I assume other tracks also may have reasons that they cannot implement a certain set of exercises

This assumption is correct.

Maybe the discussion should be open for all tracks and transferred to exercism/exercism. It would be great to have the opportunity to hear from other track maintainers and their experiences with this issue. It might also be possible that there already exist simple solutions in some language tracks that we could use in the Java track.

There used to be but I don’t think there is anymore unfortunately 🙁 So I think the easiest thing to do at the moment is just to see if there are any exercises in the problem specifications repo that aren’t in our list of exercises in this repo. You can then try to port over any of those exercises (apart from leap, grains and say as explained in this issue).

You can also update the tests for any of the exercises. To do that you can run a script to check which tests need updating 🙂

And you can suggest new exercises or improvements to the current exercises in the problem specifications repo 🙂

We did have a link to an exercism.io page with a list of exercises not implemented yet on the Java track, but it doesn’t appear to exist on exercism.io anymore 🙁 I guess we could create and maintain our own list?