Alex XYZ

Гляньте формат "Office Open XML" + docx4j. -> вот к чему может привести xml. Так что несколькими днями не отделаетесь. Можно и через год удивляться "а чё, так можно было?"

Параметры, передаваемые через POST - это просто строка формата param1=value1&param2=value2, но передаваемая в теле запроса, а не в адресной строке. Вот хороший пример преобразования, где учтено экранирование: stackoverflow.com/questions/7671597/convert-map-to...

connection.setDoOutput(true);  // После этой строки писать всё остальное
StringBuilder sb = new StringBuilder();
  for(HashMap.Entry<String, String> e : queryString.entrySet()){
      if(sb.length() > 0){
          sb.append('&');
      }
      sb.append(URLEncoder.encode(e.getKey(), "UTF-8")).append('=').append(URLEncoder.encode(e.getValue(), "UTF-8"));
  }

// Теперь нужно эти данные передать в тело запроса:

        DataOutputStream wr = new DataOutputStream(connection.getOutputStream());
        wr.write(sb.toString().getBytes());
        wr.flush();
        wr.close();

Попробуйте перед lib поставить точку (текущий каталог), а то, наверное, java не очень понимает где же всё-таки находится lib (ну и *.jar убрать):

java -classpath application.jar;./lib;. org.company.application.Launcher

Есть ещё один "тонко-толстый" момент. При разработке Java web-app очень часто оказываешься в ситуации, когда из-за изменения даже одной запятой (пусть даже и в HTML-клиенте) приходится пересобирать весь проект, на что может уходить и как 2-3 минуты, так и полчаса. На php такой проблемы нет. В принципе это очень напрягает Java-разработчиков. Смотрел разные способы, но пока нашёл только один более-менее приемлемый JRebel, но он платный.

Не подойдёт обычный try/catch с сохранением сбойных запросов в отдельный список, а потом повторного их вызова?

Надо вступить в банду крутых JavaEE разработчиков. Потом научиться небрежно употреблять крутые слова "виртуальная машина Java", "объектный код", "да я могу собрать WAR из командной строки", и т.д. Потом одеть чёрное очки. И тут вы получаете приглашение от Голливуда. На предложение Oracle вы брезгливо отказываетесь (ну кто будет связываться с этим странным "предсказателем"? Хрень какая-то, кино не снимают). Вас задействуют в главной роли JavaEE разработчика в фильме типа "Координаты JavaEE" где вы успешно ломаете центральный сервер glassfish от Всемирной корпорации зла Oracle используя уязвимости протокола HTTPS. В конце в вас влюбляется голубоглазая блондинка и приглашает Вас в своё уютное гнездышко невинным вопросом - ты не покажешь, как удалённо деплоить приложение на tomcat? И уход в затемнение...
Ну почему программист должен быть крутым??? Это же не кино! Все очень просто (я, вы и пушка) - Вы, программа, компьютер. Бороться вам надо будет только с самим собой, а точнее со своим незнанием чего-то. И это проклятие профессии в IT. Вам всегда будет не хватать знаний. Здесь нет крутизны. Каждый день вы можете сталкиваться с нерешаемыми на первый взгляд задачами. Очень сложно не спасовать. И иногда будете сталкиваться с фундаментальными вопросами и находить для них необычные решения. И вот тогда вы сами скажете себе "Да я КРУТ".
На мой взгляд, программист - это немного учёный. Если вы не видели этого, советую посмотреть: Ричард Фейнман: удовольствие делать открытия.

Гляньте scriptomatic: https://www.microsoft.com/en-us/download/details.a...
Там много примеров как настроить watcher на разные события в системе. Google wmi file watcher

Ну вы поняли, в вопросах бэкенда и разработки серверов я пока плаваю

- Это вы точно подметили, только вы неправильно характеризуете свои ощущения. Мой тихий внутренний голос часто говорит мне, что нет ничего нового. Просто нужно уметь найти правильную точку зрения при которой всё становится понятным и процесс осмысления идёт как по маслу. Если всё идёт со скрипом, значит вы что-то не так поняли.

Что же касается JavaEE - это чистой воды фикция. Это просто спецификация:
Java Platform, Enterprise Edition, сокращенно Java EE (до версии 5.0 — Java 2 Enterprise Edition или J2EE) — набор спецификаций и соответствующей документации для языка Java, описывающей архитектуру серверной платформы для задач средних и крупных предприятий. И вы вольны даже при разработке EE-приложений не придерживаться её.

