Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible wrong use of the "@SideOnly(Side.CLIENT)" #35

Closed
broncotc opened this issue Feb 12, 2019 · 3 comments
Closed

Possible wrong use of the "@SideOnly(Side.CLIENT)" #35

broncotc opened this issue Feb 12, 2019 · 3 comments

Comments

@broncotc
Copy link

broncotc commented Feb 12, 2019

The current file Charge.java consists 2 decorators of "@SideOnly(Side.CLIENT)" which will cause the mod built from trunk to crash. I was testing truck build due to the sponge incompatibility of the current beta 4 release.
In construction stage of loading module "charge", it throws an exception: "java.lang.RuntimeException: Attempted to load class mods/railcraft/api/charge/Charge$IZapEffectRenderer for invalid side SERVER". This implies the behavior of the decorator "@SideOnly(Side.CLIENT)" might be resisting the entire class/enum from loading instead of strip certain methods from a loadable class on the server side.
What I described here is not matching with the behavior documented here: ForgeDoc/Concepts/Sides , but removing the 2 "sideonly" decorations will make it load and work in the sponge server. Also the forge doc do suggest to not use this decoration except certain very specific circumstances.

Version numbers for your reference:
Forge: 14.23.5.2811
SpongeForge: 1.12.2-2768-7.1.5
Buildcraft: current git
Java: openjdk version "1.8.0_171"

Thank you for investigating into this.

@CovertJaguar
Copy link
Member

I admit something did feel off about #33. Hopefully it doesn't cause any issues with running on a normal dedicated server.

@liach
Copy link
Contributor

liach commented Feb 12, 2019

Duplicate of #33

@liach liach marked this as a duplicate of #33 Feb 12, 2019
@liach
Copy link
Contributor

liach commented Feb 12, 2019

The cause is clear: The code referencing the field is not removed in <clinit>. The modified version of #33 has fixed it.

@liach liach closed this as completed Feb 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants