Support MyPet 4 entity lookup while retaining MyPet 3 compatibility

[mercurialmusic]

Description

This updates the Jobs MyPet hook to support the rewritten MyPet 4 API while retaining compatibility with the MyPet 3 API currently used to compile Jobs.

MyPet 4 removed MyPetBukkitEntity. As a result, the existing instanceof MyPetBukkitEntity check throws a NoClassDefFoundError whenever Jobs handles an applicable EntityDeathEvent on a server running MyPet 4.

MyPet 4 pets are now regular Bukkit entities registered with MyPet's PetManager. The updated hook detects the available MyPet API and uses the appropriate lookup path:

• MyPet 3 continues to use the existing MyPetBukkitEntity implementation.
• MyPet 4 uses MyPetApi#getPetManager() and PetManager#getPetFromEntity(Entity).
• Owner checks under MyPet 4 compare the pet owner's UUID with the supplied player's UUID.
• If the expected modern API cannot be initialized, the hook fails safely rather than attempting to access the removed legacy classes.

Reflection is used for the MyPet 4 path so Jobs can continue compiling against its existing MyPet 3 dependency without requiring a broader dependency or build-system change. This was done largely because MyPet 4 has gone open-source premium, it's only just released, and I expect many users will remain on MyPet 3 for a while.

Testing

Tested with:

• Jobs 5.2.6.6
• MyPet 4
• Paper 26.2
• Java 25

The plugin compiled successfully and loaded without errors. The previous NoClassDefFoundError console spam is no longer present, and the MyPet integration appears to function correctly during initial testing.

Scope

This change is limited to MyPetManager and does not modify Jobs' bundled MyPet dependency, general payment handling, or other plugin hooks.

Closes #1989

[UserDerezzed]

Can I perhaps suggest doing this in the reverse way - use reflection for MyPet 3 (the legacy version) and direct import MyPet 4? Looks good otherwise, I also made my own fork but forgot to PR it :P

[mercurialmusic]

Can I perhaps suggest doing this in the reverse way - use reflection for MyPet 3 (the legacy version) and direct import MyPet 4? Looks good otherwise, I also made my own fork but forgot to PR it :P

Thanks for the review and direction! I’ve updated the implementation so that MyPet 4 is now the primary compile-time API, with MyPet 3 compatibility handled through reflection instead.

The revised changes now:

• Compile directly against de.keyle:mypet-api:4.0.0.
• Use MyPetApi#getPetManager() and PetManager#getPetFromEntity(Entity) directly for MyPet 4.
• Remove the bundled MyPet 3 API JAR from the repository.
• Isolate all MyPet 3-specific classes and calls inside a reflective compatibility adapter.
• Resolve ownership from the actual pet entity under both API versions.

I also rechecked the implementation against the current MyPet 4 source and the MyPet 3 source. The expected methods and package names match both versions, and isolated runtime checks confirmed that:

• The MyPet 4 path works with the MyPet 3 classes completely absent.
• The MyPet 3 path works with the MyPet 4 entity and manager classes completely absent.
• Pet detection and owner UUID checks work correctly under both versions.
• Normal entities and incorrect owners are rejected.

The updated Jobs build completed successfully, and the plugin has been tested on Paper 26.2 with Java 25. It loads without errors, the previous NoClassDefFoundError console spam remains fixed, and the integration appears to be functioning correctly in live testing.

@UserDerezzed would still appreciate your review again as well!

[UserDerezzed]

Looks good to me :) just needs Jobs authors’ approvals