середу, 13 серпня 2014 р.

Як показати діалог "зберегти" з допомогою JFileChooser

Як показати діалог "зберегти" з допомогою JFileChooser

Якщо вашій програмі потрібно зручно вказати положення файлу, папки або ж місцезбереження файлу, то для цих цілей Swing надає клас javax.swing.JFileChooser. Виклик діалогу збереження файлу схожого на той що використовується у віндовз, здійснюється через метод showSaveDialog():

  public int showSaveDialog(Component parent)

Де parent - це батьківський компонент діалогу, переважно JFrame. Коли користувач введе ім'я файлу і натисне ОК або Cancel, метод повертає одне з наступних значень:

   
   JFileChooser.CANCEL_OPTION // користувач відмінив вибір файлу
   JFileChooser.APPROVE_OPTION // користува здійснив вибір файлу
   FileChooser.ERROR_OPTION // якщо користувач закрив вікно
                            // кнопкою закриття Х.

Після того як користувач здійснив свій вибір, ми можемо використати метод getSelectedFile() щоб взяти нам об'єкт файлу:

    File getSelectedFile()

Перед викликом методу showSaveDialog(),  ви можливо захочете встановити деякі опції для діалогу:
  
    setDialogTitle(String) // встановлює заголовок вікна.
    setCurrentDirectory(File) // встановити директорію для збереження

Приклад коду:

// батьківський компонет діалогового вікна
JFrame parentFrame = new JFrame();
 
JFileChooser fileChooser = new JFileChooser();
fileChooser.setDialogTitle("Вкажіть як зберегти файл");   
 
int userSelection = fileChooser.showSaveDialog(parentFrame);
 
if (userSelection == JFileChooser.APPROVE_OPTION) {
    File fileToSave = fileChooser.getSelectedFile();
    System.out.println("Зберегти як: " + fileToSave.getAbsolutePath());
}

Можна встановити фільтр для задання розширень файлу:

 
FileNameExtensionFilter filter = 
                      new FileNameExtensionFilter("csv файл","csv");
fileChooser.setFileFilter(filter);

Вікно може виглядати так:


В результаті отримали об'єкт File і можна створювати потоки вводу-виводу і записувати у файл використовуючи отриманий об'єкт File. Об'єкт File, хто ще не знає є дискриптором файлу і мабуть, основне що в ньому є - це адрес розміщення файлу і його назва.

 При написанні було використано матеріали із codejava.net

пʼятницю, 25 липня 2014 р.

Заміщення (overriding) методів у Java


У відеоуроці розглядається наступне:
Що таке заміщення  методів? 
Чому заміщення і перевизначення це не одне й те саме? 
Дещо про успадкування та поліморфізм у Java.
Особливості статичних методів.
Модифікатор final при визначенні методів Java.


пʼятницю, 11 липня 2014 р.

WindowBuilder Error: Unhandled event loop exception

Вирішив поставити плагін WindowBuilder у Eclipse. При спробі використовувати графічний редактор зразу ж Eclipse почав видавати помилку: Unhandled event loop exception


Думав, знов щось нахомутав при встановленні. Проте завдяки посту:  "Eclipse Bug: Unhandled event loop exception No more handles", довідався що у цьому можуть бути винні деякі процеси запущені у windows. Методом проб і помилок як і у випадку описаному у моєму пості "JVM creation failed" виявилося, що знов винен електронний словник Abby Lingvo. Ну не люблять чомусь Java IDE цю програмку :)  і взагалі продукти фірми ABBY :).

Проблема вирішується або вбивством процесу  LvAgent.exe або ж у налаштуваннях лінгво забрати галочки пов'язані з роботою з клавіатурою, щоб взагалі не було реагувань на клавіші.

вівторок, 10 червня 2014 р.

Логування в Java (log4j 2)

Мабуть чи не всі програмісти виводять додаткову інформацію на консоль для зневадження програми і просто з метою стеження за її виконанням.  Проміжну інформацію про стан виконання програми, про певні критичні помилки часто корисно записувати у файл чи передати по мережі. Тоді користувач програми може надіслати розробнику звіт і розробник зможе розібратися, що ж пішло не так. Логування у будь-якому разі корисне. Логування у файл можна звичайно зробити самому. Проте навіщо винаходити велосипед, якщо на цьому поприщі вже багато чого зроблено. Існує декілька бібліотек, які спрощують логування. Зараз мова піде про log4j 2-ї версії.

Що потрібно звантажити

