Есть jar-файл, в нем соответственно .class-файлы, какие из них являются членами одного и того же runtime package? Те что лежат в одной и той же поддиректории?

Здравствуйте, Аноним, Вы писали:

А>Есть jar-файл, в нем соответственно .class-файлы, какие из них являются членами одного и того же runtime package? Те что лежат в одной и той же поддиректории?
Да, если мы говорим о package. Что такое runtime package я не знаю.

Выдержка из The JavaTM Virtual Machine Specification:

5.4.4 Access Control
A class or interface C is accessible to a class or interface D if and only if either of the following conditions are true:

* C is public.

* C and D are members of the same runtime package

К сожалению меня интересует именно runtime package, а не package. Впрочем может это одно и то же?

Здравствуйте, <Аноним>, Вы писали:

А>К сожалению меня интересует именно runtime package, а не package. Впрочем может это одно и то же?
точно не одно и то же. runtime package определяется парой — имя пакета, classloader. Т.е. классы, принадлежащие пакетам с одинаковыми именами, но загруженные разными class loader-ами принадлежат разным runtime package-ам.Ю, и област вилимомти "по умолчанию" для них не работает (проверено).

Читаю спецификацию — The loading process is implemented by the class ClassLoader and its subclasses.
Нигде не нашел этого самого класса ClassLoader. Объясните пожалуйста, что это такое и что он делает?
Разве задача загрузки .class-файла — не полностью зависит от самой реализации ява-машины?
И как определить какой ClassLoader необходимо использовать для каждого файла?

Нашел класс ClassLoader... хм... разобрал его код:

void addClass(java.lang.Class);
  Code:
   0:    aload_0
   1:    getfield    #586; //Field classes:Ljava/util/Vector;
   4:    aload_1
   5:    invokevirtual    #722; //Method java/util/Vector.addElement:(Ljava/lang/Object;)V
   8:    return

судя по этом и другим фрагментам — он умеет загружать классы. Как это возможно, он же сам — класс! Кто его загрузит?

Здравствуйте, Аноним, Вы писали:

А>Нашел класс ClassLoader... хм... разобрал его код:
А>судя по этом и другим фрагментам — он умеет загружать классы. Как это возможно, он же сам — класс! Кто его загрузит?

Есть такая штука, как bootstrap classloader (он обычно вообще native), вот он и грузит. Но реально цепочка несолько длинее, по этому рекомендую прочитать например здесь

Так, если я правильно понял — класс может грузиться двумя способами — bootstrap — то есть неким способом, реализованным автором JVM и через class loader'ы... Дабы избежать косяков при переводе с английского буду цитировать

Whenever a new JVM is started by typing java MyMainClass, the "bootstrap class loader" is responsible for loading key Java classes like java.lang.Object and other runtime code into memory first. The runtime classes are packaged inside of the JRE\lib\rt.jar file. We cannot find the details of the bootstrap class loader in the Java documentation, since this is a native implementation. For the same reason, the behavior of the bootstrap class loader will also differ across JVMs.

что отсюда следует?
в этом архивчике лежат все базовые классы явы, такие как Object, Class, Byte, ClassLoader... Логично считать, что этот jar не имеет ссылок на классы, лежащие за его пределами. Очевидно он — базовый кирпичик. как я понял — я могу грузить его как мне пожелается, хранить в памяти или подгружать динамически, то есть все его классы грузятся без classloader'ов. Я прав?
Далее неясные мне моменты:
1.

In Java, a class is identified by its fully qualified class name. The fully qualified class name consists of the package name and the class name.

вот например класс java.lang.Object — имеет имя Object и входит в пакет (package) java.lang? верно? все так просто или какой-то подвох?
2. так, теперь попытаюсь задать вопрос, который не совсем могу сформулировать...
вот есть КЛАСС ClassLoader. следовательно загрузка какого либо класса с его помощью — будет являться частью исходника на яве и в итоге разложится в некие опкоды ява машины. то есть по сути ява-машина не должна волноваться о загруженных таким образом классах — они ведь будут загружаться "сами собой", если машина правильно выполняет все опкоды. зачем же тогда в спецификации ява машины так много уделено class loader'ам? по сути ведь при написании ява-машины не надо реализовывать загрузку классов иначе чем через bootstrap...
3. собственно вернусь к теме. вот если мы загружаем все классы из rt.jar bootstrap'ом, то runtime package для каждого из них будет зависеть только от package? ведь все они грузятся одинаковым лоадером....
4. и напоследок чтобы добить уважаемых экспертов своей глупостью — а что, в J2ME ClassLoader'ов вообще нет? я сколько не глядел — нигде не нашел.

Здравствуйте, Аноним, Вы писали:

