Splitting Hashmap by converting to TreeMap
Interfaces over implementations


           TreepMap&lt;String, Type&gt; treeMap = new TreeMap&lt;String, Type&gt; (originalMap);



This could be 

           SortedMap&lt;String, Type&gt; splittable = new TreeMap&lt;&gt;(original);


That gets rid of the typo TreepMap.  

It saves specifying the types twice.  You don't need to do that unless you are building against an old version of Java.  

Specifying the interface rather than the implementation makes it easier to change implementations in the future.  You could also use NavigableMap, but it's not necessary for these operations.  

I prefer descriptive names like splittable and original to type names.  Of course, your coding standards could be different.  

Exceptions


      } catch (Exception e) {
           throw e;
      }



If you're just going to throw the same exception, there's no reason to catch it.  If you want to catch it, then handle it.  If you want it to percolate up to the caller, then just let it go without catching it.  As is, the try/catch doesn't do anything.  You could simplify the code by taking it out.  

Alternatives

I'm not convinced that this does enough to be worthwhile.  It's probably going to be less efficient than the more manual solution.  And it's not less code.  Consider 

    Map&lt;String, Type&gt; current = new HashMap&lt;&gt;(MAXIMUM_CAPACITY);

    for (Map.Entry&lt;String, Type&gt; entry : original.entrySet()) {
        current.put(entry.getKey(), entry.getValue());

        if (current.size() &gt;= MAXIMUM_SIZE) {
            splitMaps.add(current);
            current = new HashMap&lt;&gt;(MAXIMUM_CAPACITY);
        }
    }

    if (!current.isEmpty()) {
        splitMaps.add(current);
    }


This is about the same amount of code, but it saves turning the keySet into a List.  

Both versions have to iterate over the original map.  This one does so manually while the original code did so implicitly by converting to a TreeMap.  

I would find the code more compelling if the data was moved from the HashMap to a TreeMap as the base source.  I.e. if there never was a HashMap and the map came as a TreeMap.  

This assumes the creation of two new constants.  You might be able to find better names with more context.  I don't like criticalNumber as a name because it doesn't tell me what makes the number critical.  MAXIMUM_SIZE is a bit better in my opinion, as it tells me that the number is a size and that we don't want to go beyond it.