C++ does not allow abstract static functions either. My Java is a bit rusty but adding a static function to ItemA should work (you haven't done that though). You don't really need a declaration in Item. I'm currently unsure how static functions work in Java when there is a similar named function in a superclass but my gut says it works fine.

That said, are you sure you need something like that? Java already comes with type information built in (in the form of a static variable of type java.lang.Class inside each class, including significant reflection capabilities). A lot of the reasons why you would handroll such a system in C++ can be dealt with in Java without actual extra work on your part.

Edit: come to think of it, there is no point to even make that a function. Just add a 'static final String myId = "blabliblub";' static data member to the individual classes.

If you just want to know if Item "i" is an instance of a certain derived class you can use "instanceof": http://www.java2s.com/Tutorial/Java/0060__Operators/TheinstanceofKeyword.htm

EDIT: "abstract static" doesn't make sense, if it's static it means you can access it from the class object, so Item.some_static_field should be always valid, but abstract means it's not defined there.

If you really want to stick to static functions and string ids you can do something like this I think:

class Item {
    abstract string getId();
}

class ItemA extends Item {
  static string getId() {
    return "ITEM_A";
  }

  string getId() {
    return ItemA.getId();
  }
}

void foo(Item i) {
  if (i.getId() == ItemA.getId()) {
    ...
  }
}

EDIT2: If you wan't to do different things for different Item derived classes you can do something better using function overloading.

If you have ItemA, ItemB and ItemC extending Item you add 3 "foo" functions that receive a concrete implementetion of Item as a parameter, instead of "Item", and the JRE resolves the type automatically.

class Item { ... }
class ItemA extends Item { ... }
class ItemB extends Item { ... }
class ItemC extends Item { ... }

void foo(ItemA item) { ... }
void foo(ItemB item) { ... }
void foo(ItemC item) { ... }

This also has some advantages on mantaining the code and adding more Item classes if needed, just add another "foo" function. You can even have a more complex inheritance (ItemD extends ItemA, for example) and you still only require one extra foo function.

Java has build-in support for classes. Something along

Item i = new Item();
if( i.getClass() == Item.class ) {
    ...
}

would do the trick. However, whether this is a meaningful way to solve OP's problem is another question as posters have already mentioned above...

Thanks for the feedback. I'll look into instanceof, it looks like it will do what I need for the type, though I'll still face the same problem for other pieces of data (Such as UUID).

... if you expand your explanation and tell us why are you trying to do that ( compare the object types ) maybe we could help you to come with a better approach to your problem...

To be honest, I don't know quite yet, the id will probably be used as keys in a HashMap, but I haven't gotten that far yet. Partly I'm just trying to understand the language itself.

class Item {
abstract string getId();
}

class ItemA extends Item {
static string getId() {
return "ITEM_A";
}

string getId() {
return ItemA.getId();
}
}

Tried this, but I got the error "Duplicate Function"

For now I'll go with this; not as clean as I'd like, but functional

class ItemA extends Item
{
  public static final String id = "ITEM_A";
  
  @Override
  public String getId()
  {
    return id;
  }
}

then call ItemA.id or i.getId()

To be honest, I don't know quite yet, the id will probably be used as keys in a HashMap, but I haven't gotten that far yet. Partly I'm just trying to understand the language itself.

If you don't know what you'll use the ID for then why do you care about it now? Do the agile thing and don't design something you're not going to use.

Also, Class objects work just fine as keys in a HashMap so there's no need to create IDs for them. If you need an identifier that can be stored in a file then the class name is the usual approach. A simple Class.forName(..) will convert that String back into a Class object which you can then use as a key.