private void button1_Click(object sender, EventArgs e)
{
if (folderBrowserDialog.ShowDialog() == DialogResult.OK)
{
path = folderBrowserDialog.SelectedPath;
fileSystemWatcher.Path = path;
string[] str = Directory.GetFiles(path);
string line;
fs = new FileStream(str[0], FileMode.Open, FileAccess.Read, FileShare.ReadWrite);
tr = new StreamReader(fs);
while ((line = tr.ReadLine()) != null)
{
listBox.Items.Add(line);
}
}
}
private void fileSystemWatcher_Changed(object sender, FileSystemEventArgs e)
{
string line;
line = tr.ReadLine();
listBox.Items.Add(line);
}
Он никуда не денется , он составлен как class abc.xyz.MyClassA
. Вы можете видеть это, если вы декомпилируете это .class
, например, используя javap
.
Если вы откроете файл .class любого из ваших классов, вы сможете увидеть детали пакета внутри него. В вашем случае, если вы откроете MyClassA.class
в текстовом редакторе, то вы увидите что-то вроде abc/xyz/MyClassA
. JVM будет использовать его как abc.xyz.MyClassA
. По этой причине, если нам нужно использовать этот класс в каком-то другом классе, нам нужно использовать его как import abc.xyz.MyClassA
.
Директивы, такие как объявление package
, а также операторы import
, вообще не генерируют никакого кода, они только влияют на то, как компилятор будет обрабатывать имена в пределах одной и той же единицы компиляции.
Таким образом, объявление типа
package abc.xyz;
public class MyClassA {
}
создает класс с определенным именем abc.xyz.MyClassA
или класс с простым именем MyClassA
в пакете abc.xyz
; оба означают одно и то же.
Полное имя хранится в файле .class
, который является единственной соответствующей информацией для JVM.
Существует соглашение для хранения такого файла как SimpleName.class
в каталоге, полученном из имени пакета, то есть abc/xyz/MyClassA.class
, присоединенного к javac
и используемого стандартными загрузчиками классов для поиска файл, когда запрашивается класс с таким именем. Очевидно, что наличие такого соглашения облегчает жизнь.
В принципе, возможны и другие способы хранения, и некоторые из них известны. Начиная с Java 9, эталонная реализация имеет формат изображения модуля, до этого был «архив данных общего класса», далее был «Pack200», формат архива, который не рекомендуется для удаления с JDK 11. [1120 ]
Обратите внимание, что даже jar-файлы, которые являются расширенными zip-файлами, не совсем то, что вы видите. Zip-файл состоит из линейной последовательности файловых записей, имеющих полное имя, поэтому в вашем случае у вас будет две записи, сообщающие об их именах как abc/xyz/MyClassA.class
и abc/xyz/MyClassB.class
, тогда как любая структура каталогов, показанная инструментами, фактически получается из этих имена и не подразумевает, что вложенные записи для abc
и xyz
действительно существуют. Тем не менее, стандартный загрузчик классов также будет использовать эти записи так же, как если бы существовала эта структура каталогов, поэтому нет проблем с тем, чтобы сохранить структуру каталогов в файле zip / jar.
Но начиная с Java 9, могут быть разные версии для одного и того же класса, которые будут выбраны в зависимости от текущей версии Java. Используемая для этого схема именования не является частью соглашения, используемого javac при хранении файлов.