@jtigger I don't see this exercise in the 'forgone' list for this track. I would be happy to add it and additional exercises as time allows if you think it's helpful. Let me know. Thanks!

See http://help.exercism.io/getting-started-with-go.html as an example.

If appropriate, suggest a linter (see exercism/docs#54).

There is a documentation site, http://help.exercism.io the code for which lives in the repo at exercism/docs

At the moment we have a "getting started" page for each language that lists

• how to get the language installed (or links to tutorials/documentation about how to do that)
• how to run the tests
• further resources

Some languages are more onerous than others to get set up, and some languages are more geared towards beginners, so the level of documentation varies.

To add the documentation add a new markdown file in this directory:

https://github.com/exercism/docs/tree/master/app/pages/languages

It needs a little bit of metadata at the top

---
title: "Java"
slug: "getting-started-with-java"
category: "languages"
ordinal: 900

---

What goes into the page will depend a bit on what happens with issue #13

The tests are expecting list order, as @sit points out here: https://github.com/exercism/xjava/pull/37/files#r27770219

xjava/README.md should explain that after cloning xjava locally, the x-api server must be restarted to serve newly added problems.

I don't know if this would be true for pre-existing problems that have been modified.

I'm trying to get through the Java track and I'm really confused about two things to do with the simple-linked-list exercise.

1. Is there a reason this exercise doesn't make use of polymorphism?
2. How can I possibly write even the signature of a method that will make the last two test conditions succeed?

Allow me to explain the second confusion, here are the method signatures, followed by the compiler errors or failed tests in each case:
Polymorphism:

public <T> T[] asArray(Class<T> cls)

> error: generic array creation T[] answer = new T[size()];

Primitive array:

public int[] asArray(Class<?> cls)

> error: method containsExactly in class AbstractIntArrayAssert<S> cannot be applied to given types;
>         assertThat(list.asArray(Object.class)).containsExactly(expected);
>                                               ^
>   required: int[]
>   found: Object[]
>   reason: varargs mismatch; Object[] cannot be converted to int
>   where S is a type-variable:
>     S extends AbstractIntArrayAssert<S> declared in class AbstractIntArrayAssert

Integer array:

public Integer[] asArray(Class<?> cls)

> error: no suitable method found for containsExactly(Object[])
> assertThat(list.asArray(Object.class)).containsExactly(expected);
>                                               ^
>     method ObjectEnumerableAssert.containsExactly(Integer...) is not applicable
>       (varargs mismatch; Object[] cannot be converted to Integer)
>     method AbstractObjectArrayAssert.containsExactly(Integer...) is not applicable
>       (varargs mismatch; Object[] cannot be converted to Integer)
>   where CAP#1 is a fresh type-variable:
>     CAP#1 extends AbstractObjectArrayAssert<CAP#1,Integer> from capture of ?

Object array:

public Object[] asArray(Class<?> cls)

> SimpleLinkedListTest > canReturnListAsArray FAILED
> java.lang.AssertionError at SimpleLinkedListTest.java:63

As far as I can tell the last three errors are solely because of a type mismatch and inability for Java and/or the test suite to cast arrays in the obvious way. The first error, as I understand it, is a limitation of Java's polymorphism (even though I have no clue how I'm supposed to implement java.util.Collection<E>.toArray(T[]) correctly without creating a generic array).
I'm guessing that I'm missing something which is either obvious or an idiosyncrasy of Java. Can someone please help?

Since all tests send longs, I think also the input type should be long.

I have been working on this one and will put the PR as soon as it's fully tested.

There is an interesting edge case in the meetup problem:
some months have five Mondays.

March of 2015 has five Mondays (the fifth being March 30th), whereas
February of 2015 does not, and so should produce an error.

Thanks, @JKesMc9tqIQe9M for pointing out the edge case.
See exercism.io#2142.

In the JS and ES tracks, all tests except the first for any given problem are disabled by default. This way the user is encouraged to make their solution pass one test at a time, enabling the next test as he or she proceeds.

In JUnit we could use @Ignore in front of the @Test annotation to enable this.

There's a second step, how do we tell gradle to ignore @Ignore so all the tests get run during development and CI builds?

For example, some problems require Java 8 to be solved.

Instead of

actualWordCount = wordCount.Phrase("word");

it should be

actualWordCount = wordCount.phrase("word");

In Java, method names are always camelCased (i.e. the first letter is never capitalized).

Hey, my etl.java is in ~/exercism/java/etl/src/main/java directory, but when I try to submit it with full path

exercism submit src/main/java/etl.java

I get an error

Unable to submit - unable to identify track and problem

or if I try to submit without providing a path

The system cannot find the file specified.

Where am I supposed to move it to?

I tried moving it to all the directories but it's not working.

In the exercise etl, the current testsuite does enforce a non-static class by creating an instance of Etl.

When I did the exercise about half a year ago, this was not the case.

Since there is no data passed to the constructor and you can leave everything it is and you don't need to implement a constructor yourself, but let it fall through to Objects constructor, there is really no need to enforce instantiability.

So why was this change done? Why don't the current tests use a static Etl?

I made a really stupid choice a while back to commit the cross-compiled
binaries for configlet (the tool that sanity-checks the config.json
against the implemented problems) into the repository itself.

Those binaries are HUGE, and every time they change the entire 4 or 5 megs get
recommitted. This means that cloning the repository takes a ridiculously long
time.

I've added a script that can be run on travis to grab the latest release from
the configlet repository (bin/fetch-configlet), and travis is set up to run
this now instead of using the committed binary.

I would really like to thoroughly delete the binaries from the entire git
history, but this will break all the existing clones and forks.

The commands I would run are:

# ensure this happens on an up-to-date master
git checkout master && git fetch origin && git reset --hard origin/master

# delete from history
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch bin/configlet-*' --prune-empty

# clean up
rm -rf .git/refs/original/
git reflog expire --all
git gc --aggressive --prune

# push up the new master, force override existing master branch
git push -fu origin master

If we do this everyone who has a fork will need to make sure that their master
is reset to the new upstream master:

git checkout master
git fetch upstream master
git reset --hard upstream/master
git push -fu origin master

We can at-mention (@) all the contributors and everyone who has a fork here in this
issue if we decide to do it.

The important question though, is: Is it worth doing?

Do you have any other suggestions of how to make sure this doesn't confuse people and break their
repository if we do proceed with this change?

See issue exercism/exercism#2092 for an overview of operation welcome contributors.

Provide instructions on how to contribute patches to the exercism test suites
and examples: dependencies, running the tests, what gets tested on Travis-CI,
etc.

The contributing document
in the x-api repository describes how all the language tracks are put
together, as well as details about the common metadata, and high-level
information about contributing to existing problems, or adding new problems.

The README here should be language-specific, and can point to the contributing
guide for more context.

From the OpenHatch guide:

Here are common elements of setting up a development environment you’ll want your guide to address:

Preparing their computer
Make sure they’re familiar with their operating system’s tools, such as the terminal/command prompt. You can do this by linking to a tutorial and asking contributors to make sure they understand it. There are usually great tutorials already out there - OpenHatch’s command line tutorial can be found here.
If contributors need to set up a virtual environment, access a virtual machine, or download a specific development kit, give them instructions on how to do so.
List any dependencies needed to run your project, and how to install them. If there are good installation guides for those dependencies, link to them.

Downloading the source
Give detailed instructions on how to download the source of the project, including common missteps or obstacles.

How to view/test changes
Give instructions on how to view and test the changes they’ve made. This may vary depending on what they’ve changed, but do your best to cover common changes. This can be as simple as viewing an html document in a browser, but may be more complicated.

