WebClub - Всероссийский Клуб Веб-разработчиков
WebClub.RU » Архив » Почему я получаю это сообщение, если использую JDK 1.1 под X Windows?

Почему я получаю это сообщение, если использую JDK 1.1 под X Windows?


Дата публикации: 17-03-2013

java.lang.NullPointerException
at sun.awt.motif.MFramePeer.(MFramePeer.java:59)
at sun.awt.motif.MToolkit.createFrame(MToolkit.java:153)
at java.awt.Frame.addNotify(Frame.java)
at java.awt.Window.pack(Window.java)


В вашей системе отсутствует шрифт. Переименуйте font.properties из подкаталога "lib" в font.properties.bak. Тогда JDK не будет искать несуществующий шрифт.

Эта проблема возникает, поскольку библиотеки Motif AWT используют шрифт "plain Dialog 12 point" в качестве шрифта по умолчанию. К несчастью, если используется удаленный X сервер, это шрифт иногда недоступен.

Для X терминала диагностические сообщения могут слегка отличаться:

% appletviewer HelloWorldApplet.html
SIGSEGV 11* segmentation violation
si_signo [11]: SIGSEGV 11* segmentation violation
si_errno [0]: Error 0
si_code [1]: SEGV_ACCERR [addr: 0x14]
Для того, чтобы определить, какие шрифты имеются у вас в наличии, используйте команду вида:

xlsfonts > ~/fonts.txt
Затем пройдитесь по длинному списку шрифтов и выберите те, которые хотите использовать. Программа xfd демонстрирует выбранный шрифт:

xfd -fn "имя вашего шрифта" &

Почему GridBagLayout так сложно использовать?

Для этого есть две причины. Во-первых, хотя небольшие упаковки довольно просты, детализированная упаковка для GUI очень сложна. Во-вторых, при разработке GridBagLayout человеческий фактор и простота использования не были основной целью. Если это вас раздражает (меня это раздражает), не используйте GridBagLayout. Разместите свой GUI на нескольких панелях и используйте для каждой из них свой менеджер упаковки, чтобы достичь нужного вам эффекта. Официальное объяснение, данное руководителем проекта AWT участникам Mountain View Java Users Group 4 декабря 1996, звучит так:

"Так случилось, и это уже принято к сведению, что GridBagLayout слишком сложен для того, чтобы выполнять возложенные на него функции. GBL будет по-прежнему поддерживаться, но также будет вскоре выпущен улучшенный и упрощенный вариант. Этот 'улучшенный GBL' может быть использован вместо GBL."

Итог: не нужно тратить усилий на GBL, на данный момент существуют более простые альтернативы. К тому же, GBL является причиной утечки памяти. GBL вставляет "добавленные" компоненты в хэш-таблицу, но removeLayoutComponent() их никогда не удаляет. См. ошибку номер 4195295.

Трудно пройти мимо документации по GBL. Основываясь на очевидном сходстве, ее можно взять из grid layout manager из Tk (Tcl/Tk). Если вам не нравятся вложенные панели и ни один из других менеджеров упаковки не делает того, что вам нужно (или вы работаете с унаследованным кодом, который уже его использует), документация из Tk может вам пригодиться.


MyClass работает отлично, за исключением случая, когда я хочу установить другой шрифт. Я не могу заставить это работать под Win95, но то же самое работает под MacOS и Unix.

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

Для Windows 95 и Solaris 2.6 эти шрифты

Dialog
SansSerif
Serif
Monospaced
Helvetica
TimesRoman
Courier
DialogInput
ZapfDingbats
обнаружены следующей программой:
import java.awt.*;

