수정 전.
수정 후.
@SideOnly는 클래스고 메소드고 뭣이고 상관없이 붙어있는 내용물을 뒤틀린 황천으로 같이 끌고 간다는 걸 알려 드린 적이 있습니다. 바로 이전 글이죠. 그리고 이 @SideOnly 처리도 Transformer를 이용하는 것 같습니다. 저번에 화로 만졌던 그거 있죠? 그런 걸 쓴다는 겁니다.
그런데.. FMLLoadingPlugin 클래스에 붙이는 @TransformerExclusions가 제 발목을 잡았습니다. 이 어노테이션은 세상에나 세상에나 Transformer의 수정을 방어하는 기가 막힌 능력을 가졌습니다. 해당 어노테이션으로 전달한 문자열로 시작하는 package를 가진 클래스는 로드될 때 Transformer#transform(...)가 호출되지 않습니다.
그런데 제가 그만 착각을 해 버렸습니다. 위 설명대로 전달한 문자열로 시작하는 package를 가진 클래스를 보호하는 옵션을 전달한 문자열과 동일한 package를 가진 클래스를 보호하는 것으로 착각해 버린 것.
덕분에 두 개만이 적용되어야 했던(틱팀이 그렇게 착각했던..) Transformer Exclusions의 범위는 TTMP Core의 패키지 전체로 확대되어 버렸고, 따라서 바이트코드를 날려버리는 @SideOnly도 TTMP Core에서는 작동하지 않았습니다.
다음 상황은 불 보듯 뻔합니다. @SideOnly가 붙은 클래스를 사용하는 메소드는 해당 클래스 자체도 없어지기에 @SideOnly로 없애 주어야 "이 클래스 무슨 클래스냐"에러가 발생하지 않습니다. 그런데 @SideOnly의 효과가 TTMP Core에서는 없었으니 메소드도 안 사라졌고... DefaultStateMapper(로그에서는 IStateMapper)도 찾을 수 없었습니다.
..이상 틱팀의 디버깅 일지였습니다. 계속 TTMP Core에서 똥을 싸대면서 이거 왜 안돼냐 빼애액거리고 있다가 멘탈이 거세게 나가서 아무 클래스나 열어보면서 지푸라기라도 잡아 헤매고 있다가 IFMLLoadingPlugin의 저 어노테이션을 보는 순간 뇌에 벼락을 맞은 기분이었습니다.
뭔가 프로그래밍을 하다 보면 수상한 부분을 잘 찾아내게 되는 기분입니다(...). 실수하는 양은 변함이 없지만서도 말입니다. 깔!깔! 이게..아닌데...
여러분 TTMP는 안전합니다. 빨리 슈퍼너프의 세계로 오십시오.
공지 목록