Installation will often differ depending on the operating system of the contributor. You will probably need to create separate instructions in various parts of your guide for Windows, Mac and Linux users. If you only want to support development on a single operating system, make sure that is clear to users, ideally in the top-level documentation.

In order to launch we should have:

• java as a submodule in x-api
• at least 10 problems
• a "how to get started" topic in the help repo repo (app/pages/languages/getting-started-with-java.md)
• one to a handful of people willing to check exercism regularly (daily?) for nitpicks to ensure that the track gets off on the right foot
• toggle "active" to true in config.json

The word multibillionaire is too long for the scrabble board. Oxyphenbutazone, on the other hand, is legal.

Please verify that there is no test for multibillionaire in the scrabble-score in this track. If the word is included in the test data, then it should be replaced with oxyphenbutazone. Remember to check the case (if the original is uppercase, then the replacement also should be).

If multibillionaire isn't used, then this issue can safely be closed.

See exercism/problem-specifications#86

Some languages are harder than others but I don't think introducing users to Abstract types in their second exercise is the best.

For example, In nucleotide-count the second test requests the user to return a dictionary of some sort.

Well, what is the actual return type of that dictionary, Map, HashMap, Dictionary?
Example Error.

java.lang.AssertionError: expecting:
<{'T'=0, 'G'=0, 'A'=0, 'C'=0}>
 to contain:
<[MapEntry[key=A, value=0], MapEntry[key=C, value=0], MapEntry[key=G, value=0], MapEntry[key=T, value=0]]>
 but could not find:
<[MapEntry[key=A, value=0], MapEntry[key=C, value=0], MapEntry[key=G, value=0], MapEntry[key=T, value=0]]>

Granted, I've been spoiled with SwiftLang

For example, after I do a exercism fetch and I get a new problem, its directory exists of the following tree:

exercise-name/
├── README.md
├── build.gradle
└── src
    └── test
        └── java
            └── AnagramTest.java

When I want to work on the exercise, I always have to add a src/main/java directory by hand, and a class, resulting in the following tree (for example for the bob exercise):

bob/
├── README.md
├── build.gradle
└── src
    ├── main
    │   └── java
    │       └── Bob.java
    └── test
        └── java
            └── BobTest.java

Copied from exercism/exercism#933 /cc @sit

Minimum Exercises to Implement

The following exercises are required to be created for the path to be launch.

• bob
• hamming
• word-count
• anagram
• nucleotide-count
• phone-number
• grade-school
• robot-name
• etl
• meetup

Additional Exercises to Implement

After the initial set of exercises the following should be implemented to have a more complete test suite.

• space-age
• gigasecond
• triangle
• scrabble-score
• roman-numerals
• binary
• prime-factors
• raindrops
• allergies
• strain
• atbash-cipher
• accumulate
• crypto-square
• trinary
• rna-transcription
• sieve
• simple-cipher
• octal
• luhn
• pig-latin
• pythagorean-triplet
• series
• difference-of-squares
• secret-handshake
• linked-list
• wordy
• hexadecimal
• largest-series-product
• kindergarten-garden
• binary-search-tree
• matrix
• robot-simulator
• nth-prime
• palindrome-products
• pascals-triangle
• beer-song
• sum-of-multiples
• queen-attack
• saddle-points
• ocr-numbers
• simple-linked-list
• linked-list
• point-mutations

Not Allowed to Be Implemented

These exercises were inspired by Java Ranch and are not allowed to be implemented.

• leap
• grains
• say

The old help site was deprecated in December 2015. We now have content that is displayed on the main exercism.io website, under each individual language on http://exercism.io/languages.

The content itself is maintained along with the language track itself, under the docs/ directory.

We decided on this approach since the maintainers of each individual language track are in the best position to review documentation about the language itself or the language track on Exercism.

Please verify that nothing in docs/ refers to the help.exercism.io site. It should instead point to http://exercism.io/languages/:track_id (at the moment the various tabs are not linkable, unfortunately, we may need to reorganize the pages in order to fix that).

