Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

@ObjectHolder going away in 1.13?


Cadiboo
 Share

Recommended Posts

I was told that the @ObjectHolder annotation is going away in 1.13 due to Java’s internal reflection being changed from Java 8 to Java 9. I understand how this breaks a lot of code, but I don’t see how it makes it impossible to have the annotation. I think that the annotation is vital so that mods can override other mods items and blocks easily. It also provides support for adding and removing mods without restarting the game.

 

Edit: I’ve seen this post, and I understand how fields with objectholder might not be allowed to be final, but I don’t see why this would cause @ObjectHolder to be removed entirely.

On 8/14/2018 at 4:59 AM, diesieben07 said:

This has nothing to do with security. Doing stuff like changing final (and especially static final) fields breaks the JVM or at least any optimizations it can do.

Edited by Cadiboo

About Me

Spoiler

My Discord - Cadiboo#8887

My WebsiteCadiboo.github.io

My ModsCadiboo.github.io/projects

My TutorialsCadiboo.github.io/tutorials

Versions below 1.14.4 are no longer supported on this forum. Use the latest version to receive support.

When asking support remember to include all relevant log files (logs are found in .minecraft/logs/), code if applicable and screenshots if possible.

Only download mods from trusted sites like CurseForge (minecraft.curseforge.com). A list of bad sites can be found here, with more information available at stopmodreposts.org

Edit your own signature at www.minecraftforge.net/forum/settings/signature/ (Make sure to check its compatibility with the Dark Theme)

Link to comment
Share on other sites

Well so far it's still present on forge's github in the 1.13 branch. And from what I can tell there are issues with gaining access to private things within a module that isn't "open" to reflection. So in theory they could still function just fine without the final modifier.

Worst case scenario we will have to replace them with a lazy getter that would querry the registry. Something like this. For example(not intended for actual use, just an example of how you can acheive similar functionality)

public static final Lazy<Block> TEST_BLOCK = Util.querry(new ResourceLocation(MODID, "test_block"), Block.class);

...

class Util
{
    private static final Map<Class<?>, IForgeRegistry<?>> regCache = Maps.newHashMap();
    public static <R extends IForgeRegistryEntry<R>, T extends IForgeRegistry<R>>T getCachedRegistry(Class<R> registryClass)
    {
        if (!regCache.containsKey(registryClass))
        {
            IForgeRegistry reg = GameRegistry.findRegistry(registryClass);
            if (reg == null)
            {
                throw new IllegalArgumentException("Not a registry object!");
            }
            
            regCache.put(registryClass, reg);
        }

        return (T) regCache.get(registryClass);
    }
    
    public static <T extends IForgeRegistryEntry<T>>Lazy<T> querry(ResourceLocation name, Class<T> registryClass)
    {
        return new Lazy<T>(() -> getCachedRegistry(registryClass).getValue(name));
    }
}

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.