Java Word Frequency Counter
It's normal for Java programs to be longer. I wouldn't care about the number of lines per se.
The main method does too much stuff:


It asks the user to choose the file
It reads the content of the file
It counts the number of occurrences 
It prints them to another file


One method should be responsible for one thing. There're at least 4 different (very different) things here.

In fact, I believe that the first thing (and probably the second and the last thing, too) doesn't belong in the FrequencyCounter class. Why? It makes sense for the counter to count occurrences and do just it. It'll make it more reusable. Think what happens if you want to change the output format, the way the user choose the file or just use it as part of your different project.  
I would redesign the FrequencyCounter it so that it has one method that takes a string and returns a map with different words and the number of their occurrences. 
The reading/writing stuff and the user dialog belong to a different class. These are different concerns. So I'd create another class to handle file I/O and one more class to interact with a user as these things have nothing to do together. They can change independently and they don't need each other to work. They're separate entities.
You don't handle the case when the file is null (that is, when the user doesn't choose a file). A NullPointerException isn't very user-friendly. 
This piece of code:

 if (counter.containsKey(word))
     counter.put(word, counter.get(word) + 1);
 else
     counter.put(word, 1);


can be simplified to counter.put(counter.getOrDefault(word, 0) + 1); unless you're using an older Java version.
If you plan to work with large files (really large, such that their content doesn't fit into main memory), you'll need to get rid of reading the entire file into a String. A more space-efficient solution would be to read it in chunks and process them separately (the words are normally short, so it can save a lot of memory). Sure, it makes the code more complicated (for instance, you'll need to carefully check when the word ends), so it's worth doing only if you plan to work with large amounts of data.
A method name is normally a verb. cleaner doesn't sound very good to me. I'd rename it to something like cleanWords. I'd also put cleaning one word into a separate method to make it more manageable. You can go even further and put all cleaning stuff into a separate class to increase the flexibility (it also makes sense from a design point of view: cleaning and counting are different responsibilities and they are pretty much independent).   
The way you work with the output file is potentially dangerous: if such a file already exists, it'll be overwritten. I don't think that doing it silently is a good idea. There're a few different ways to deal with it: generating a different unique name, aborting the program or letting the user choose the output file. Either of them is better than replacing the content of the file silently.