Also, some language tracks reference help.exercism.io in the SETUP.md file, which gets included into the README of every single exercise in the track.

We may also have referenced non-track-specific content that lived on help.exercism.io. This content has probably been migrated to the Contributing Guide of the x-common repository. If it has not been migrated, it would be a great help if you opened an issue in x-common so that we can remedy the situation. If possible, please link to the old article in the deprecated help repository.

If nothing in this repository references help.exercism.io, then this can safely be closed.

The travis build [was] failing due to the prime factors exercise.

The files for the problem are:

$ tree prime-factors
prime-factors/
├── build.gradle
└── src
    ├── example
    │   └── java
    │       └── PrimeFactors.java
    ├── main
    │   └── java
    └── test
        └── java
            └── PrimeFactorsTest.java

In other exercises, we have the example solution at the root of the problem directory, and it is named example.java. E.g.:

$ tree gigasecond
gigasecond/
├── build.gradle
├── example.java
└── src
    ├── main
    │   └── java
    └── test
        └── java
            └── GigasecondTest.java

What is the correct move here? Move src/example/java/PrimeFactors.java to example.java? Or perhaps to src/main/java/example.java?

I've been working on making the various language icons a little bit more uniform. I don't know graphics, so I've been writing scripts to decode the PNGs and then rewrite them the way I want. It's a little bit tedious, and I haven't figured out how to smooth the edges, but I'm pretty excited about how it's turning out... and I just wanted to share. Hence the issue :)

After fetching and getting the meetup exercise, its file tree is:

meetup/
├── README.md
├── build.gradle
└── src
    ├── main
    │   └── java
    │       ├── Meetup.java
    │       └── MeetupSchedule.java
    └── test
        └── java
            └── MeetupTest.java

As you can see, it's missing a README file, which makes it impossible (for me, at least) to complete the exercise.

From looking at the tests across this repo @ 6753d9c, it looks like junit is the defacto test runner:

$ git grep testCompile
_template/build.gradle:  testCompile "junit:junit:4.10"
accumulate/build.gradle:  testCompile "junit:junit:4.10"
allergies/build.gradle:  testCompile "junit:junit:4.10"
anagram/build.gradle:  testCompile "junit:junit:4.10"
atbash-cipher/build.gradle:  testCompile "junit:junit:4.10"
binary/build.gradle:  testCompile "junit:junit:4.10"
bob/build.gradle:  testCompile "junit:junit:4.10"
crypto-square/build.gradle:  testCompile "junit:junit:4.10"
etl/build.gradle:  testCompile "junit:junit:4.10"
etl/build.gradle:  testCompile "org.easytesting:fest-assert-core:2.0M10"
etl/build.gradle:  testCompile "com.google.guava:guava:16+"
gigasecond/build.gradle:  testCompile "junit:junit:4.10"
grade-school/build.gradle:  testCompile "junit:junit:4.10"
grade-school/build.gradle:  testCompile "org.easytesting:fest-assert-core:2.0M10"
hamming/build.gradle:  testCompile "junit:junit:4.10"
hello-world/build.gradle:  testCompile "junit:junit:4.10"
luhn/build.gradle:  testCompile "junit:junit:4.10"
meetup/build.gradle:  testCompile "junit:junit:4.10"
meetup/build.gradle:  testCompile "org.easytesting:fest-assert-core:2.0M10"
nucleotide-count/build.gradle:  testCompile "junit:junit:4.10"
nucleotide-count/build.gradle:  testCompile "org.easytesting:fest-assert-core:2.0M10"
octal/build.gradle:  testCompile "junit:junit:4.10"
pangram/build.gradle:  testCompile "junit:junit:4.10"
pascals-triangle/build.gradle:  testCompile "junit:junit:4.10"
phone-number/build.gradle:  testCompile "junit:junit:4.10"
pig-latin/build.gradle:  testCompile "junit:junit:4.10"
prime-factors/build.gradle:  testCompile "junit:junit:4.12"
raindrops/build.gradle:  testCompile "junit:junit:4.10"
rna-transcription/build.gradle:  testCompile "junit:junit:4.10"
robot-name/build.gradle:  testCompile "junit:junit:4.10"
roman-numerals/build.gradle:  testCompile "junit:junit:4.10"
scrabble-score/build.gradle:  testCompile "junit:junit:4.10"
sieve/build.gradle:  testCompile "junit:junit:4.10"
simple-cipher/build.gradle:  testCompile "junit:junit:4.10"
space-age/build.gradle:  testCompile "junit:junit:4.10"
strain/build.gradle:  testCompile "junit:junit:4.10"
triangle/build.gradle:  testCompile "junit:junit:4.10"
trinary/build.gradle:  testCompile "junit:junit:4.10"
word-count/build.gradle:  testCompile "junit:junit:4.10"

