== is associative, which means that for any values "a" and "b", "a == b" will always give the same result as "b == a".
The "null == object" syntax is inherited from C programmers. In C, everything can be used as a boolean. A pointer is true if set, or false if NULL (the C equivalent of Java's null). Sometimes people made typing mistakes, leaving out one of the = signs: This is an assignment to object followed by an evaluation. Instead of checking if object was NULL this actually set object to NULL and then evaluated this, which would always yield false. The compiler didn't give any error because it's perfectly legal in C. (Although some compilers could give warnings.)
Now you know the back story you can forget about it. In Java this is possible in only a very few cases. All other cases will result in a compiler error. These cases all involve boolean or (since Java 5.0) Boolean. They are:
bool1 gets the same value as bool2, after which its value is evaluated.
Only possible if bool is a Boolean. Again the assignment, then bool is auto-unboxed. This will actually result in a NullPointerException since unboxing null is not possible.
The first one you can't prevent by swapping bool1 and bool2. The second one can be prevented by swapping bool and null; "null = bool" will always give a compiler error. That being the case, I never do this. I find "object == null" just a bit more natural than "null == object". And this one occurrence with Boolean can be found out through proper testing. The NullPointerException will help you out with that.