I think you mean something like this:

public class T {
    public T(Class<Map<MyClassType1, Object>> cls) {
    }
}

But you'll need this instead:

public class T {
    public T(Class<? extends Map<MyClassType1, Object>> cls) {
    }

    public static void main(String[] args) {
        Map<MyClassType1, Object> m = new HashMap<MyClassType1, Object>();
        T t = new T(m.getClass());
    }
}

Java's type system is simply not strong enough to enforce the type constraint you're describing directly, and you'll need to do some unsafe casts to make this work -- or wrap the Map in some other API that enforces the type safety. Guava's ClassToInstanceMap does just that for exactly this use case, providing an externally safe API that imposes additional restrictions on the Map interface to make it work. (Disclosure: I contribute to Guava.)

The only time this can cause a memory leak is if there's some classes you're using here that would not be retained for the life of the application. This isn't a concern for many users, especially if you're writing a "server side" application that isn't as concerned about unloading unused classes.

The misunderstanding is due to poor documentation that doesn't catch a major change in specs, or due to the CPython implementation which dare to write a class for what is listed as a built-in function in the specs.

In Python 2, it is a function that returns a list. In the online documentation of Python 2, it is listed under Built-in Functions. The first line of help(map) on CPython 2.7.10 reads

Help on built-in function map in module builtin

correctly calling it a function.

In Python 3, they changed the specs that it returns an iterator instead of a list. As @RafaelC noted, it has an advantage of lazy loading. Althiugh it is still under "Built-n Functions", the CPython implementation decided to make it a class. This change is reflected in help(map), which you have seen and quoted in the question.

What you are doing when you call map() in CPython 3 is, you are creating an object of class map with the parameters you throw. This is clearly shown when you try to print what map() returns.

CPython 2.7.10:

>>> map(int, "12345")
[1, 2, 3, 4, 5]

CPython 3.7.2:

>>> map(int, "12345")
<map object at 0x1023454e0>

So you are clearly creating an object of class map, which makes what you've seen in help(map) sound very fine.

So it seems that, to the CPython core developers, a class can be a "function" with some definiton of a "function". This is clearly misleading. Anyway, it implements the necessary methods that enables it to be used as an iterator. (as the docs says, if you ignore that it's listed under builtin functions.)

It's used as a function

That's because the syntax of calling a function and fetching its return value is identical to creating a class object (by calling its initializer) and fetching the object.

For example, using a function my_function() as in return_value = my_function() is syntactically no different from creating a class object of my_class() as in my_object = my_class(). When you call map() in CPython 3, you are creating an object of class map. But you would write the same even if map were a function. That's why you're confused.

So in short,

1. map was a function in CPython 2, but is a class in CPython 3. That is clear from help(map) on both versions, and that's what the CPython implementation does.

2. The documentation keeps it under "Built-in functions" while CPython implementation finds liberty to write a class for it, causing confusion.

3. It's a shame that the two aren't clearly distinguished in the docs.