We're not consistent on which assertion methods to use. Some tests use either junit's assertEquals(), others use junit's assertThat() or fest-assert's assertThat().

1. Should we pick one version of junit and use that across the board?
2. Should we pick one assertion API and stick with it? Note that fest-assert seems to be replaced by AssertJ (FWIW).

The latest version of junit in maven central is 4.12, so I'd vote for that.

I'm partial to variations of assertThat() because of matcher support (for Collection classes, arrays, etc). But I don't have a strong opinion aside from that.

When doing an exercism fetch and getting the anagram exercise, it doesn't contain a build script (build.gradle file), making me unable to complete the exercise.

After I do exercism fetch, I get (on OS X 10.10.2, using exercism-cli):

                     New: 1 problem
           Anagram (java) /Users/pietvandongen/exercism/java/anagram

unchanged: 25, updated: 0, new: 1

The directory listing (ls -la anagram/) gives:

total 8
drwxr-xr-x  4 pietvandongen  staff  136  1 feb 21:59 .
drwxr-xr-x  8 pietvandongen  staff  272  1 feb 21:59 ..
-rw-r--r--  1 pietvandongen  staff  360  1 feb 21:59 README.md
drwxr-xr-x  3 pietvandongen  staff  102  1 feb 21:59 src

I keep my working exercism directory in git, and I'm one of many... I just went to commit after working on some Java exercises and realized I ad added .gradle/ and .idea/ dirs to the working tree, among others, that shouldn't be checked into source control. It would be a good and helpful idea to add a .gitignore for typical artifacts either to each exercise directory, the java directory, or possibly a global one for exercism...

Maybe more than one of these. Might bear some discussion on the exercism/dev channel on Gitter, but I thought I'd open an issue here as well since Java's definitely a case where a lot of build/IDE artifacts are generated and I end up with quite lengthy .gitignore files in my regular projects.

Perhaps this was a part of exercise to figure out, but I ran into the following issue with Java 1.6:

$ gradle build
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:assemble UP-TO-DATE
:compileTestJava

FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all dependencies for configuration ':testCompile'.
> Could not resolve junit:junit:4.10.
  Required by:
      :etl:unspecified
   > Failure initializing default system SSL context
> Could not resolve org.easytesting:fest-assert-core:2.0M10.
  Required by:
      :etl:unspecified
   > Failure initializing default system SSL context
> Could not resolve com.google.guava:guava:16+.
  Required by:
      :etl:unspecified
   > Failed to list versions for com.google.guava:guava.
      > Unable to load Maven meta-data from https://repo1.maven.org/maven2/com/google/guava/guava/maven-metadata.xml.
         > Failure initializing default system SSL context

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

After downloading JDK 8 from Oracle, the issue went away. Maybe it's possible to set up a Java version check?

The metadata for this problem has been simplified, and it might be worth changing the test suite and example so that theres no mention of RNA or uracil.

