Как объединить файл package в один
Обновлено: 05.07.2024
Пакеты. Использование пакетов в Java. Директивы import и package . Компилированные модули ( *.java ). Промежуточные .class файлы. Структура проекта. Использование стандартных библиотек Java
Содержание
- 1. Пакеты в Java
- 2. Как подключить пакет к существующему проекту в Java Eclipse? Структура проекта, который содержит пакеты
- 3. Какая общая форма вызова класса из пакета? Пример
- 4. Пример, который демонстрирует использование одного имени класса в разных пакетах и в разных каталогах (папках)
- 5. Какое назначение директивы import ? Общая форма. Пример
- 6. Как в директиве import указать, что могут быть использованы все классы из данного пакета?
- 7. Что собой представляет ключевое слово package ?
- 8. Что такое компилированный модуль в Java?
- 9. Какие требования к реализации компилированного модуля ( .java )?
- 10. Сколько классов могут быть реализованы в компилированном модуле?
- 11. Какое назначение файлов с расширением .class ?
- 12. Какие преимущества дает использование ключевых слов package и import ?
- 13. Пример, который демонстрирует структуру проекта и размещение компилированных модулей
- 14. Пример подключения класса из стандартной библиотеки Java
Поиск на других ресурсах:
1. Пакеты в Java
Каждый проект на языке Java в своей работе использует так называемые пакеты. Пакет – это отдельный модуль (пространство имен), которому соответствует одноименный каталог (папка). Пакет содержит библиотеки (группы) классов. Эти классы объединены между собой в одном пространстве имен или пакете. Количество реализованных классов в пакете неограничено. Классы, которые объявляются в пакете, реализуются в файлах с расширением *.java .
Пакеты могут иметь разнообразные уровни вложения (подкаталоги, подпапки). На разных уровнях вложения пакетов имена могут повторяться. Сохранение пакетов и файлов *.java в проекте осуществляется в виде древовидной структуры файловой системы.
2. Как подключить пакет к существующему проекту в Java Eclipse? Структура проекта, который содержит пакеты
В системе Java Eclipse подключение пакета есть стандартной командой. Предварительно может быть создан проект. В проекте может размещаться произвольное количество пакетов. В каждом пакете может быть произвольное количество классов.
Для создания пакета в некотором проекте используется команда
В результате откроется окно, изображенное на рисунке 1. В окне указывается имя проекта и пакета, который будет размещаться в этом проекте.
После выбора кнопки Finish происходит следующее. Проекту с именем MyProject03 соответствует специальная папка (каталог) с таким же именем. В этом каталоге создается несколько подкаталогов (подпапок). Один из них подкаталог с именем src. В этом подкаталоге создается каталог MyPackage , соответствующий создаваемому пакету.
3. Какая общая форма вызова класса из пакета? Пример
Чтобы обратиться к имени класса из пакета используется следующая общая форма:
- PackageName – имя пакета, в котором реализован класс с именем ClassName ;
- ClassName – имя класса.
Если пакет PackageName1 содержит подпапку (подпакет) с именем PackageName2 , то доступ к классу с именем ClassName имеет вид:
Подобным образом формируется доступ к классу в случае более более сложных уровней вложения.
Например. Пусть задан пакет с именем Figures . В пакете реализованы два класса с именами Circle и Rectangle . Тогда, фрагмент кода, который создает объекты этих классов будет следующий:
4. Пример, который демонстрирует использование одного имени класса в разных пакетах и в разных каталогах (папках)
На рисунке 2 изображена иерархия, которую могут образовывать пакеты.
Рис. 2. В проекте MyProject03 три пакета с именами MyPackage01 , MyPackage02 , MyPackage02.MyFolder02
Как видно из рисунка, в проекте MyProject03 созданы 3 пакета с именами MyPackage01 , MyPackage02 , MyPackage03 . Каждый из пакетов имеет класс с одинаковым именем MyClass01 . Таким образом происходит разделение одинаковых имен.
Ниже приведен демонстрационный код, создающий объекты классов MyClass01 , которые размещены в разных пакетах (папках), согласно схеме из рисунка 2.
5. Какое назначение директивы import ? Общая форма. Пример
Директива import позволяет сократить весьма длинные строки обращений к классам (интерфейсам, перечислениям), которые реализованы в пакетах.
В простейшем случае общая форма директивы import следующая:
- PackageName – имя пакета, который подключается;
- ClassFileName – имя файла с расширением *.java , в котором реализован класс или группа классов, к которому нужно обращаться по сокращенному имени.
Чтобы из любого другого класса, который размещается в другом пакете данного проекта, иметь доступ к методам файла Circle.java из пакета Figures нужно в начале указать:
Ниже приводится пример подключения и использования класса Circle из другого пакета и другого класса.
Если в пакете OtherPackage убрать строку
то объект класса Circle нужно было бы создавать следующим образом
6. Как в директиве import указать, что могут быть использованы все классы из данного пакета?
Бывают случаи, когда в пакете реализованы несколько классов (файлов с расширениями *.java ) и возникает необходимость подключения всего множества классов. В этом случае общая форма директивы import может быть следующая:
- Package – имя пакета с библиотекой подключаемых классов.
7. Что собой представляет ключевое слово package ?
Ключевое слово package задает имя библиотеки, в которую могут входить разное количество компилированных модулей. Компилированные модули – это файлы с расширением .java .
Если в модуле (файле с расширением .java ) указывается строка наподобие
то это означает, что данный модуль есть частью библиотеки с именем PackageName .
8. Что такое компилированный модуль в Java?
Каждый компилированный модуль может содержать не большее одного открытого класса. Компилированный модуль входит в состав пакета. В пакете может быть любое количество компилированных модулей.
9. Какие требования к реализации компилированного модуля ( .java )?
К реализации компилированного модуля предъявляются следующие требования:
- имя компилированного модуля должно иметь расширение .java ;
- имя компилированного модуля без учета расширения .java должно совпадать с именем открытого ( public ) класса, который реализован в этом модуле;
- имя компилированного модуля и имя реализованного в нем открытого класса должны начинаться из большой буквы;
- в компилированном модуле может быть не более одного открытого ( public ) класса. Если в компилированном модуле есть еще другие (вспомогательные) классы, то они должны быть скрытыми (без модификатора public ).
10. Сколько классов могут быть реализованы в компилированном модуле?
Компилированный модуль может иметь любое количество классов. Однако, открытым ( public ) должен быть только один класс. Имя этого класса должно совпадать с именем компилированного модуля.
11. Какое назначение файлов с расширением .class ?
Файлы с расширением .class получаются в результате компиляции файлов с расширением .java (компилированных модулей). Файлы с расширением .class есть промежуточными файлами, которые затем объединяются компоновщиком в исполнительный модуль.
Например, в языке программирования Delphi временные скомпилированные файлы имели расширение *.dcu . В языке программирования C++ временные скомпилированные файлы имели расширение .obj . После компоновки из этих файлов получался *.exe файл (исполняемый модуль).
После этого, файлы с расширением .class объединяются в пакет и сжимаются утилитой JAR . Это все осуществляет интерпретатор Java.
12. Какие преимущества дает использование ключевых слов package и import ?
Использование ключевых слов package и import позволяет удобно поделить пространство имен таким образом, чтобы предотвратить возникновению конфликтов между разными разработчиками классов на Java.
13. Пример, который демонстрирует структуру проекта и размещение компилированных модулей
Пусть в Java Eclipse создан проект с именем Project03 . Проект размещается в папке по умолчанию, которая используется системой Java Eclipse. В проекте созданы 2 пакета с именами Figures , OtherPackage . В пакетах реализованы по одному компилированному модулю соответственно с именами Circle.java и MyClass.java . Рисунок 3 отображает структуру проекта Project03 системы Java Eclipse.
Рис. 3. Отображение структуры проекта Project03 в окне Package Explorer
В файле (модуле) Circle.java разработан класс Circle . В файле MyClass.java разработан класс MyClass . В классе MyClass из пакета OtherPackage (см. рис. 3) подключается модуль Circle.java с помощью директивы
Если компилятор встречает директиву import , он формирует полное имя с учетом пути к каталогу, который записан по умолчанию в системе.
таким образом, получается полное имя модуля Circle.java :
По желанию путь к каталогу (папке) по умолчанию можно изменить.
14. Пример подключения класса из стандартной библиотеки Java
Чтобы обратиться к имени класса из стандартной библиотеки Java используется один из двух способов:
- Использование полной формы или полного имени класса в библиотеке.
- Использование сокращенной формы имени класса. В этом случае, полное имя пакета с нужным классом, может быть задано явным образом с помощью директивы import .
Полная форма обращения к имени нужного класса в простейшем случае выглядит так
Например. Фрагмент кода, который использует класс Vector из стандартной библиотеки Java. В данном случае стандартная библиотека Java носит имя java.util .
В вышеприведенном коде происходит обращение к классу Vector по полному имени:
Всем нам хочется иметь много дополнительных материалов для красивой игры. Множество контента выпускается в формате .package, большое колличество которых тормозит производительность игры. С помощью простого процесса все файлы можно скомбинировать в один или несколько, в игре будут отображаться все материалы пака, но игра будет распознавать их как один файл и тормозить не будет, потому что ей не придется подгружать много пекеджей!
1) Скачайте последнюю версию Доступно только для пользователей
(Кликаем на Looking for the latest version? Download s3pe_)
2) Устанавливаем s3pe. Запускаем. Открывается окно
3) Выбираем New в пункте меню File
4) Кликаем по пустому белому полю в проекте и выбираем '(EXPERIMENTAL) As dbc. '
Открывается окошко
Нажмите на второй вариант и ОК
5) Выбираем в папке где хранится ваш дополнительный контент нужные вам .package файлы и кликаем по ОК.
У вас открывается такое окошко, как на скрине снизу, выбираем вариант без сохранения файла после каждого импорта (No), иначе импорт файлов будет длиться очень долго.
Пусть s3pe сделает свою работу. Импорт файлов может занять продолжительное время, так что не пугайтесь и просто дайте программе работать. В итоге получаем:
После того как все файлы будут импортированы, выберите в меню File команду Save as и сохраните в нужное место под нужным именем.
Итак! Мы получили один большой package!
На этом все.
Нажмите 'ОК'
В появившемся списке отсортируйте файлы по полю 'instance number', для этого включите галочку Sort, как снизу на скрине и нажмите на поле Instance:
Выберите все XML файлы которые имеют instance number '0000000000000', и у которых в конце EEB, и удалите, нажав ПКМ - Delete. (При этом файлы не исчезнут из списка, а будут зачеркнутыми. Это остатки от симс3паков, из которых вынули ваши пакаджи. Если будете паковать скин, например, то таких файлов не увидите, т. к. он изначально идет в пекедж. Если файлы уже зачеркнуты, до того, как это сделаете вы, ничего больше делать не нужно.
То, что зачеркнутым текстом, устарело. Новая версия SIM3PE автоматически удаляет ненужные XML. Они уже будут зачеркнутыми.
При необходимости повторите шаги 2-5.
Все, что вам понадобится для отображения дополнительных файлов в игре - это ваш новый скомбинированный файл. Так что те файлы, которые вы скомбинировали, удалите из папки Mods перед помещением туда вашего нового большого файла.
Вы можете комбинировать уже скобинированные .package файлы так же в один, а так же какой-то один новый .package комбинировать с уже сделанным сборником.
Но не увлекайтесь комбинированием. Вместо того чтобы делать один большой пекедж сделайте 3-4 сборных пакаджей. Например, один для каса, другой для мебели. Оптимальный вес одного файла-комбинации около 200 Mb. Так же постарайтесь держать колличество ваших пекеджей в папке Модс около 100.
Никогда не комбинируйте моды и дефолтные скинтоны. Вдруг вам захочется поменять скинтон? Вдруг вы обновите игру и мод будет несовместим с новой версией? Вам придется переделывать весь ваш сборниый .package!
S4pe - программа для редактирования package. Программа позволяет открывать package файлы, относящиеся к The Sims 4, извлекать и производить замену текстур, мешей и так далее. Работа с программой S4PE
Гайд от Just.
Перевод
Шаг 1
Открываем мод в формате package в программе S4PE. Для этого можно перетащить мод в программу, либо нажать File -> Open.
После этого откроется окно со списком
Шаг 2
Ищем STBL файл, который начинается на 0x12, другие не трогаем! Кликаем правой кнопкой мыши по нему и выбираем Edit STBL. Можете отсортировать файлы, нажав на шапку столбца TAG или Instance.
Шаг 3
В открывшимся окне вводим свой перевод. Слева оригинал, справа наш перевод. Для копирования текста выделяем его и нажимаем Ctrl+C.
Шаг 4
После того как переведены все строки в этом файле STBL, нажимаем SAVE и переходим к следующими файлу STBL с кодом 0x12. Когда Вы перевели все файлы STBL с кодом 0х12, сохраняем наш файл и кидаем в папку Mods.
P.S. Есть баг, не переводится последняя строка, когда сохраняем переведенный STBL файл, для этого нужно еще раз его открыть и перевести ее.
Так же если Вы плохо владеете английским, используйте лучше яндекс переводчик для этих нужд.
Экспорт перевода
Открываем мод в программе S4PE. Ищем все те же STBL файлы с кодом 0х12, кликаем правой кнопкой мыши по нему и выбираем Export ->To package. Пишем название файла (лучше писать название мода и приставку ru/rus, чтобы не путаться в дальнейшем) и нажимаем открыть.
Для того чтобы вытащить сразу несколько файлов STBL из мода, зажимаем Ctrl и нажимаем левой кнопкой мыши по файлам, которые нужны, а дальше все также через Export.
Если у Вас нет строки Edit STBL, то нужно переустановить программу (лучше использовать exe установщик).
Запаковка файлов Package
Шаг 1
Нажимаем File -> New
Шаг 2
Нажимаем Resource -> Import -> As dbc. выделяем файлы package, которые хотите запаковать, и нажимаем открыть. У нас открывается окно, где нужно дать имя нашему файлу package, в котором будут запакованы моды, пишем название и нажимаем сохранить.
Лучше запаковывать по категориям (одежда, обувь, прически, аксессуары и т.д.) и не превышать размера 2 гигабайта.
Иногда возникает необходимость разделить несколько пакетов, лежащих в одном пространстве имен по разным физическим путям. Например, если вы хотите иметь возможность передавать разную компоновку плагинов, имея возможность в последствии добавлять их, не контролируя их расположение, и, при этом, обращаться к ним через один namespace.
Эта шпаргалка, которая подойдет скорее для новичков, посвящена пространствам имен Python.
Давайте рассмотрим, как это можно сделать в разных версиях Python, так как хотя Python2 и перестает скоро поддерживаться, многие из нас как раз сейчас меж двух огней, и это как раз один из важных нюансов при переходе.
Рассмотрим такой пример:
Мы хотим получить структуру пакетов:
Содержимое файла module1
Содержимое файла module2
При этом пакеты распределены в такой структуре папок:
Допустим, что так или иначе path1 и path2 уже добавлены в sys.path. Нам надо получить доступ к module1 и module2:
Что произойдет в Python 3.7 при выполнении этого кода? Все работает чудесно:
С PEP-420 в Python 3.3, появилась поддержка неявных пространств имен. Кроме того при импорте пакета с версии py33 не надо создавать файлы __init__.py. А при импорте namespace, это просто _запрещено_. Если в одной или обоих директориях и именем namespace1 будет присутствовать файл __init__.py, произойдет ошибка на импорте второго пакета.
Таким образом наличие инишника явно определяет пакет, а пакеты объединять нельзя, это единая сущность. Если вы начинаете новый, независящий от старых разработок, проект и пакеты будут устанавливаться с помощью pip, то придерживаться надо именно такого способа. Однако иногда нам в наследство достается старый код, который тоже надо поддерживать, по-крайней мере некоторое время, или переносить на новую версию.
Перейдем к Python 2.7. С этой версией уже интереснее, нужно сначала добавлять __init__.py в каждую директорию для создания пакетов, иначе интерпретатор просто не распознает в этом наборе файлов пакет. А затем прописать в __init__ файлах относящихся к namespace1 явное объявление пространства имен, в противном случае, произойдет импорт только первого пакета.
Что при этом происходит? Когда интерпретатор доходит до первого импорта, выполняется поиск в sys.path пакета с таким именем, он находится в path1/namespace1 и интерпретатор выполняет path1/namespace1/__init__.py. Далее поиск не ведется. Однако функция extend_path сама выполняет поиск уже по всему sys.path, находит все пакеты с именем namespace1 и инишником и добавляет их в переменную __path__ пакета namespace1, которая используется для поиска дочерних пакетов в этом пространстве имен.
В официальных гайдах рекомендуется, чтобы инишники были одинаковыми при каждом размещении namespace1. На самом деле, они могут быть пустыми все, кроме первого, который находится при поиске в sys.path, в котором должен быть вызов pkgutil.extend_path, потому что остальные не выполняются. Однако, конечно, лучше чтобы действительно вызов был в каждом инишнике, чтобы не завязывать свою логику «на случай» и не гадать какой инишник выполнился первым, ведь порядок поиска может измениться. По этой же причине не стоит располагать никакую другую логику __init__ файлах области переменных.
Это сработает и в последующих версиях и этот код можно использовать для написания совместимого кода, но нужно учитывать, что выбранного способа надо придерживаться в каждом распространяемом пакете. Если на 3-й версии в некоторые пакеты положить инишник в вызовом pkgutil.extend_path, а некоторые оставить без инишника, это не сработает.
Кроме того этот вариант подходит и для случая, когда вы планируете устанавливать с помощью python setup.py install.
Еще один способ, который сейчас считается несколько устаревшим, но его еще можно много где встретить:
Модуль pkg_resources поставляется с пакетом setuptools. Здесь смысл такой же, что и в pkgutil — надо, чтобы каждый __init__ файл при каждом размещении namespace1 содержал одинаковое объявление пространства имен и отсутствовал любой другой код. При этом в setup.py надо регистрировать пространство имен namespace_packages=['namespace1']. Более подробное описание создания пакетов выходит за пределы этой статьи.
Кроме того часто можно встретить, такой код
Здесь логика простая — если не установлен setuptools, то используем pkgutil, который входит в стандартную библиотеку.
Если настроить одним из этих способов пространство имен, то из одного модуля можно звать другой. Например, изменим namespace1/package2/module2
И далее посмотрим, что будет, если мы по ошибке назвали новый пакет так же как уже существующий и обернули тем же namespace'ом. Например, будут два пакета в разных местах с названием package1.
В этом случае импортирован будет только первый и доступа к module2 не будет. Пакеты объединить нельзя.
Читайте также: