Если Вы решите, что узкие рамки апи Bukkit не для Вас (А вы обязательно решите так, как только захотите сделать, что-то более менее сложное и интересное) и на вашем воркспейсе появится CraftBukkit.

Джарка импортируется как и все остальные, для прикрепления исходных кодов, потребуется все файлы из net.minecraft.server обернуть в папку с версией сервера, в случае крайней версии это v1_7_R1.
Полный путь файлов после оборота составит net.minecraft.server.v1_7_R1.*

Как вы заметили версия включена в путь файлов, это значит, что весь ваш импорт, зависимости и костыли перестают работать при изменении версии CraftBukkit автоматически и неотвратимо если сделаны без учёта данной возможности.

Команда craftbukkit сделала это специально для не очень умных людей которых 96%, так как при изменении версии, плагины с костылями, могут начать работать совсем совсем не так как задумано, вплоть до разрушения мира и иных повреждений.

Но запретный плод самый сладки, чуточку позже я распишу в данной статье, как:

Всё будет делатся без применения библиотек типа ASM, так как с ними не интересно, но с применением Unsafe там где оно надо (и не надо).

TTL undefined, так как кроме этой статьи сперва необходимо расписать статью про reflections и unsafe, без вся статья будет слишком сложной для тех кто и без этой статьи всё умеет делать.

На этой стадии извращенцы всех мастей начинают соревноваться в остроумности (не хуже петросянов), в интернетах можно найти методы определения версии вплоть до чтения жарки на предмет наличия папок или чтения конфигурации или даже сверки жарки по контрольным числам, знайте это всё ересь.

В настоящий момент я не до конца выучил архитектуру виртуальной машины, однако суть в том, что "переменные" могут быть названы по имени интерфейса, они вообще могут быть названы как угодно, это не важно, все переменные на объекты являются для виртуальной машины одинаковыми и сами по себе тип переменной не держат.

Тип прописан первым "тайным" полем внутри инстанса объекта до полей и после карты синхронизации, тип указывает на системный объект (не описанный каким либо классом явы) который держит в себе карту всех необходимых значений и в одном из полей указатель на вполне "явовский" класс, это позволяет изменить класс всех уже загруженных объектов переписав системный объект или изменить класс какого либо объекта на произвольный (только будут глюки если размеры объектов не совпадают)(очень большие глюки, вплоть до падения JVM при сборке мусора, что может произойти далеко не сразу и доставит кучу проблем при попытке отладить).

Так что, у нас как бы переменная не называлась и какой бы тим не имела, если там есть валидный объект, он будет иметь подпись класса который интерфейс реализует.

Например:

		Server s = Bukkit.getServer();
		System.out.println(s.getClass().getPackage());

Все "объекты" что здесь засветились описаны интерфейсами, которые не указывают на конкретную версию ведра, однако за Server прячется CraftServer который декларацию версии имеет.
В результате выполнения этого кода мы получим

[21:08:39] [Server thread/INFO]: package org.bukkit.craftbukkit.v1_7_R1, Bukkit, version unknown

Сплитим декларацию пакета по "точкам" и берём крайный сегмент, это и будет наша версия, вне зависимости от попыток сумеречного гения из команды баккита скрыть версию, изменить её, делать что либо в рантайме, достаточно достать версию именно этим методом и никуда она от вас не денется.

Здорово, конечно, но вряд ли тут найдутся мастера в этой сфере)
З.Ы. Спасибо за информацию, возможно пригодится