Implementing my own Pair class in Java

Only one nitpick:

return this.first.equals(other.first) && this.second.equals(other.second);

The above will throw NullPointerException if this.first or this.second is null.

Consider this, instead:

Pair<T1, T2> other = (Pair<T1, T2>) obj;
return Objects.equals(first, other.first) &&
       Objects.equals(second, other.second);

The idea is that Objects.equals deals with the null values also.

DON'T DO IT!

You should know that the reason why Java standard libraries do not have a Pair class is because people would abuse it and use it EVERYWHERE to represent anything that has two things associated to each other.

This would make code horrible to read and maintain. People would put pairs into pairs and create freakish binary trees where no name gives any indication whatsoever to what each piece of data represents.

Inasted of making the exact error that was rejected by quite a smart bunch of software architects, you should reject it too and instead make classes that represent your data.

So if your pair represents cartesian coordinates, name your class Coordinate instead. If it's a key-value pair, name it KeyValuePair. And so on.

Now that we have the important part out of the way, "a pair" is just a set with hard coded size of 2. If you implement your class so that it has an order between the values, you create something that is no longer just a pair and you should name it accordingly. If you are hell bent on implementing a pair, your equals method should take into account that the order of the elements should not matter.

1. You can compare your implementation with java.util.KeyValueHolder
2. Consider disallowing null keys and values - depends on the context if can be done, but if its sort of "clean slate" state I'd definitely go for it. A lot has been said about nulls, their pros and cons, but main benefit of removing them (for me) is that it makes the code simpler as it can express less states (e.g. you would entirely avoid having to check nulls in equals/hashcode).
3. Consider eliminating mutability. Again, immutable code is generally simpler and easier to understand (personally I consider immutable solution default and only go to mutable solution when actually needed). Currently anyone holding reference to the pair object can modify it without any thread safety/consistency constrains.
4. Consider how would the code be used, and, if additional abstraction layer is needed. E.g. if you want the pair to be mutable it is generally better to hide internal state behind abstraction layer (getter/setter) - it is not important tho if you are going to use it only in your project (then I would wait with adding getters/setters to the moment when they are needed as modern IDEs make it completely automatic), but, if it were part of library to be used by multiple projects (and Pair-like objects usually are due to them being so generic) then additional abstraction layer is a very good idea to not tie your hands as a maintainer (see Map.Entry interface and KeyValueHolder implementing it)
5. Consider implementing toString - value holding classes tend to be logged while debugging etc. and it could make it easier (don't do it tho if you want to store secrets in it)

You can get rid of that warning by using pattern matching for instanceof:

        if (obj instanceof Pair other) {
            return this.first.equals(other.first) && this.second.equals(other.second);
        } else {
            return false;
        }