class foonly {
static public void main(String s[])
{
String n[]= new Frame().getToolkit().getFontList();
for (int i=0;i System.out.println(n[i]);

System.exit(0);
}
}
Другими словами, вы можете получить массив типа String имен шрифтов, используя:

String[] fonts = Toolkit.getDefaultToolkit().getFontList()
Вместо настоящих имен шрифтов, таких как Helvetica, TimesRoman, и Courier в JDK 1.1 было отдано предпочтение стилям, таким, как SansSerif, Serif, и Monospaced (соответственно). Стиль шрифта будет отображаться в наиболее подходящий шрифт для данной платформы.

В настоящий момент для отображения стилей в имена системных шрифтов используются записи в одном из файлов font.properties в $JAVAHOME/lib. Имеется несколько файлов font.properties, соответствующих разным локализациям. Если вам нужно быстро протестировать новый шрифт, вы можете изменить файл или дополнить его так, что отображение будет производиться в тот шрифт, который вы хотите проверить.


Я создал Lightweight-компоненту (компоненту, непосредственно расширяющую класс Component), но она мерцает/не перерисовывается как следует. Почему?

Lightweight-компоненты, поскольку они считаются "прозрачными", не перерисовываются непосредственно в ответ на repaint(). Фактически Component.repaint() просматривает стек компонент снизу вверх, находит "непрозрачную" Heavyweight-компоненту (она должна быть контейнером), и затем вызывает ее метод repaint().

Из этой точки управление в итоге передается методу Container.update(). Первое, что он делает - вызывает super.update, приводя нас к Component.update(), который очищает компоненту цветом фона, поскольку он был вызван для heavyweight-компоненты, и завершается. Затем Container.update() вызывает update рекурсивно для всех Lightweight-компонент, которые этот контейнер содержит.

Итог: "прозрачность" lightweight-компонент будет работать правильно (без мерцания) если первая доступная выше по иерархии включения heavyweight-компонента является:

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

Другой важный момент состоит в том, что если ваш контейнер определяет собственный метод paint(), то он обязан вызывать super.update/paint(), иначе содержащиеся в нем lightweight-компоненты никогда не будут перерисованы. Собрав это воедино, мы видим, что в данном случае для нормальной работы нужно внесение минимальных изменений в код - поместить метод:

public void update(Graphics g) {
super.paint(g);
}
В ближайший в иерархии компонент heavyweight-контейнер, содержащий lightweight-компоненты, которые ничего не выводят в тех областях, которые уже были прорисованы их родителями, т.е. "непрозрачные" компоненты. Грязно, но быстро.

Если вы хотите нормально работать с прозрачными компонентами, описанный выше метод заменяется на:

public void update(Graphics g) {
// стандартное создание внеэкранного контекста.
offg.fillRect(нужный цвет фона, полный размер);
super.paint(offg);
g.drawImage(myimage, 0, 0, null);
}

public void paint(Graphics g) {
// на случай изменения размера может вначале вызывать update().
super.paint(offg);
g.drawImage(myimage, 0, 0, null);
}
Их можно объединить, если заставить this.update() вызывать this.paint(), с подстановкой различных значений параметров, но проще всего перекрыть их по отдельности, как в примере.


Возможно ли из Java размещать и получать обратно "куки" (cookies) способом совместимым со всеми браузерами, поддерживающими "куки" (cookies)?

Краткий ответ: нет. Расширенный ответ: вероятно нет. Окончательный ответ: "Куки" (Сookie) это незначительный обьем данных, которые сервер посылает обратно клиенту, и может восстановить по требованию. Это позволяет серверу сохранять некоторую статическую информацию об каждом из своих клиентов. Информация обычно что-то типа - "какие страницы посещались пользователем?" или "это привилегированный пользователь?". Раздел DevEdge на домашней странице Netscape's содержит javascript-Java пример получения cookies. Так же следующая ссылка http://www.geocities.com/SiliconValley/Vista/1337 содержит информацию о связывании апплета с функциями javascript. Так как это довольно запутанно, используйте только Java если это возможно.


Я разработал апплет и протестировал его под Netscape Navigator, и обнаружил что после перекомпиляции, даже если я нажимаю reload, очищаю кэш, повторно ввожу URL документа я все равно получаю старую версию апплета. Почему?

Примечание: читатели информируют о том, что в Netscape Communicator 4.05 возможно принудительно перегрузить апплет удерживая "control"+"shift" и "кликая" на "Reload" В прошлом Netscape не сумели полностью исправить дефектный код, который выполняет такие абсурдные вещи. Это повторялось во многих удачных релизах. Очистка сетевого кэша не влияет; не имеет значения где происходит кэширование. Хотя апплеты иногда удаляются ("pruned") и происходит уборка "мусора", этот процесс не предсказуем, поэтому перезапуск Netscape единственно надежная вещь в настоящее время. Связанный вопрос "как сделать перезагрузку окна браузера из URLConnection вместо получения содержания из локального кэша?" Ответ: используйте

java.net.URLConnection.setUseCaches(false)
Окно браузера изменяется в соответствии с этим программным требованием. Кеширование в Netscap-e варьируется в зависимости от того используется ли proxy сервер, и какой поток в апплете выполняет запрос.

Другой подход состоит в добавлении "?" к URL, тоесть

http://www.somesite.com/webcam/image.jpg?100
и увеличении этого число каждый раз когда апплет вызывает изображение.


Почему Netscape не обновляет апплет когда Вы нажимаете кнопку Reload ?

Для перезагружаемого апплета, новая версия должна была бы быть загружена в другом ClassLoader-е. Стратегия Navigator/Communicator's для связывания апплета с ClassLoader-ом не принимает во внимание была ли выполнена перезагрузка. (хотя нет никаких технических причин что бы этого не делать).
Hекоторые версии Netscape обновляют апплет если очистить кэш используя пункты меню Edit/Preferences/Advanced/Cache to Clear Memory Cache and Clear Disk Cache, а затем удерживая нажать reload. В Explorer, используйте View/Options/General/Delete Files для очистки кэша, затем 'Reload' для обновления страницы содержащей апплет.

До тех пор пока это не исправят, используйте appletviewer для тестирования апплетов. И пишите письма - разработчики могут исправить только те "баги" о которых знают.


Что предпочтительнее использовать файлы Microsoft CAB или Java JAR?

Вопрос риторический. Формат файлов CAB собственность Microsoft. Hе используйте его так как он разрушает переносимость программ.
Файловый формат JAR стандартный формат Java, основанный на формате PKZIP с компрессией данных, был введен в JDK 1.1.
Ссылка http://www.ibm.com/java/community/viewarchive4.html содержит дополнительную информацию.
Вам стоит использовать стандартный формат Java - JAR (Файл архива Java), как файловый формат не связанный с определенным поставщиком, так как JAR не только стандартный формат Java, но и промышленный стандарт разновидности PKZIP. Один из читателей замечает что оба формата могут быть использованы, как например в следующем коде:




IE3 не поддерживает JAR. IE4 поддерживает сжатый и не сжатый формат JAR, но не подписанный JAR.


Как я могу узнать версию Java поддерживаемую моим браузером?

Смотри ссылку http://java.rrzn.uni-hannover.de/insel/beispiele/vertest.html. Эта ссылка сообщает поддерживает ли Ваш браузер JDK 1.1.

Ссылка http://www.uni-kassel.de/~pfuetz/Properties.html сообщает какие классы можно надеяться будут присутствовать в выполняющей системе браузера.


Почему Visual J++ - плохой выбор?

Потому что главная цель Microsoft - "уничтожение кросс-платформенной Java".

Обеспечение пользователю возможности легкого переноса программ на другие платформы противоречит финансовым интересам Microsoft. MS - единственная компания в компьютерной промышленности, которая активно пытается подорвать Java. Это не предположение - Департамент Юстиции на одном из судебных разбирательств с Microsoft, упоминая компанию, назвал ее стратегической целью - "уничтожение кросс-платформенной Java посредством заражения Java-рынка". Загляните на http://www.usdoj.gov/atr/cases/f1700/1762.htm VJ++ может использоваться как Java-совместимый продукт, но с предлагаемыми по умолчанию установками, это невозможно.

Против Microsoft было возбуждено дело из-за несанкционированных изменений, сделанных в Java. Федеральный судья в марте 1998 г. дал компании предписание, запрещающее использование этикеток, выдающих J++ за Java. Другое предписание, в котором требовалось устранение преднамеренной несовместимости с Java, было дано Microsoft в ноябре 1998 г.(напомним, что Microsoft не создавала Java, а всего лишь получила от Sun право на ее распространение).

Спросите у Вашего начальства как комфортно оно себя чувствует, используя продукты от Microsoft в то время как компания втягивается в юридический конфликт из-за преднамеренно созданных несовместимостей в ПО. Спросите как оно себя чувствует, когда доказано, что Microsoft хочет ограничить пользователя рамками одной ОС. Все это сказано для того, чтобы защитить Вас от неправильного выбора. Вы можете ссылаться на эти факты, внедряя Java в Вашей компании.

Как Java-программист, присоединитесь пожалуйста к Java Lobby - независимой организации, представляющей некоммерческие интересы Java. Это вы можете сделать бесплатно. Вы можете посетить http://www.javalobby.org для уточнения деталей. Есть другие пути, способствующие распространению Java:

Можно использовать средства разработки других поставщиков. Можно конвертировать MS J++ для работы с Sun'овским JDK. За инструкциями можно обратиться на http://www.orbiter.demon.co.uk/
Можно использовать Netscape Communicator (не Internet Explorer)
Если без Internet Explorer не обойтись, используйте Java-плугины.
Используйте стандартный GNU JVM, Kaffe, другие IDE (от Sun, например. Hо ни в коем случае не Microsoft J++ SDK)
Бесплатные Java-компиляторы и плугины можно взять на http://java.sun.com.
Бесплатные виртуальные Java-машины можно скачать здесь: http://www.kaffe.org, http://www.oryxsoft.com/projects/gvm,
и http://www.redhat.com/linux-info/jolt
Бесплатный Java AWT софт можно найти на http://www.biss-net.com/biss-awt.html а также можно взять все необходимое на ftp.java-linux.org (linux'овский сайт).
Бесплатный Java-софт лежит здесь: http://www.gnu.org/software/java/java.html
Кстати, в мае 1998 г. Microsoft отрицала свою вину, настаивая на том, что она создала новый, усовершенствованный проект. Это не соответствует действительности. Microsoft фактически обвиняют в

действиях, направленных против конкурентов, производящих броузеры. Таким образом защищается монополия Microsoft на рынке настольных операционных систем.
использовании монополии для навязывания производителям PC ограничивающих соглашений, требующих поставку Microsoft броузера вместе с Windows. Это также препятствует продвижению на рынок конкурентноспособных броузеров.
Многие люди не понимают политики, взятой на вооружение компанией Microsoft. Зачастую условия, которые ставит Microsoft в соглашениях, очень неразумны, а порой и абсолютно неприемлемы. Вот почему MS сталкивается с проблемой нелегального использования своих продуктов в США, Италии, Бразилии и европейских странах.
Домен продается

Популярное

Не так давно в сети появился новый сервис, под названием Dead Man Zero. Этот сервис сделал...
Рынок социальных площадок уже давно стал стабильным. Несмотря на то, что время от времени...
Artisteer 4 – единственный в своем роде продукт, позволяющий автоматизировать работу над созданием...
Октябрь 2018 (14)
Февраль 2017 (3)
Январь 2017 (1)
Август 2016 (1)
Май 2016 (2)
Ноябрь 2015 (1)

Карта сайта: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41

Друзья сайта



Случайная цитата

Неизвестный автор:

"Ссылка – текст, да в ней намёк."

Опрос

Ваша техника?

Настольный компютер
Ноутбук
Смартфон
iPad
iPhone
другое