I've also changed the API of the problem in Ruby so that there is no error checking in the object itself, only in the factory that creates it: https://github.com/exercism/xruby/blob/master/nucleotide-count/example.rb#L2-L8

I don't know if this is relevant or idiomatic in Java.

The instructions mention this explicitly:

Keep your hands off that filter/reject/whatchamacallit functionality provided by your standard library! Solve this one yourself using other basic tools instead.

Aside from test case 0, I get all the tests failing with messages like:

"java.lang.AssertionError: expected: java.util.Arrays$ArrayList<[2, 3]> but was: java.util.ArrayList<[2, 3]>"

The lists match and the values have the same orders. Initially I was using a LinkedList and thought that was the problem, but changing to ArrayList didn't solve the problem.

Oddly enough, test 0 pass (empty list), probably because the initalizer is

Arrays.asList(new Integer[0]);

instead of

Arrays.asList(new Integer[]{})

as the others are.

I'm using IntellijIdea 14.1 , running as JUnit tests. Attached the code for my solver:

public class PrimeFactors {
    public static List<Long> getForNumber(double input) {
        List<Long> result = new ArrayList<>();
        long number = (long) input;

        //Primality checks only up to SQRT(num)
        for (long i = 2; i * i <= input; i++) {
            //Eratosthenes-like approach at removing prime multiples
            while (number > 1 && number % i == 0) {
                number /= i;
                result.add(i);
            }
            //Premature exit if we are done
            if (number <= 1) {
                break;
            }
        }
        //Leftovers are prime numbers too
        if (number > 1) {
            result.add(number);
        }
        return result;
    }
}

From issue exercism/exercism#1867

Wikipedia says the Hamming distance is not defined for strings of different length.

I am not saying the problems cannot be different, but for such a well-defined concept it would make sense to stick to one definition, especially when the READMEs provide so little information about what is expected from the implementation.

Let's clean this up so that we're using the official definition.

And the Date() method should be called getDate().

The build.gradle for the atbash-cipher exercise is empty.

The Map's values could be directly added to the Enum, see the comment by @sit here: https://github.com/exercism/xjava/pull/27/files#r27770365

The JUnit API defines:

static public void assertEquals(Object expected, Object actual) {
    assertEquals(null, expected, actual);
}

So, the expected value goes first.

The build.gradle for the pangram exercise is empty.

The problems api (x-api) now supports having exercises collected in a subdirectory
named exercises.

That is to say that instead of having a mix of bin, docs, and individual exercises,
we can have bin, docs, and exercises in the root of the repository, and all
the exercises collected in a subdirectory.

In other words, instead of this:

x{TRACK_ID}/
├── LICENSE
├── README.md
├── bin
│   └── fetch-configlet
├── bowling
│   ├── bowling_test.ext
│   └── example.ext
├── clock
│   ├── clock_test.ext
│   └── example.ext
├── config.json
└── docs
│   ├── ABOUT.md
│   └── img
... etc

we can have something like this:

x{TRACK_ID}/
├── LICENSE
├── README.md
├── bin
│   └── fetch-configlet
├── config.json
├── docs
│   ├── ABOUT.md
│   └── img
├── exercises
│   ├── bowling
│   │   ├── bowling_test.ext
│   │   └── example.ext
│   └── clock
│       ├── clock_test.ext
│       └── example.ext
... etc

This has already been deployed to production, so it's safe to make this change whenever you have time.

The API is blowing up when trying to serve the new acronym exercise. I'll try to take a look at it today, but if you happen to have a suspicion about what's going on then now's your chance :)