А>Так, если я правильно понял — класс может грузиться двумя способами — bootstrap — то есть неким способом, реализованным автором JVM и через class loader'ы...
Только строго определенные классы грузяться bootstrap. Далее идет класслоадер для extensions, а потом AppClassLoader (который по совместительству становиться класслоадером, который можно получить через getSystemClassLoader(). И вот уже этот системный класслоадер грузит пользовательские классы. Программист может сделать свой класслоадер и используя методы http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html попросить загрузить какой-то класс, обеспечив тем самым возможность изоляции (например так делает tomcat для загрузки разных контекстов).

А>в этом архивчике лежат все базовые классы явы, такие как Object, Class, Byte, ClassLoader... Логично считать, что этот jar не имеет ссылок на классы, лежащие за его пределами. Очевидно он — базовый кирпичик. как я понял — я могу грузить его как мне пожелается, хранить в памяти или подгружать динамически, то есть все его классы грузятся без classloader'ов. Я прав?
Нет. Они грузяться bootstrap класслоадером, который не может быть выгружен. Подменить rt.jar можно только при запуске jvm например у Sun есть -Xbootclasspath параметр.
А>вот например класс java.lang.Object — имеет имя Object и входит в пакет (package) java.lang? верно? все так просто или какой-то подвох?
Ну да. org.mysuper.Test и есть идентификация. Где этот класс jvm найдет первым (обходя classpath) тот и загрузит. (правда нужно иметь ввиду указанное Lucker выше про разные класслоадеры)

А>2. так, теперь попытаюсь задать вопрос, который не совсем могу сформулировать...
А> зачем же тогда в спецификации ява машины так много уделено class loader'ам? по сути ведь при написании ява-машины не надо реализовывать загрузку классов иначе чем через bootstrap...
Потому, что класслоадеры — это сложная и нужная фича jvm. Механизм класслоадеров позволяет делать очень много, например создание классов в рантайме, изоляция, безопасность и т.д.

А>3. собственно вернусь к теме. вот если мы загружаем все классы из rt.jar bootstrap'ом, то runtime package для каждого из них будет зависеть только от package? ведь все они грузятся одинаковым лоадером....
он будет соствалять package + bootstrap clzloader. Пользовательские классы автоматически будут в другом runtime package, т.к. их грузит другой класслоадер (AppClassloader), т.е. подсунуть свой класс в java.lang пакет не получится.

А>4. и напоследок чтобы добить уважаемых экспертов своей глупостью — а что, в J2ME ClassLoader'ов вообще нет? я сколько не глядел — нигде не нашел.
Не работал, но слышал там что-то из-за упрощенной модели безопасности свои класслоадеры создавать нельзя... но могу ошибаться...

Здравствуйте, Lucker, Вы писали:

А>>К сожалению меня интересует именно runtime package, а не package. Впрочем может это одно и то же?
L>точно не одно и то же. runtime package определяется парой — имя пакета, classloader. Т.е. классы, принадлежащие пакетам с одинаковыми именами, но загруженные разными class loader-ами принадлежат разным runtime package-ам.Ю, и област вилимомти «по умолчанию» для них не работает (проверено).

Они же еще могут быть «унаследованы». Тогда в одну сторону видимость есть.

Здравствуйте, aka50, Вы писали:

А>>в этом архивчике лежат все базовые классы явы, такие как Object, Class, Byte, ClassLoader... Логично считать, что этот jar не имеет ссылок на классы, лежащие за его пределами. Очевидно он — базовый кирпичик. как я понял — я могу грузить его как мне пожелается, хранить в памяти или подгружать динамически, то есть все его классы грузятся без classloader'ов. Я прав?
A>Нет. Они грузяться bootstrap класслоадером, который не может быть выгружен.

Я имею ввиду — могу грузить как хочу — если я пишу ява машину — ведь реализация процесса загрузки bootstrap'ом абсолютно свобода. Я пытаюсь действительно написать свою ява машину — не для коммерции, а так, для общего развития и понимания того как она работает.

А>>3. собственно вернусь к теме. вот если мы загружаем все классы из rt.jar bootstrap'ом, то runtime package для каждого из них будет зависеть только от package? ведь все они грузятся одинаковым лоадером....
A>он будет соствалять package + bootstrap clzloader. Пользовательские классы автоматически будут в другом runtime package, т.к. их грузит другой класслоадер (AppClassloader), т.е. подсунуть свой класс в java.lang пакет не получится.

не совсем понял, это "да" или "нет". если моя ява машина загружает bootstrap'ом все классы из этого rt.jar, то получается что в одном runtime package будут находиться классы, у которых одинаковый package, верно? То есть как бы у каждого класс-лоадера, включая бутсрэповский есть некое пространство runtime package'й, которые для каждого конкретного класс-лоадера зависят только от package'й? ща, пример
java.lang.Object
java.lang.Byte
-эти два класса грузятся бутстрэпом, принадлежат одному пакету java.lang, соответственно принадлежат одному runtime package
myPackage.MyClass1
myPackage.MyClass2
-если они грузятся одинаковым класс-лоадером, они принадлежат одному runtime package, если разными, то разным, так?

А>>4. и напоследок чтобы добить уважаемых экспертов своей глупостью — а что, в J2ME ClassLoader'ов вообще нет? я сколько не глядел — нигде не нашел.
A>Не работал, но слышал там что-то из-за упрощенной модели безопасности свои класслоадеры создавать нельзя... но могу ошибаться...

Очевидно не ошибаетесь. полуается что все классы в J2ME грузятся bootstrap'ом и на класслоадеры вообще можно забить.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, aka50, Вы писали:

А>Я имею ввиду — могу грузить как хочу — если я пишу ява машину — ведь реализация процесса загрузки bootstrap'ом абсолютно свобода. Я пытаюсь действительно написать свою ява машину — не для коммерции, а так, для общего развития и понимания того как она работает.
У... грандиозно . Чтобы не изобретать лисапед рекомендую глянуть исходники либо самой жавы либо http://harmony.apache.org и уже после их изучения много думать

А>>>3. собственно вернусь к теме. вот если мы загружаем все классы из rt.jar bootstrap'ом, то runtime package для каждого из них будет зависеть только от package? ведь все они грузятся одинаковым лоадером....
A>>он будет соствалять package + bootstrap clzloader. Пользовательские классы автоматически будут в другом runtime package, т.к. их грузит другой класслоадер (AppClassloader), т.е. подсунуть свой класс в java.lang пакет не получится.

А>не совсем понял, это "да" или "нет". если моя ява машина загружает bootstrap'ом все классы из этого rt.jar, то получается что в одном runtime package будут находиться классы, у которых одинаковый package, верно?
Да. В пределах одного класслоадера это один runtime package.

Здравствуйте, Аноним, Вы писали:

А>4. и напоследок чтобы добить уважаемых экспертов своей глупостью — а что, в J2ME ClassLoader'ов вообще нет? я сколько не глядел — нигде не нашел.
Да, пользовательских classloader'ов там нет, только стандартный

A>У... грандиозно . Чтобы не изобретать лисапед рекомендую глянуть исходники либо самой жавы либо http://harmony.apache.org и уже после их изучения много думать

у одного из уважаемых товарищей форума видел в подписи фразу "Изопретение своего велосипеда повышает уровень квалификации программиста" или как-то так.

A>Да. В пределах одного класслоадера это один runtime package.

Вот. то что я и хотел выяснить. то етсь в случае J2ME (runtime package == package). Огромное спасибо за ссылки и помощь.

Здравствуйте, Аноним, Вы писали:

А>Вот. то что я и хотел выяснить. то етсь в случае J2ME (runtime package == package). Огромное спасибо за ссылки и помощь.
ИМХО, в случае J2ME не обязатеьлно читать The JavaTM Virtual Machine Specification. KVM это совсем другие спецификации.

Здравствуйте, Blazkowicz, Вы писали:

А>>Вот. то что я и хотел выяснить. то етсь в случае J2ME (runtime package == package). Огромное спасибо за ссылки и помощь.
B>ИМХО, в случае J2ME не обязатеьлно читать The JavaTM Virtual Machine Specification. KVM это совсем другие спецификации.
Тогда надо брать не только KVM: ещё есть AOT компиляция, желехная поддержка Java, JVM'ы "почти" соответствующие VM от Sun'а для J2SE.
J2ME, кстати, не ограничивается только CLDC и MIDP. В конфигурации CDC есть возможность использовать свой класслоадер (по крайней мере присутствует класс java.lang.ClassLoader)

Здравствуйте, Аноним, Вы писали:

A>>У... грандиозно . Чтобы не изобретать лисапед рекомендую глянуть исходники либо самой жавы либо http://harmony.apache.org и уже после их изучения много думать

А>у одного из уважаемых товарищей форума видел в подписи фразу "Изопретение своего велосипеда повышает уровень квалификации программиста" или как-то так.

Правильно написано но я бы добавил: "Изопретение и воплощение своего велосипеда повышает уровень квалификации программиста". А недоделанные лисапеды не очень хорошо повышают, лучше попроще лисапед выбрать (например свою простенькую vm для совсем простого языка). Вероятность довести до завершения гораздо выше .

Здравствуйте, aefimov, Вы писали:

A>Они же еще могут быть «унаследованы». Тогда в одну сторону видимость есть.
это как?

Здравствуйте, Lucker, Вы писали:

A>>Они же еще могут быть «унаследованы». Тогда в одну сторону видимость есть.
L>это как?

ClassLoader A
+- ClassLoader B
ClassLoader C

B имеет парента -- A
С отдельный

A и C не видят кроме себя ничего вокруг
B не видит C, но видит A.