When would SomeClass<Object> be appropriate/useful

Question

I've recently come across the following line of code in a project I'm to refactor and own:

SomeClass<Object> someClass = new SomeClass<Object>();

I can't, for the life of me, figure out why anyone would use generics in this fashion. The only reason I came up with is that SomeClass uses generics in another scenario to good effect and therefore has to use something here. Lacking a better alternative, Object is used.

I did try googling, but since Google discards the <> from <Object>, I got the standard results.

===========================================================================

SomeClass is subclassed extensively and is part of a very large and complex project. Using generics would provide the usual benefits of type safety and shorter code (no casting required).

Given the complexity of the code, I can't say for certain why this was done yet and if it really does provide benefit. However, I figured I'd ask the experts just in case there is some obscure but valid reason to do so, which isn't well known.

Alternatively, this may be a defensive measure to keep the relatively inexperienced programmers like me from messing with the code. Touch one angled bracket and watch the source code fill with red...

It certainly made me brush up on my knowledge of Generics in Java.

========================================================================

To further clarify, SomeClass is a kind of a general purpose container object. It is used in all sorts of ways, such as:

class SomeSubClass<SomeClass> extends SomeClass<T> 
class SomeSubClass<? extends SomeSubClass> extends SomeClass<T> 

I'd understand the second example as a way to reuse and limit said general purpose container to instances of SomeSubClass and its children. It is entirely possible this is an abuse of Generics, brilliant coding or both.

However, since I'm still exploring the dark corners of this project, I figured I'd start with a question that nagged me and appears to be of some interest to others.

========================================================================

Final Edit: The original author of the code started with a Generic data container to be subclassed, as well as contain other objects. This works well if you are a brilliant programmer with an excellent understanding of the code as well as the ability to contain it all in your short term memory. Alas, I'm none of the above.

As well as using it for more than 10 subclasses, he needed to use it for other purposes and simply used the above with Object. In this case, not needing to cast let him return SomeClass from functions, leaving himself and the compiler the only two to really know the class.

I'm tempted to call this an abuse of OOD and generics, but I'm loath to do so while so much of the project is still entangled and obscured by this crazy cat's cradle. For all I know, there some very good reason to have done so.

========================================================================

Post Final Edit (yes I know)

This turned out to be due to a case of curiously recurring generic pattern.

Answer 1

The best reason I can see is that it makes it clear that it's not that the code predates generics, but that this instance of SomeClass really is parameterized with Object. Sort of an internal code documentation thing.

Let's use List as an example: List<Object> says "this is a list I might put anything in" whereas (as you know) List<Foo> says "this is a list I'm only going to put Foo instances (and subtypes) in." But just using List could mean either "this is a list I might put anything in" or "this is a List in code that predates generics, but we only put X in." So by using the type parameter <Object>, the author emphasizes that it really is that the list might have anything in it, not just that it's old code.

You're right that it doesn't provide anything on top of just SomeClass someClass = new SomeClass(); in terms of whether casting is required, etc. That's why I called it a code documentation thing.