Получил ответ , который может не сработать для вас, так как кажется, что он скорее зависит от многих вещей и обстоятельств, НО Я подозреваю, что он действительно актуален для большинства людей здесь.
Устранение неполадок
(Пропустите, если вам все равно, как я понял это для своих настроек, но это может помочь вам. Решение 1 - это то, что вам нужно, если вы нетерпеливы .)
Как это началось ...
Текущий рабочий каталог активно развивающегося проекта начал выкладывать логи, показывающие это поведение сегодня, когда некоторое время не было ошибок. Я использовал Windows 7, Maven 3.0.4, плагин компилятора 2.4 и java (c) 1.6.0_31.
При достижении определенного подмодуля maven мог бы выплевывать некоторые сообщения об ошибках и отказывать в сборке, за исключением сообщений об ошибках, не связанных (сообщающих об использовании проприетарных com.sun.* API), и не было бы никаких признаков фактической ошибки компиляции .
Все становится странно ...
На данный момент я нахожу этот поток, и я также пытаюсь пересобрать с различными версиями Java и версиями Maven-compiler-plugin. Вот забавная часть:
- с компилятором-плагином 2.5, я получаю похожую проблему и нет действительного сообщения об ошибке;
- с плагином компилятора 2.3, я получил бы аналогичную проблему с бессмысленным сообщением об ошибке с жалобой на отсутствующий пакет (который присутствует и в classpath, хотя!) ;
- с плагином компилятора 2.3.2, я получил бы аналогичную проблему с бессмысленным сообщением об ошибке с жалобой на отсутствующий пакет (который присутствует и в classpath, хотя!) НО ** в другой точке ** при компиляции тестовых классов модуля (ранее это происходило при компиляции обычных классов).
От странного до странного
Становясь подозрительным, я переключился на другой каталог с чистой проверкой проекта и пересобрал все.
Все работало FINE . Озадаченность и отчаяние здесь.
Итак, я понял, что я работал над довольно огромным и сложным классом в другом рабочем пространстве в неисправном модуле. И я имею в виду довольно большой, сложный и довольно плохо написано. Тип зверя, который заставляет вас говорить своему боссу: «Пожалуйста, не заставляйте меня трогать это», и это заставляет ваш ключ DELETE щекотать вас каждый раз, когда вы сталкиваетесь с неудачей, наткнувшись на него в вашей IDE. На самом деле, эта штука настолько похожа на детище мрачного маргинального эксперимента и странно неэтичного биоисследования, что вы задаетесь вопросом, не произошло ли это прямо из RTC Wolfenstein или Doom, если антагонисты были кусочками кода. Класс, который вы не хотите оставлять в покое для написания кода ночью, и для которого Sonar тихо сообщает о почти 1000 нарушениях качества кода, включая индексы сложности, которые заставляют задуматься, не имеют ли PMD, JDepend и другие инструменты на самом деле все удар одновременно).
Но я отвлекся ...
Я скопировал его в это чистое и, казалось бы, рабочее пространство (к счастью для меня, это не повлияло на другие файлы, поэтому сделать это было довольно просто: просто скопировать).
Затем я перестраиваюсь с Maven, и он снова начинает капризничать, когда снова достигает модуля, содержащего этот файл, за исключением того, что на этот раз он выводит load ошибок стека трассировки, которые никогда не заканчиваются. Поэтому я хочу попытаться перезапустить ту же сборку, на этот раз сохраняя результаты в файле журнала, чтобы рассмотреть их поближе и (вот новая странная вещь, потому что пока это было недостаточно странно) ... снова не показывает ошибки.
Итак, я полагаю, что что-то, очевидно, очень неприятно, что javac должен идти вразрез с тем, что выглядит как переполнение стека, и искать фрагмент трассировки стека, который я мог видеть в своем журнале в первый раз. Вот часть этого (как я подозреваю, некоторые могут столкнуться с этим и найти этот ответ полезным):
[ERROR] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
[ERROR] at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:377)
[ERROR] at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1241)
[ERROR] at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1210)
[ERROR] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
[ERROR] at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:1799)
[ERROR] at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1522)
[ERROR] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
[ERROR] at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:377)
[ERROR] at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1241)
[ERROR] at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1210)
[ERROR] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
[ERROR] at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:1799)
[ERROR] at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1522)
И Google приятно указывает мне на ... StackOverflow, конечно:)
Компиляция Maven: сбой при выполнении javac
Где я вижу простую попытку (см. Ниже).
Конечно, это было бы намного проще для устранения неполадок, если трассировка стека появилась во всех ситуациях и во всех случаях и показала очевидное исключение StackOverflowException.Особенно если учесть, что в противном случае я уже видел эту ошибку и знаю, что она означает, но чертовски трудно понять, когда вы ** не видите * ошибки.
Не уверен, почему Мейвен проглотил это, но, возможно, javac просто потерпел крах без уведомления, и в управлении журналом произошел сбой, и он не удаляется должным образом.
Это также объясняет, почему эта ошибкапроисходит относительно случайно: это будет зависеть от ваших настроек оборудования, и небольшие изменения в классах javac будут переданы процессу.
Итак, что теперь ???Что ж, если есть сумасшедшее исключение переполнения стека или OutOfMemoryException, когда java пытается обработать ваш код, очевидно, вам нужно сделать что-то похожее на объяснение ниже ...
Решения
Решение 1 (так называемое «кратковременное / быстро-грязное /« сделай сам »»)
Обновите настройки памяти.Самый простой способ - что-то с , например, (для оболочки, похожей на bash):
export MAVEN_OPTS="-Xss1024k -Xms512m -Xmx1024m"
BEWARE : эти настройки, очевидно, будут зависеть от аппаратного обеспечения вашей платформы (ина вашей оболочке).
В моем случае, я имел обыкновение иметь:
export MAVEN_OPTS="-Xss128k -Xms384m -Xmx384m"
... потому что у меня довольно тяжелый проект и рабочая станция с не такой большой памятью, поэтомуМне нужно сжать каждый бит ОЗУ, который у меня есть, чтобы было запущено несколько экземпляров Eclipse, несколько серверов приложений и т. Д. Итак, мои JAVA_OPTS, ANT_OPTS и MAVEN_OPTS установлены с кучей опций, включая эти.
Это не обязательно то, что вы хотите !! Значение xss по умолчанию для 64-битной JVM в Windows на самом деле составляет 1024, поэтому я использую что-то значительно меньшее.Я просто говорю это, поскольку это может помочь другим в той же ситуации.Попытайтесь поднять его соответствующим образом и разумно для вашей конфигурации.
Итак, в конце концов, чтобы исправить эту конкретную проблему в моем проекте, мне пришлось изменить вышеупомянутое значение на:
export MAVEN_OPTS="-Xss256k -Xms384m -Xmx384m"
И теперь все работает отлично.
Может быть, некоторые другие вещи для вас разные.Дайте мне знать.
Решение 2 (он же «долгосрочный / дзен»)
Вы знаете, что лучше, чем возиться с настройками памяти, которые выиграли другие »не знаете, как возиться и, возможно, не имеют шанса, и это делает ваши сборки менее переносимыми? [аудитория кричит здесь]
Вы преобразуете ад из этого безобразного класса , который заставляет javac плакать из-за своей мамы.
Это так просто.Нет тысяч и тысяч строк классов, с безумными статическими инициализаторами, супер длинными методами и тому подобным.Если ваш код выглядит сложным для вас, он, безусловно, подходит и для плохого javac.
Сохраните процесс javac сегодня: рефакторинг вашего кода !!