STL is just the containers / iterators / algorithms part of the standard library, the part that Alexander Stepanov designed and originally implemented. Most of the less pleasant parts of the standard library like iostreams come from elsewhere.
Templates, static method dispatch and type polymorphism are not really part of OOP, certainly not Java style OOP. Abstract classes for allocators are a very recent addition with polymorphic allocators and are a good example of OOP features being used in modern C++ as more of an implementation detail (a way to get dynamic dispatch / type erasure).
Java is not the last word in what OOP means in practice, and is a younger language, which took many OOP ideas from C++ OOP libraries that were current when Java was designed.
In fact something like J2EE was a relief versus using CORBA or DCOM/MTS, kings of OOP boilerplate.
Or the surviving king of C++ GUI frameworks, Qt.
As for the STL part you refer to, the original one, containers / iterators / algorithms, it makes use of C++ classes, methods, aggregation and delegation, which are definitely OOP.
OOP doesn't have a rule that it is only OOP when all concepts are used in every single class.
The STL is more derived from Abstract Data Types than from OOP but there is overlap between those. Basically the good parts of OOP is ADTs and are embodied in the STL, the bad parts are most of the rest and are embodied in Java.
To bring it back to the original comment I was replying too and to the original email, Alan Kay says in the email:
> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.
He was writing in 2003 so presumably didn't / doesn't consider Java or C++ OOP languages by his definition.
The comment I was originally replying to said:
> C++, Java, Python, are all founded in confused interpretations of OO. OO has also become so synonymous with these implementations that we should just let the paradigm go entirely and start afresh.
And I was taking issue with C++ being included with Java in this (I think Python shouldn't really be included either). C++ is a multi paradigm language and while I agree the OOP parts of it that it has in common with Java are neither very good nor what Alan Kay meant by OOP, C++ supports other better programming paradigms better than Java does.
The good parts of C++ style OOP are mostly the ADT bits. The less good parts are inheritance and virtual functions. Design Patterns makes heavy use of the less good parts of that style of OOP and most of the problems it addresses are better solved in other ways that modern C++ supports quite well.
Templates, static method dispatch and type polymorphism are not really part of OOP, certainly not Java style OOP. Abstract classes for allocators are a very recent addition with polymorphic allocators and are a good example of OOP features being used in modern C++ as more of an implementation detail (a way to get dynamic dispatch / type erasure).