(originally exercism/exercism#2432)

differentRobotsHaveDifferentNames and resetName are not proper tests for detecting collisions. They need many more iterations to be convincing (~1/670000).

Here is my modified test:

import org.junit.Test;

import java.util.stream.IntStream;

import static org.hamcrest.CoreMatchers.equalTo;
import static org.hamcrest.core.Is.is;
import static org.hamcrest.core.IsNot.not;
import static org.junit.Assert.assertThat;

public class RobotTest {

    private static final String EXPECTED_ROBOT_NAME_PATTERN = "\\w{2}\\d{3}";
    private final Robot robot1 = new Robot();
    private final Robot robot2 = new Robot();

    @Test
    public void hasName() {
        assertIsValidName(robot1.getName());
    }

    @Test
    public void differentRobotsHaveDifferentNames() {
        IntStream.range(0, 300000).forEach(x -> {
            assertThat(robot1.getName(), not(equalTo(new Robot().getName())));
        });
    }

    @Test
    public void resetName() {
        IntStream.range(0, 300000).forEach(x -> {
            final String name = robot2.getName();
            robot2.reset();
            final String name2 = robot2.getName();
            assertThat(name, not(equalTo(name2)));
            assertIsValidName(name2);
        });
    }

    private static void assertIsValidName(String name) {
        assertThat(name.matches(EXPECTED_ROBOT_NAME_PATTERN), is(true));
    }
}

Today, we start off new folks with a wrongly filled-out solution file. I'm proposing that not only should we fix this, but provide enough code in that first exercise that when the exercist runs the tests, they get tests failing for the right reasons (i.e. on assertions) rather than compilation errors.

So, go from this:

public Etl {
}

(notice the missing class keyword; but will yield other compilation errors, too)

...to this...

import java.util.List;
import java.util.Map;

public class Etl {
    public Map<String, Integer> transform(Map<Integer, List<String>> old) {
        return null;
    }
}

Thoughts? (cc: @kytrinyx @pietvandongen @vdemeester @sit)

Please check if there's a test that states that a triangle with sides 2, 4, 2 is invalid. The triangle inequality states that for any triangle, the sum of the lengths of any two sides must be greater than or equal to the length of the remaining side. If this doesn't affect this track, go ahead and just close the issue.

@pminten brought up a very good point about the API of meetup being
pretty terrible (See exercism/exercism#950).

If the meetup problem has not already been fixed in this track, we should
improve the test suite and example code to give the API a better design.

As a track maintainer,
I want the CI build to also stand-up a local instance of exercism and fetch exercises through the client
So that I'm confident that end-to-end, my changes don't break the exercism experience.

Notes:

• look at README.md for full setup instructions. This should be fun as it requires a Ruby install as part of the build (possible on travis?)

In @vdemeester 's clean-up (via 8e35e87) accidentally included compilation errors. Namely, that three starter classes — Etl, WordCount, and DNA were missing the class keyword.

Reading the docs, I only saw support for Java 8.

Android requires Java 7 (doesn't seem to have integrated 8 yet)
http://developer.android.com/sdk/installing/index.html?pkg=studio

Would the attached gist issue be related to Java 7 Support?
https://gist.github.com/masters3d/12f973f262e957b2c998

Thanks

The contents of the SETUP.md file gets included in
the README.md that gets delivered when a user runs the exercism fetch
command from their terminal.

At the very minimum, it should contain a link to the relevant
language-specific documentation on
help.exercism.io.

It would also be useful to explain in a generic way how to run the tests.
Remember that this file will be included with all the problems, so it gets
confusing if we refer to specific problems or files.

Some languages have very particular needs in terms of the solution: nested
directories, specific files, etc. If this is the case here, then it would be
useful to explain what is expected.

Thanks, @tejasbubane for suggesting that we add this documentation everywhere.
See exercism.io#2198.

The API currently blows up when trying to serve java problems, due to the non-utf-8 characters in the gradle archive.

It is perhaps a bit excessive to serve a jar file with each problem. Should we provide a link to the jar and have people download it and put it in their PATH?

Should we simplify the testing? (we really don't need anything fancy, the problems are all very tiny).