* Apache Log4j 2 з оф. сайту (http://logging.apache.org/log4j/2.x/download.html)
* Log4j 2 User’s Guide – посібник користувача (http://logging.apache.org/log4j/2.x/log4j-users-guide.pdf)
* SLF4J – це бібліотека для логування на якій базується log4j 2 (http://www.slf4j.org/download.html)


Підключення бібліотек


Для того щоб наші приклади працювали. Необхідно підключити відповідні *.jar файли до проекту. Не буду пояснювати як це робити.

Розархівовуємо вміст архівів звантажених з інтернету і з них я підключав наступні:

log4j2.0\log4j-api-2.0-rc1.jar
log4j2.0\log4j-core-2.0-rc1.jar
log4j2.0\log4j-slf4j-impl-2.0-rc1.jar
slf4j-1.7.7\integration\lib\slf4j-api-2.0.99.jar
slf4j-1.7.7\integration\lib\slf4j-simple-1.6.99.jar

Якщо не підключити slf4j, то буде видавати помилку виду:

 Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/ILoggerFactory
      at java.lang.ClassLoader.defineClass1(Native Method)...........



Конфігурація Log4j 2

Для того щоб логування працювало як нам потрібно необхідний відповідний файл конфігурації. Можна створити .xml файл, а можна файл properties. Приклади файлів конфігурації можна знайти в посібнику (User’s Guid). Файл повинен бути прописаний в classpath проекту. Можна просто закинути файл у корінь проекту, або у каталог src. Файл конфігурації краще назвати log4j2.xml.

У посібнику користувача можна знайти різні приклади файлу конфігурації для різних цілей: виводу лише на консоль, виводу у файл, виводу у мережевий сокет і т.д. Для виводу у файл матимемо:

<configuration>
    <appenders>
        <file append="false" filename="A1.log" name="A1">
            <patternlayout pattern="%t %-5p %c{6} - %m%n">
        </patternlayout></file>
        <console name="STDOUT" target="SYSTEM_OUT">
            <patternlayout pattern="%d %-5p [%t] %C{6} %M (%F:%L) - %m%n">
        </patternlayout></console>
    </appenders>
    <loggers>
        <logger level="debug" name="org.apache.log4j.xml">
            <appenderref ref="A1">
        </appenderref></logger>
        <root level="debug">
            <appenderref ref="STDOUT">
        </appenderref></root>
    </loggers>
</configuration>

Наступний приклад демонструє роботу з логуванням.
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class HelloWorld {
 private static Logger logger = LogManager.getLogger("HelloWorld");

 public static void main(String[] args) {
  logger.info("Hello, world");
  
  Logger fileLog=LogManager.getLogger("org.apache.log4j.xml");
  fileLog.debug("Write in file!");
 }
}

В результаті, якщо був використатий файл конфігурації наведений вище, то на консолі отримаємо:
2014-06-10 15:04:31,610 INFO  [main] HelloWorld (HelloWorld.java:8) - Hello, world
2014-06-10 15:04:31,612 DEBUG [main] HelloWorld (HelloWorld.java:11) - Write in file!
А у файлі:
main DEBUG log4j.xml - Write in file!
Спочатку отримуємо наш основний «Логер», який направлений буде на консоль.

private static Logger logger = LogManager.getLogger("HelloWorld");

Якщо ми хочемо писати у файл щось, то отримуємо логер для файлу:

Logger fileLog=LogManager.getLogger("org.apache.log4j.xml");

І пишемо у файл:

fileLog.debug("Write in file!");

Те як виглядатими наш лог, що туди включатиметься в значній мірі залежить від файла конфігурації.


Можливі передачі у лог і винятків (Exception):

logger.info("Error: ", new Exception("An exception"));


Рівні логування

Не хочеться вдаватися глибоко у цю тему, але необхідно згадати основне. При логуванні розрізняють рівні логування:

1.    TRACE – повідомлення найвищого рівні

2.    DEBUG – зневаджувальні повідомлення, менш детальні ніж TRACE

3.    INFO – стандартні інформаційні повідомлення

4.    WARN – некритичні помилки

5.    ERROR – помилки, що можуть вплинути на правильність результату

6.    FATAL – фатальні помилки, які заважають роботі

За допомогою файлу конфігурації ми можемо вказати, які повідомлення включати у наш лог.  У нас у файлі конфігурації маємо level="debug" . Це означає що на консоль і у файл буде виводитися всі повідомлення рівня Debug і нижче. Повідомлення рівні trace не будуть включатися. Тобто рядок в коді logger.trace("Hello, world"); - нам нічого не виведе ні в лог, ні у файл, ні на консоль, якщо ми не підвищемо рівень логування до TRACE у файлі конфігурації.

Патерни логування

Для формування вигляду логу, використовується відповідний патерн або ж шаблон. У нас використано два патерни, один для файлу інший для консолі.

<PatternLayout pattern="%t %-5p %c{2} - %m%n" />

<PatternLayout pattern="%d %-5p [%t] %C{2} (%F:%L) - %m%n" />

%d – вивести дату

%t – ім’я нитки (thread)

%-5p — виводить рівень логу (ERROR, DEBUG, INFO …), цифра 5 означає, що для виводу використовується 5 символів ,  (-), те що вирівнювання буде відбуватися по лівій стороні

%c{1} — виводить назву логера, у фігурних дужках регулюється наскільки повною видаватиметься назва

%L —номер рядка, в якій відбувася виклик запису у лог

%m — повідомлення, що було передано в лог

%n — перехід на новий рядок

Усе це детальніше подато у посібнику користувача.

понеділок, 23 грудня 2013 р.

Мічіо Кайку – Фізика майбутнього

Почав читати Мічіо Кайку "Фізика майбутнього". На книгу натрапив в книгарні Є. Дещо вагався
потрібна вона мені чи ні. На полиці і так лежить недочитані "Тиранія ринку" та "Теорія Брехні". Проте все ж придбав і не пожалів.

Попри страшне слово "фізика" у назві, книга не містить жодної формули і написана в доступній формі для широкого загалу. Написано про те як може помінятися світ в найближчі 100 років. Раджу читати всім, особливо науковцям і програмістам:). Кайку сам фізик і пишучи книгу він не видумував майбутнє у стилі фантастів, а спирався на уже існуючі прототипи певних технологій. В книзі ви знайдете чимало згадок про них. При написанні Він радився з науковцями, що займалися тими речами про що він писав. І це відрізняє книгу від недолугих опусів журналістів та різних любителів пописати про майбутнє.І найголовніше не обов'язково її читати із самого початку, можна починати читати з будь-якої сторінки.

Я ще недочитав її, але хочеться вже її похвалити і навести дещо з того, що прогнозує автор.

Чіпи у всьому. До 2020 року чіпи максимально здешевляться (десь до 1 цента) і їх будуть вставляти у все що тільки можна: окуляри, стіни, крісла, одяг і навіть тіло. 

Інтернет-повсюди. Усі речі і навіть тіла(з медичною метою) матимуть підключення до глобальної мережі.

Зручне медичне домашнє діагностичне і лікувальне обладнання. Усе що потрібно для діагностики хвороби і її лікування можна буде отримувати дома (переносні персональні томографи). З лікарем спілкування відбуватиметься віртуально. І навіть лікаря в більшості випадків зможуть заміняти автоматичні програми.

Віртуальна реальність прогресуватиме в сторону збільшення реалістичності, відбуватиметься повне занурення не тільки оптичне, а й тактильне. Автор згадує уже існуючі дослідні симулятори військових в США для навчання піхотинців та пілотів.

Екрани-шпалери. Це мені найбільше сподобалося. Замість шпалер можна буде клеїти екрани і створювати будь-яке зображення на стінах, навіть рухоме. Уже зараз є прототипи плівчастих екратів, в майбутньому екранами будуть стіни, вікна, двері, стеля.


Читання-думок. Керування розумними речами можна буде здійснювати навіть не словесно, а подумки.

Лінзи - екрани. Уже зараз ведуться розробки над окулярами та лінзами, які можуть слугувати для перегляду зображень. В результаті в комплексі з іншими засобами і поширенням інтернету вчителям в школам та викладачам прийдеться змінювати підходи до перевірки знань учнів та студентів. Їм прийдеться зосередитися на перевірці умінь думати та аргументувати. Учні запросто зможуть отримувати усе з інтернету непомітно від викладача/вчителя, безпосередньо під час контрольної, екзамену чи навіть під час спілкування з ним.

Люди-боги: До 2100 року завдяки тим же чіпам і безпровідному зв'язку та іншим технологіям, люди зможуть вести спосіб життя, що нагадуватиме життя богів на олімпі.

Можлива деградація. Кайку також піднімає цікаве питання, що буде коли замість купляти речі, люди створюватимуть усе потрібне у себе вдома за допомогою нових технологій, які оточуватимуть їх скрізь.  Людям не потрібно буде надто старатись для отримання певних речей і навіть гроші скоріш за все втратять сенс. Чи не деградує людство із зникненням мотивації до діяльності. На це питання так відповіді і не дано

Тож як я вже казав раджу читати всім. Цікаве, якісне і корисне чтиво. Я би  цю книгу ввів в шкільну програму.

Мічіо Кайку "Фізика майбутнього"

Сумна історія нашої мікроелектроніки

Натрапив на статтю в журналі "Економіст" за 1997 рік  "Наша електроніка була гіганською" авторства Августімова В. Л. Автор очолював цілий ряд підприємств пов'язаних з мікроелектронікою за часів СРСР і на початку незалежності, тож його думці можна довіряти.  Власне весь випуск журналу було присвячено сумному стану мікроеклектроніки в 1997 році, коли вона ще в нас хоч якось існувала. Стаття в черговий раз переконала мене в недосконалості планової економіки СССР і тому як у нас не вміють мислити на перспективу.

Власне це підтверджує не тільки дана стаття, але й книги по історії комп'ютерної техніки в Україні і в Союзі загалом. Зокрема свого часу я читав декілька книг присвячених В.М. Глушкову, людині, що після від'їзду Лєбєдєва з Києва, очолила нашу українську кібернетику і по суті за його керівництва в Києві була створена потужна комп'ютерна галузь. У нас створювались власні, оригінальні комп'ютери і усе що з ними було пов'язано. В 70-х роках поки комп'ютери в світі розвивалися відносно повільно  ми успішно конкурували із західними взірцями комп'ютерної техніки. Проте уже на початку 80-х ми почали відставати. СРСР повністю перейшов на копіювання американських комп'ютерів.  Закордонні новинки детально вивчалися і створювалися власні копії. Звичайно, що на це був потрібен час і ми постійно ішли по заду. Копіюванням займалися наукові установи Києва, Москви та Мінська.

Власне аналогічна ситуація склалась і в мікроелектроніці. Проте проблема полягала не лише в необхідності певного часу на копіювання того що зроблено на заході. Проблема була і у виробництві нової техніки, що була не передбачена держ. планами. Без дозволу на виробництво нічого нового не виготовлялося серійно, хоча певна річ могло давно бути розроблена в якомось науково-дослідному інституті чи конструкторському бюро і могла бути кращою за іноземні взірці.

У вищезгаданій журнальній статті наводиться такий приклад "...мікрохвильових печей не було, тому що не було поставлено такого завдання, а коли це втямили наші керівники, союз вже почав розпадатись". Ці слова показують увесь стан справ в цілому. Нормальний розвиток науки і високих технологій можливий лише в конкурентних ринкових умовах. Власне Китай тому і перейшов на капіталізм, оскільки їхні керівники добре зрозуміли до чого усе йде, та й торгівля у них в крові давно. До цього Китай пережив усе те що і ми в союзі і воєнний комунізм і голодомор за його загинуло до 35 мільйонів людей і всі інші переваги комуністичного життя.  В СРСР же усі спроби реформування провалювались, ну не хотіло наше комуністичне керівництво випускати хоч трішечки влади із своїх рух, усе хотіли контролювати і рахувати, хоча радянські економісти постійно втовкмачували про необхідність змін в цьому плані. Навіть коли у 80-х дозволили дрібне підприємництво, воно залишалось обкладене величезними податками і під тотальним контролем усіх можливих органів, навіть КДБ.

На жаль, і теперішня влада абсолютно не розуміє, що підприємців потрібно стимулювати, а не давити. Щодо галузі мікроелектроніки в незалежній Україні, то її намагалися якось реформувати від початку 90-х, проте як завжди робилося усе через велике Ж.. Підприємства потребували податкових пільг і серйозних поступків в плані зменшення митних обмежень на ввезення імпортних мікроелектронних елементів, проте цього не робилося. Боялися що надходження в бюджет впадуть і що розваляться і так давно відсталі заводи по виготовлення своєї елементної бази. В разультаті останні і так відмерли, із біля 2-х сотень потужних заводів, практично нічого не залишилося. На плаву залишилися одиниці, які займаються дрібними розробками під заказ або ж які субсидуються державою, існують ще тех.відділи при деяких підприємствах, які переважно займаються поточними ремонтами, а не створенням чогось нового.

Нормальних справді сучасних високотехнологічних заводів у нас просто уже не існує, а щоб створилися нові потрібно або ж вкладення шалених грошей або ж серйозні стимули для інвесторів. Мікроелектроніка не може жити без хорошого підходу, це не ІТ-галузь  де крім кількох комп'ютерів, інтернету і хороших програмістів більше нічого майже не потрібно і куди державі із своїми обмеженнями і правилами доволі важко втиснутися. Мікроелектронна галузь - це передусім енергоємке, матеріалоємне виробництво і яке дуже залежне від податкової та митної політики держави. Для цієї галузі потрібна  продумана політика побудована на досвіді Південної Кореї, Сінгапуру, Японії, Німеччини і того ж Китаю як розвинути власну високотехнологічну базу практично з нічого. Проте для цього потрібна влада яка б дбали про державу, а не про власні кишені....


P.S. Хоча початково не думав зачіпати цю тему,  але зараз рішив ще дописати про ЄС. Зараз нас лякають що при в ступі в ЄС наші підприємства будуть неконкурентні і відімруть, проте навіть і без вступу в ЄС вони років через 10 також відімруть. Весь світ рухається вперед в технологічному плані і якщо ми швидко не обновимо застаріле обладнання цих заводів і не створимо нові високотехнологічні, то перспективи в нашої економіки невеселі...