Group Anagrams Together approach in Java
for (int i = 0; i &lt; word1.length(); i++) {



Since you never use i except to calculate word1.charAt(i), you could more easily do 

        for (char current : word1.toCharArray()) {


Then you could replace word1.charAt(i) with current.  

But as noted in a comment, it would actually be more efficient to use a different algorithm.  The issue is that indexOf is \$\mathcal{O}(n)\$ and of course the for loop is \$\mathcal{O}(n)\$.  Nested, they become \$\mathcal{O}(n^2)\$.  Worse, isAnagram is itself inside nested for loops.  So the overall approach is \$\mathcal{O}(m^2n^2)\$, where \$m\$ is the number of words and \$n\$ is the maximum length of each word.  

If you instead normalize each string by sorting it (\$\mathcal{O}(n\log n)\$), you can then put the normalized strings in a HashMap of ArrayList (\$\mathcal{O}(1)\$ each or \$\mathcal{O}(m)\$ total).  This is only \$\mathcal{O}(m\cdot n\log{n})\$, which is much better.  

Or skip the ArrayList and just use a counter.  The overall algorithm would look something like 

    public static Map&lt;String, Integer&gt; countAnagrams(String[] words) {
        Map&lt;String, Integer&gt; anagramCounts = new HashMap&lt;&gt;();

        for (String word : words) {
            String sorted = sort(word);

            Integer count = anagramCounts.get(sorted);
            if (count == null) {
                count = 0;
            }

            anagramCounts.put(sorted, count + 1);
        }

        return anagramCounts;
    }


This expects the caller to handle the output, which is better practice (Single Responsibility Principle, as applied to methods; see also SOLID, Separation of concerns, and Don't Repeat Yourself).  

The basic idea here is that the method should either generate data or display it.  That way, if you want to reuse the data generation for something else, you can.  

In the original, you generate the data and then display it in the same method.  If you wanted to do something else with the data, you'd have to refactor.  This is more flexible and easier to test with automation.  

Consider 

public static void displayAnagramCounts(String[] words) {
    Map&lt;String, List&lt;String&gt;&gt; groups = groupAnagrams(words);
    List&lt;Integer&gt; counts = countValues(groups);
    Collections.sort(counts);
    displayNumbers(counts);
}


Now countValues and displayNumbers can be written in generic ways.  The former takes a Map of List and flattens it into a List of the sizes of the List elements.  The latter displays a list of numbers with spaces between them.  Both those methods can be reused and tested separately.  


        for (Map.Entry&lt;String,Integer&gt; entry : anag.entrySet()) {
            //System.out.println(entry.getKey() + " " + entry.getValue());
            counts.add(entry.getValue() + 1);
        }



There is an argument that you shouldn't include commented out code in a code review.  Commented out code is code not ready for source control (it should either be deleted or commented in).  

You don't actually need an entrySet here, as values is enough.  E.g. 

        for (int value : anag.values()) {
            counts.add(value + 1);
        }


With my alternative algorithm, you wouldn't even have to add one here.