Reading Map from csv with Singleton
soo... going from top to bottom:


public interface IMapFromCsv{



superfluous I before name, missing space before opening curly brace


public default &lt;T&gt; Map&lt;String, T&gt; getMap(String FILE_TO_LOAD, Function&lt;String, T&gt; convertValue){



FILE_TO_LOAD should be named according to naming convention: fileToLoad. Next step is making it a Path because a String is not a File and File is superseeded by Path, because it sucked.

Also missing a space before the opening curly again.


    Map&lt;String, T&gt; mapResult = new HashMap&lt;&gt;();
    File f = new File(FILE_TO_LOAD);



so far so good. did I mention that File is crap?


    try (Scanner sc = new Scanner(f)) {
        while (sc.hasNextLine()) {
            String tmp = sc.nextLine();
            String[] tmp2 = tmp.split(";");
            mapResult.put(tmp2[0], convertValue.apply(tmp2[1]));
        }
    }



Bonus points for using try-with-resources, deductions for using tmp and tmp2 as variable names. How about we simplify this a bit?

try (Stream&lt;String&gt; lines = Files.lines(fileToLoad)) {
    return lines.map(s -&gt; s.split(";"))
        .collect(Collectors.toMap(line -&gt; line[0]
            , line -&gt; convertValue.apply(line[1])));
}


Note that this only returns either the full map, or currently nothing. If something goes wrong while reading the map, I'd suggest using Collections.emptyMap() as a sensible default result.


    } catch (FileNotFoundException fntf) {



This exception is one of the reasons File is crap. The good part is: You get a unified Exception API from the java.nio.Path and related, which is: IOException. 



At this point I'm asking myself the question why this is a default method on an interface. Methods in an interface are meant to be overwritten to modify them. The method instead takes parameters to configure it. IMO this would be much nicer as a static method in some IO module or something.



Last but not least: Why are AreaMapFromCsv named like they'd be Methods? Let's reconsider this for a second. You're trying to implement something that will hold information on Maps of your choosing, namely where they are saved, and what value you're currently assigning to them. 

I'm not clear on why that needs to be two separate classes (or actually singleton enums), or where the singleton comes into this. 

From my PoV it seems like you heard that Singletons are an acceptable solution when you try to handle global state. Tip: they aren't. 

The correct solution for global state is a properly encapsulated statically accessible instance of a proper class. Consider this instead:

public class MapHolder&lt;T&gt; {

    // consider making this final
    private Map&lt;String, T&gt; map;
    private final String mapPersistenceLocation; // this is a Path...
    private final Function&lt;String, T&gt; converter;

    public MapHolder(String parameterName, Function&lt;String, T&gt; converter) {
        this.mapPersistenceLocation = parameterName;
        this.converter = converter;
        reload();
    }

    public void reload() {
        // if map is final, replace by map.clear(); map.putAll(...);
        map = IOHelper.readMap(mapPersistenceLocation, converter);
    }

    public Map&lt;String, T&gt; get() {
        // consider returning a readonly copy, if modifications should be disallowed
        return map;
    }
}


Which can now be used as follows:

public final class GlobalContext {
    public static final MapHolder&lt;Double&gt; CURRENCY = new MapHolder&lt;&gt;("resources/currencyMap.csv", Double::parseDouble);
    public static final MapHolder&lt;String&gt; AREA = new MapHolder&lt;&gt;("resources/areaMap.csv", Function.identity());

    // prevent instantiation
    private GlobalContext() {}
}