Removing final on classes (Access Transformers)

[HashtagShell]

Some classes in Minecraft are final, probably the most commonly used being ItemStack. I need to subclass this class. Reflection cannot be used for this. So I added a line in my AT file

public-f net.minecraft.item.ItemStack

and rebuilt the workspace. ItemStack was not final. The AT file is being loaded, I successfully used it to make a field public. I looked through FG's and SS's sources, and it would seem to me that this should work, seeing that the final flag in the JVM is the same for classes and members. Making a class nonfinal should be possible with bytecode modification, so unless there is an explicit reason to disallow such ATs or there is a mistake on my part somewhere, I would see this as a bug.

I am essentially trying to get a callback on any edits that happen to a specific instance of an ItemStack (that I create), that is changes in the contained item, and, more importantly, its size. Usually, the way to do this is by creating a subclass. If there is any other way I will be happy to use that instead.

Edited March 25, 2017 by HashtagShell

[shadowfacts]

Why on earth do you even want to extend ItemStack?

[HashtagShell]

  On 3/25/2017 at 10:17 PM, HashtagShell said:

I am essentially trying to get a callback on any edits that happen to a specific instance of an ItemStack (that I create), that is changes in the contained item, and, more importantly, its size. 

Expand  

 

 

[loordgek]

in a inventory that you made??

[HashtagShell]

I am afraid not. I am giving out an ItemStack to some unknown automation function, and if it makes any changes to it, I need to know about it to act upon those changes. The function also doesn't return execution to me (rather it calls my function through an interface call, and I return execution along with the ItemStack to it), so I cannot check for any changes, it has to be a callback on the setCount or whatever methods. Note that even if the function stores the instance around for a few years, and then changes it, I still want to act upon it.

 

I would see my subclass looking something like this:

public class ReflexiveStack extends ItemStack
{
  //Constructor
  
  @Override
  public void setCount(int count)
  {
    //Handle change
    super.setCount(count);
  }
}

 

[HashtagShell]

I actually want my subclass to vanish as soon as the item is serialised, cloned, etc.

Picture the following:

1. Function gets an ItemStack instance from me
2. It expects a reference to the same instance to exist in my code (ie. the stack is passed by reference)
3. So it can edit the stack without the need to give it back to me
4. Usually, this is fine, but I need to do extra things when it edits this particular instance, to simulate the "passed by reference" contract
5. Once it clones, serialises, etc. the stack, the function can no longer expect the "passed by reference" contract to be kept, so I don't want to take any actions.
6. If it needs this contract, it will re-query the instance from me, at which point #2 applies.

[HashtagShell]

"I am afraid not" and the rest of the comment was in response to loordgek's question, if it was an inventory that I had created.

 

This "automation function" is any function that can make changes to the ItemStack in general - usually this is a method in some TileEntity.

Picture me having a TileEntity, which a hopper is pumping into. The hopper will query for a stack in my slot, and directly make changes to it, without returning it - it expects that I passed the stack by reference. I need to complement this by reference passing with some extra functionality.

[HashtagShell]

No. If I meant after the chunk was reloaded, I would say I needed it be persistent or something like that. "A few years later" means that even if this instance (instance requires no serialisation, cloning, etc.) of the ItemStack was kept around for years, I still would want the callback. This was a very unreal and impractical example of a chunk that would be kept loaded for years.

[HashtagShell]

So, specifics:

I am making an IInventory that doesn't store its contents as a whole but shares contents with another tile in the world.

You are of course familiar with the getStackInSlot function, which (by reference) returns the ItemStack in a slot. I need to return the unity of two stacks to this function, so I create a new one with its count being sum of the counts of the two input stacks. Say, that any tile (picture hopper, etc.) can query this stack, and because it expects the by reference thing, it will directly modify it. But, because I created a new stack in the getStackInSlot function, the changes will not be automatically reflected in my inventory. Plus, I need to split the change evenly between the two original ItemStacks, which is what I hoped to do in the overridden ItemStack class.

Essentially, I am trying to have an inventory act as a unity of two, but machines expecting ItemStacks to be passed by reference are making this painful.

[HashtagShell]

This looks nice, however: Won't many modded tiles try to cast my tile to IInventory? What if I want to use ISided? Why can the IItemHandler#getStackInSlot function return null, all (at least Mojang's) code uses NonNullLists and ItemStack.EMPTY everywhere?

[loordgek]

the javadoc is outdated null = ItemStack.EMPTY

[HashtagShell]

Vanilla tiles still do implement IInventory, don't they? Wouldn't that cause compatibility issues? Say that I wanted to check if a block is an inventory, how would I go about that when there are still IInventories around?

[loordgek]

no forge adds a wrapper

 

https://github.com/MinecraftForge/MinecraftForge/blob/1.11.x/patches/minecraft/net/minecraft/tileentity/TileEntityFurnace.java.patch#L78-L93

and for everything else

[HashtagShell]

So I don't implement anything, but create IItemHandler instances for every side that I want to handle, store them in instance fields, and if <T> in getCapability is of type IItemHandler (for which I check by reference comparing the queried capability with net.minecraftforge.items.CapabilityItemHandler.ITEM_HANDLER_CAPABILITY) I return the IItemHandler instance for the appropriate side, but I need to do an unchecked cast to <T>, because the compiler doesn't know I verified <T> though the capability?

 

This capability system looks cool, also appreciate the unified energy storage capability

[loordgek]

  On 3/25/2017 at 11:29 PM, HashtagShell said:

but I need to do an unchecked cast to <T>, because the compiler doesn't know I verified <T> though the capability?

Expand  

no do it like so

@Override
    public <T> T getCapability(Capability<T> capability, EnumFacing facing) {
        if (capability == CapabilityItemHandler.ITEM_HANDLER_CAPABILITY)
            return CapabilityItemHandler.ITEM_HANDLER_CAPABILITY.cast(fuelSlot);

        return super.getCapability(capability, facing);
    }

lets post this for fun

[HashtagShell]

Hmm... that method is just doing an unchecked cast and suppressing the warning - which I can also do. A suppressed unchecked cast seems more readable to me. Besides, Forge (in the Furnace for example) just casts it directly. Not that there is a big difference, except maybe a method call overhead, which is like nonexistent these days.

[HashtagShell]

Thanks, this pretty much solved problem.

Coming back to the original question, are we not supposed to de-finalize classes, am I doing something wrong, or is this a bug and should be reported?

[HashtagShell]

It didn't work, ItemStack still was final, even though I added the AT. If it had worked the first time, I wouldn't have reason to post anything in the first place.

 

(Just to be clear I won't be subclassing it but using the Cap system instead, tis just theoretical now)

Edited March 26, 2017 by HashtagShell

[HashtagShell]

Not sure, but as long as FG's/SS's code supports it, I'm cool. Probably some stupid mistake or typo, which I feel it isn't necessary to hunt down anymore. Thanks a lot!