Может нужно было ограничиться Python или PHP?

- это вы сами решайте. Но JavaEE не делает чего-то особенного, чего вы не знаете. Просто представление о backend-е у вас срослось с Python и PHP. Разделять то, что приросло - очень трудно. Так что это больше работа над собой, чем изучении JavaEE.

Немного странно у вас сформулирован вопрос, но в принципе понятно. Давайте не 1/2.java (потому что имена классов должны совпадать с именами файлов, а в java классы не могут быть названы числами), а хотя бы First.java и Second.java
В Second.java пишите вначале

import First;

и далее по коду в Second.java пишете

x=First.var1

Это если var1 - статическая. Иначе вам сначала придётся инстанциировать объект First, а потом вызывать доступ к var1 от имени экземпляра.

Хотя лично мне кажется, что вы только что начали изучать java. Смотрите раздел "Области видимости", "Модульность", ваш вопрос оттуда.

Дам совет, но не скажу, что профи в java. За годы общения с этим языком я почти не встречал приложений типа desktop на java. А тем более таких, которые дико популярны (eclipse и всякие IDE не в счет). Вот backend - это его родная стихия, но там красот нет, нет цветного desktop и ничто, никакой цвет, кроме черного не нарушает мрачную темноту сервера в темном шкафу. Вот мне это нравится, но не все это понимают :) как вам? Программы там как рабы, даже баллон всплыть не может, чтобы привлечь мое внимание. Только логи...

Андроид веселее. Ну а по информации - не скидывайте свой предыдущий опыт, учеба - она одинакова и там и тут. Начинайте с того, что вам знакомо и поймете, что азы одинаковые.

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

Java это не только JavaEE. Попробуй вообще поработать с java в ручном режиме:
- руками собрать приложение, без IDE, "понюхать" манифесты. В java манифесты очень важны;
- запустить приложение без сборки jar-файла, погонять разные настройки jvm из командной строки;
- поработай с java в linux;
- изучай maven (ну или какую-либо другую систему сборки, но все будут требовать порога входа в тему), учись писать и интегрировать модули, потому что быстро программу можно написать только пользуясь результатами именно чужого труда, а этому ещё надо научиться;

и вообще привыкни к мысли, что учёба в работе занимает много времени. Не будет такого, что поднял, например, stream-ы и зашибись, пошла лафа и халява. Две темы вместе уже сами порождают третью и теперь уже три темы влияют друг на друга, а потом они растворяются друг в друге. В общем - весело.

Есть некоторая информация на эту тему. Я связался с человеком, поддерживающим сайт:

http://www.jhlabs.com/index.html

он ответил:

The problem is that Java doesn't actually use the source for these gradients but instead has a special optimised version (I think running on the GPU). It detects if the gradient is an instance of one of the built in gradients and then switches to this special code, so the code in the gradient classes is never actually run.

В вольном переводе:

Java не использует оригинальный код, представленный в исходниках, а вместо него имеет оптимизированную версию (которая, по-моему, выполняется на GPU). Java определяет, если градиент является «встроенным», то переключается на специальный код, поэтому код в его классах градиента на самом деле никогда не выполняется.

Я на это тоже обратил внимание, что дебаггер ещё останавливается на конструкторе LinearGradient, а вот на функции fillRaster уже не останавливается.

Маленький бонус (в инете очень мало пособий, объясняющих, как создавать градиентные заливки):

Пример градиента без наворотов:
asserttrue.blogspot.com/2010/01/how-to-iimplement-custom-paint-in-50.html
Пример конусного градиента (с кешированием, иначе вообще тупит):
www.jug-muenster.de/java2d-conical-gradient-paint-674/

Больше ничего не нашёл. Если кто найдёт — киньте ссылку, буду очень благодарен.

Мною замечено яркое применение нестандартной заливки в продукте Adobe Illustrator (сетчатый градиент). Шустро работает. Хороший пример сетчатого градиента:
Нос совы: www.digitalartsonline.co.uk/tutorials/?featureid=3221873&pn=2
Огонь спички (требуется авторизация): demiart.ru/forum/index.php?showtopic=172676

Линейная и радиальная градиентные заливки там тоже отличаются от стандартных заливок, но не сильно. Фотошоп в пример не привожу, потому что он использует свои заливки исключительно как растровые фильтры (кстати, в свете вышеизложенного становится понятно, почему они так долго отрисовываются).