LINUX.ORG.RU

Java 16 поломала поддержку LDAP в Spring Boot

 , , ,


0

1

Вот, не только Lombok пострадал. Всё пропало или скоро починят?

Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.springframework.ldap.core.support.LdapContextSource
	at org.springframework.boot.autoconfigure.ldap.embedded.EmbeddedLdapAutoConfiguration$EmbeddedLdapContextConfiguration.ldapContextSource(EmbeddedLdapAutoConfiguration.java:205) ~[spring-boot-autoconfigure-2.4.4.jar:2.4.4]
	at jdk.internal.reflect.GeneratedMethodAccessor431.invoke(Unknown Source) ~[na:na]
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
	at java.base/java.lang.reflect.Method.invoke(Method.java:567) ~[na:na]
	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) ~[spring-beans-5.3.5.jar:5.3.5]
	... 127 common frames omitted

UPDATE: нашёл источник проблемы.

Exception in thread "main" java.lang.IllegalAccessError: class org.springframework.ldap.core.support.AbstractContextSource (in unnamed module @0x108c4c35) cannot access class com.sun.jndi.ldap.LdapCtxFactory (in module java.naming) because module java.naming does not export com.sun.jndi.ldap to unnamed module @0x108c4c35
	at org.springframework.ldap.core.support.AbstractContextSource.<clinit>(AbstractContextSource.java:77)

Очень похоже на то, что случилось с Lombok, но уже в JNDI LDAP:

	private static final Class<com.sun.jndi.ldap.LdapCtxFactory> DEFAULT_CONTEXT_FACTORY
            = com.sun.jndi.ldap.LdapCtxFactory.class;

UPDATE #2: В spring-ldap-core это уже исправили, исправление должно войти в следующую версию 2.3.4-RELEASE

https://github.com/spring-projects/spring-ldap/commit/0a1d3f595b670412b7fd7ab739237c57381a7fa8#diff-1b415582238c28e1c42b5ab96d862e14d8917d4e3decf1cc43f84aa45e63e7ae https://github.com/spring-projects/spring-ldap/issues/543



Последнее исправление: hummer (всего исправлений: 5)

Просто не нужно пользоваться этим спринг бутом и ломбоком. Возьми и напиши XML-конфигурацию с геттерами и сеттерами. Совремённые программисты слишком ленивые.

Legioner ★★★★★
()

Всё пропало или скоро починят?

Не рассчитывал бы, они медленно движутся. Ту же джакарту последнюю не поддерживают и не собираются даже (так и сказали - только если в следующей мажорной версии). Обжегся, когда попытался подключить библиотеку, юзающую jaxb 3.0.0

Midael ★★★★★
()
Ответ на: комментарий от Legioner

Возьми и напиши XML-конфигурацию с геттерами и сеттерами. Совремённые программисты слишком ленивые.

Какое это имеет отношение к поддержке LDAP в Spring Boot? Lombok тут не обсуждается, а лишь приведёт в пример.

hummer
() автор топика
Ответ на: комментарий от rukez

JDK должна поддерживать совместимость вниз. Что там в этом org.springframework.ldap.core.support.LdapContextSource такого, что Java 16 бросает NoClassDefFoundError?

hummer
() автор топика
Ответ на: комментарий от Legioner

Ну у тебя в стектрейсе бутовские классы. Выкинь бут и попробуй ещё раз.

С каких пор Spring Boot стал чем-то плохим? И что ты предлагаешь использовать вместо него?

hummer
() автор топика
Ответ на: комментарий от hummer

С каких пор Spring Boot стал чем-то плохим?

С его первого релиза.

И что ты предлагаешь использовать вместо него?

Ничего не использовать вместо него. Он не нужен.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Можешь дать более развёрнутый ответ? Что именно не так со Spring Boot и как следовало бы проектировать те приложения, которые на нём простроены?

hummer
() автор топика
Ответ на: комментарий от hummer

Что там в этом

Куча рукопопых рефлекшенов но равном месте?
Подключи исходник да посмотри :-)

rukez ★★★★
()
Ответ на: комментарий от hummer

Для чего нужен Spring Boot? Для того, чтобы ты не конфигурировал Spring. Как работает Spring Boot? Через магию, которая не всегда стабильна. Ему даже плагины для maven/gradle свои нужны. То бишь это очень сложная и хитрая система. И всё для того, чтобы не ты писал несколько десятков (ну ладно, в огромных проектах несколько сотен) строк конфигурации Spring-а.

Никак особо их проектировать не нужно. Просто выкидываешь Boot и конфигурируешь Spring как тебе больше нравится. Мне больше нравится XML, но можно проектировать и через Java-код с аннотациями. С Java там тоже магии хватает, но её вроде поменьше. Ничего сложного в этом нет, в Spring Reference всё написано, чего как конфигурировать.

Ну или едешь с Boot-ом, но тогда не жалуйся, что магия порой магически не работает.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 3)
Ответ на: комментарий от hummer

Это не что там такого в Бут, а чего теперь нет в ждк, смотри ченжлоги того чего повыбрасывали и делай выводы, ну и не плохо было бы сказать что вместо 16 было ранее

anonymous
()
Ответ на: комментарий от Legioner

Вообще, у меня вызывает сильные сомнения «новый» курс развития джавы, при котором поломка работавших с лохматых версий вещей ради непонятно чего стала нормой.

izzholtik ★★★
()
Ответ на: комментарий от izzholtik

Ломаются те вещи, которые завязаны на внутренностях. Ограничение доступа к внутренностям позволяет в будущем эти внутренности менять без боязни того, что что-то поломается. То бишь это вынужденные решения, которые продиктованы желанием не повторять подобную ситуацию в будущем.

Раньше с этим поступали проще. Говорили «не используйте всякие sun.* никогда вообще». Но их не слушали и использовали. Поэтому пришли к выводу, что нужно не говорить, а запрещать техническими средствами.

Нормальный код как работал в Java 1.0, так и будет продолжать работать в Java 16.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

Ломбок через штатный annotation processing работает, это не чёрная магия ни разу..

izzholtik ★★★
()
Последнее исправление: izzholtik (всего исправлений: 1)
Ответ на: комментарий от anonymous

Это не что там такого в Бут, а чего теперь нет в ждк, смотри ченжлоги того чего повыбрасывали и делай выводы

Вроде бы ничего связанного с LDAP не выбросили, а наоборот добавили.

ну и не плохо было бы сказать что вместо 16 было ранее

Было 15. Планирую обновлять версии JDK вплоть до выхода 17 в этом сентябре и затем остаться на 17, поскольку это LTS.

hummer
() автор топика
Последнее исправление: hummer (всего исправлений: 1)
Ответ на: комментарий от hummer

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

Все проблемы подобного толка в джаве сейчас либо от 1) что-то выбросили в отдельный проект и отдельно подключаемые пакеты 2) переместили в связи с обмодуливанием 3) была какая-то рефлексивная магия за пределами устава хогвартса и в новых джава версиях оно больше не работает.

anonymous
()
Ответ на: комментарий от izzholtik

Вообще, у меня вызывает сильные сомнения «новый» курс развития джавы, при котором поломка работавших с лохматых версий вещей ради непонятно чего стала нормой.

Абсолютно всегда было нормой не ломать то, что лежит в java., стараться не ломать то, что лежит в javax. и уж совсем никогда никто не говорил что лежащее в com.sun.* будет вообще где-то работать, а у тс поломалось именно там

Поясню: то что лежит в java.* это то, что входит в стандартную спецификацию языка и должно поддерживаться любой жвм, которая декларирует поддержку базовой спецификации.
В com.sun.* лежат «бонусы», которые не входят в спецификацию, которые могут ломаться/появляться/удаляться не только между версиями, но и между разными жвм одной версии.
Исторически эти вещи принято не рекомендовать к использованию, ибо они требуют бОльшего внимания, чем привыкли жабакодеры, более того, по дефолту тот-же эклипс кучу импортов оттуда маркирует ошибкой и не даёт собрать проект пока ты в настройках не разрешишь стремные импорты.

Есть кстати положительные изменения - например недавно http сервер переехал из ком.сан в основную спецификацию, что очень радует :-)

rukez ★★★★
()
Ответ на: комментарий от anonymous

Все проблемы подобного толка в джаве сейчас либо от 1) что-то выбросили в отдельный проект и отдельно подключаемые пакеты 2) переместили в связи с обмодуливанием 3) была какая-то рефлексивная магия за пределами устава хогвартса и в новых джава версиях оно больше не работает.

А можно примеров?
В отдельный пакет просто, насколько помню, выкидывали только javafx, возможно ещё дерби (хотя вроде ещё не выкинули) и какие-то кишки из jni (хотя не уверен что они вообще были в ждк).

rukez ★★★★
()
Ответ на: комментарий от rukez

Эта тема пример, ты два назвал, хмл парсеры выкинули еще пример. Если надо еще примеров, добро пожаловать в чейнжлоги там каждую версию что-то объявляют устаревшим и грозятся выкинуть в следующем релизе или уже выкинули в текущем или перетасовали в виде модуля или все наоборот лысый лысого… Довольно завлекательно чтиво, рекомендую. Даже относительно 16 релиза есть на что обратить внимание.

anonymous
()
Ответ на: комментарий от rukez

https://docs.oracle.com/javase/8/docs/api/javax/jws/WebService.html например. В Java 9 вынесли в отдельный модуль, который объявили устаревшим, в 11 вроде окончательно выкинули из JDK.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от anonymous

Эта тема пример

эта тема как-раз не пример ибо com.sun.* никто и не обещал что будет работать вне oraclejdk той версии, в которой ты это нашёл

ты два назвал

javafx в целом логично что вынесена ибо места много а толку мало (мало кому надо), с дерби аналогично, с jni/jna свои заморочки - это как дать гранату обезьянкам и потом обижаться что они убились, но повторюсь что я не уверен что они вообще были в спеках

главный цимус - когда что-то выносят в отдельный пакет, код менять не надо, надо только при старте показать где пакеты лежат т.е. если у тебя есть жарник с javafx8, который работал на jdk8, то ты можешь его стартануть и под 11/15 добавив только аргумент при запуске, который намекает где теперь у тебя лежит fx

например

а, точно, я ими кажись в последний раз в 00ых пользовался :-)

eщё вдогонку к этому же

с одной стороны куча конструкторов для базовых переменных выкидывается, с другой стороны они все были ниочень. справедливости ради могли бы просто слинковать выкидываемые в правильные благо они одинаковые по вход-выход
с паузой потоков давно пора покончить ибо редкой дебильности вещь, компилятор остаётся из javax.tools.JavaCompiler, URLDecoder не очень понял зачем улетает, javax.security.cert.* просто переезжает в java.security.*, в который давно пора бы докинуть нормальный генератор сертификатов (если уже не докинули, я дальше 11 пока не хожу)

но в целом да, похоже что не всё из 11 переедет на 17 прям влёт.
с другой стороны и платная поддержка старых лтс должна же себя как-то окупать :-)

rukez ★★★★
()
Ответ на: комментарий от anonymous

По моим ссылкам лишь проблема доступности внутреннего API Java, проявившаяся лишь в Java 16. Никто ничего не выбросил, а лишь закрыл доступ извне. Проблема точно такая же, как с Lombok, но решённая проще, поскольку пользоваться этим com.sun.jndi.ldap.LdapCtxFactory напрямую, на самом деле, не нужно.

hummer
() автор топика
Ответ на: комментарий от rukez

никто и не обещал что будет работать

что лишь подтверждает что является, нежели нет. В этом собственно все и дело, что никто никогда ничего не обещает, а если обещает, то обещание обязательно нарушает, такова суть развития.

но в целом да, похоже что не всё из 11 переедет на 17 прям влёт. с другой стороны и платная поддержка старых лтс должна же себя как-то окупать :-)

Надо просто не быть ТС и не переезжать уж слишком быстро, вот когда все то что используется и работает начнет протухать, тогда и пора перебираться, а переезд с 15 на 16 и следовательно более ранние переезды… если только совсем скучно и грустно. Я бы послушал оправдания этого переезда.

anonymous
()
Ответ на: комментарий от hummer

Там были озвучены как минимум 3 причины поломок в джава софте, под одну из них ситуация подпадает. Откровенно, мне лень смотреть как именно «решена» проблема, но да 80% что там наспех написан слой совместимого кода который эту проблему хачит, до лучших времен когда основная кодовая база будет переписана с новыми требованиями 16го релиза и возможно релизов более поздних.

anonymous
()
Ответ на: комментарий от anonymous

Откровенно, мне лень смотреть как именно «решена» проблема, но да 80% что там наспех написан слой совместимого кода который эту проблему хачит, до лучших времен когда основная кодовая база будет переписана с новыми требованиями 16го релиза и возможно релизов более поздних.

Не ленись и посмотри. Там совсем простой патч и без каких-то грязных хаков:

https://github.com/spring-projects/spring-ldap/commit/0a1d3f595b670412b7fd7ab739237c57381a7fa8?branch=0a1d3f595b670412b7fd7ab739237c57381a7fa8&diff=unified

Осталось просто дождаться выхода Spring LDAP 2.3.4-RELEASE.

hummer
() автор топика
Ответ на: комментарий от anonymous

Я бы послушал оправдания этого переезда.

Проект находится в самом начале своего развития, поэтому уже сейчас начал готовиться к появлению LTS Java 17 в сентябре. Сейчас это сделать проще, чем когда проект обрастёт массой легаси.

hummer
() автор топика
Ответ на: комментарий от hummer

Ты путаешь com.sun.* с sun.* https://www.oracle.com/java/technologies/faq-sun-packages.html

com.sun = sun, приписка com намекает что там может быть не опенсорс (но это вроде уже давно не так) или лицензионные ограничения

Собсно по твоей ссылке перечислены пакеты, из которых можно брать пакеты, если ты планируешь использовать official jdk ( = openjdk на данный момент) и это только java., javax. и org., я там выше расписал чем отличается java. от javax.* (они вне базовой спецификации), org это то что в спецификацию по ходу вообще не вошло, но передано из проприетарных в опенсорс (не вникал особо)

rukez ★★★★
()
Ответ на: комментарий от rukez

com.sun = sun, приписка com намекает что там может быть не опенсорс (но это вроде уже давно не так) или лицензионные ограничения

Это не более, чем твои ложные догадки. На самом деле это просто следование конвенцие именования. В Maven Central полно таких публичных библиотек, например Mail. https://github.com/javaee/javamail/tree/master/mail/src/main/java/com/sun/mail

hummer
() автор топика
Последнее исправление: hummer (всего исправлений: 1)
Ответ на: комментарий от hummer

Это не более, чем твои ложные догадки.

это историческое наименование

В Maven Central полно таких публичных библиотек, например Mail

ты отличаешь библиотеку от части ждк?
твоя библоитека может хоть gay.porn.* лежать - это твоё личное дело как её обозвать

то что лежит в ЖДК:

  • java.* = базовая спецификация. всё что лежит в ней ты должен поддерживать, если ты хочешь выпустить свою жвм и сказать что она совместима минимальным охватом SE. В своём коде ты можешь использовать всё что там лежит без оглядки.
  • javax.* = то, что не вошло в базовую спецификацию языка, но поддерживается большинством жвм. В своём коде можешь использовать если планируешь использовать official jdk или 100% совместимые
  • org.* - там лежит то, что переехало из com.* когда ява стала опенсорсной и при этом попало в поддержку official jdk, можешь использовать как javax.*
  • com.* (в том числе com.sun.*) - там лежит то, что не попало никуда но по ряду причин было в official jdk, например там долго лежал (и вроде до сих пор лежит, хотя переведён в спецификацию жвм) вэб сервер. изначально там был навален закрытый код и код под лицензиями, сейчас - хз, видимо при опенсурсивании явы всё открыли. Дык вот всё что там лежит, может не поддерживаться нигде и никем за пределами official jdk, и поддержка внутри official не гарантируется за пределами версий наличия, по хорошему ты вообще не должен рассчитывать на эти классы и не должен их нигде использовать за исключением ситуации когда ты привязываешь свой код к конкретной версии конкретной жвм. усё, точка.

но при желании можешь продолжать долбить ком.сан, просто не забывай нас информировать как у тебя в очередной раз подгорел пукан :-)

rukez ★★★★
()
Ответ на: комментарий от rukez

Забавно как ты несёшь в массы некое тайное знание без единой ссылки на официальные источники и ещё хамишь мне при этом. Судя по всему это у тебя пукан подгорел.

hummer
() автор топика
Ответ на: комментарий от rukez

Ну тайное оно только для особенных, остальные как бы в курсе:

https://stackoverflow.com/questions/727844/javax-vs-java-package

https://stackoverflow.com/questions/55798992/difference-between-sun-vs-com-sun

И где тут хотя бы один официальный источник о том, что com.sun == sun в JDK, по валидности использования в коде?

За хамство ты так и не извинился. До сих пор пукан шкварчит?

hummer
() автор топика
Ответ на: комментарий от hummer

И где тут хотя бы один официальный источник о том, что com.sun == sun в JDK, по валидности использования в коде?

Ты точно прочитал и понял, что там написано?

Most of the original sun.* APIs have either been removed, promoted to official javax.* API, or renamed to the more proper com.sun.* domain

Никакого официального источника тебе не будет - никто никогда не отчитывался о том что-куда помещается ибо кто ты такой что бы тебе ещё официально толковать решения партии

За хамство ты так и не извинился

Лол, перед тобой штолле?

До сих пор пукан шкварчит?

Алеш, пуканы горят у тех кто не осиливает даже в логику названия пакетов и не прислушивается к советам не трогать что-то за пределами основы.
Ты же по ходу не осиливаешь даже в разделение ждк и сторонних либ, так что продолжай остужать пукан погружаясь в волшебный мир буков, может через годик-другой твоя мамка перестанет называть тебя особенным :-)

rukez ★★★★
()
Ответ на: комментарий от rukez

Ты точно прочитал и понял, что там написано?

Ты точно не понял суть моего вопроса.

Никакого официального источника тебе не будет - никто никогда не отчитывался о том что-куда помещается ибо кто ты такой что бы тебе ещё официально толковать решения партии

И вот ещё одно доказательство того, что ты не понял ибо тебе нечем. Выше я привёл ссылку на официальный FAQ от Oracle с указанием: «не пользуйтесь классами из пакетов sun.*». Где точно такое же официальное указание/рекомендация не пользоваться классами из пакетов com.sun.*? Его нет.

За хамство ты так и не извинился

Лол, перед тобой штолле?

Да, передо мной, хам ты невоспитанный.

Алеш, пуканы горят у тех кто не осиливает даже в логику названия пакетов и не прислушивается к советам не трогать что-то за пределами основы. Ты же по ходу не осиливаешь даже в разделение ждк и сторонних либ, так что продолжай остужать пукан погружаясь в волшебный мир буков, может через годик-другой твоя мамка перестанет называть тебя особенным :-)

Ещё один пример твоего хамства, вперемешку с не меньшей глупостью. Продолжай разговаривать с собой, Алеш.

hummer
() автор топика
Ответ на: комментарий от hummer

Выше я привёл ссылку на официальный FAQ от Oracle с указанием: «не пользуйтесь классами из пакетов sun.». Где точно такое же официальное указание/рекомендация не пользоваться классами из пакетов com.sun.? Его нет.

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

rukez ★★★★
()
Ответ на: комментарий от rukez

и не будет, ровно как и обьяснения что это вообще такое, такая вот печалька.

Вот так ты и слил.

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

Сколько тебе вообще лет, поучающий юноша? :-)

hummer
() автор топика
Ответ на: комментарий от hummer

Вот так ты и слил.

я то тут причём, если это у оракла никогда не было обьяснений по поводу маркировки пакетов (, но сиё «тайное знание» очевидно всем кроме тебя
но ты не стесняйся, отправь в оракл телефонограмму с претензиями и требованием извиниться, можешь приложить фотографию горящего пукана и угрозу использовать слово «слил» как минимум три раза.

Сколько тебе вообще лет, поучающий юноша? :-)

37, а что, в светофоры реально не получается без подсказок? :-)

п.с. на случай если кто-то еще читает этот бредовый топик и потерял его ценность в потоках сознания несогласных с очевидным, вот полезный комментарий из ссылок на stackoverflow выше, который описывает как формировались пакеты в исторической перспективе и почему оно нонче так как есть и никак иначе:

The javax namespace is usually (that’s a loaded word) used for standard extensions, currently known as optional packages. The standard extensions are a subset of the non-core APIs; the other segment of the non-core APIs obviously called the non-standard extensions, occupying the namespaces like com.sun.* or com.ibm.. The core APIs take up the java. namespace.

Not everything in the Java API world starts off in core, which is why extensions are usually born out of JSR requests. They are eventually promoted to core based on ‘wise counsel’.

The interest in this nomenclature, came out of a faux pas on Sun’s part - extensions could have been promoted to core, i.e. moved from javax.* to java.* breaking the backward compatibility promise. Programmers cried hoarse, and better sense prevailed. This is why, the Swing API although part of the core, continues to remain in the javax.* namespace. And that is also how packages get promoted from extensions to core - they are simply made available for download as part of the JDK and JRE.

rukez ★★★★
()
Ответ на: комментарий от rukez

я то тут причём, если это у оракла никогда не было обьяснений по поводу маркировки пакетов

В том-то и дело, что такое объяснение у них есть и ссылку на него я выше уже давал. Ты просто тупишь.

Сколько тебе вообще лет, поучающий юноша? :-)

37

И кто тебе дал право поучать старших?

hummer
() автор топика
Ответ на: комментарий от hummer

В том-то и дело, что такое объяснение у них есть и ссылку на него я выше уже давал. Ты просто тупишь.

ну давай, расскажи нам официальную версию разделения на java., javax., com.sun.* и sun.*, а то по ходу это у тебя, оказывается, есть секретные данные а ты и молчал всю дорогу

И кто тебе дал право поучать старших?

матушка природа, которая по ходу была на тебя зла за что-то
не начинай в яву, это вообще не твоё если ты не можешь даже в названия :-)

rukez ★★★★
()
Ответ на: комментарий от rukez

ну давай, расскажи нам официальную версию разделения на java., javax., com.sun.* и sun.*, а то по ходу это у тебя, оказывается, есть секретные данные а ты и молчал всю дорогу

Снова тупишь. Разговор лишь о правомерности использования com.sun.* в коде.

Раз уж ты на столько туп и не видишь разницу в использовании sun.* и com.sun.*, то вот тебе такой пример. В Java 6 были добавлены стандартные реализации HTTP HTTPS серверов. Сделано это было примерно вот так.

Абстрактные классы:

  • com.sun.net.httpserver.HttpServer
  • com.sun.net.httpserver.HttpsServer

Их реализации:

  • sun.net.httpserver.HttpServerImpl
  • sun.net.httpserver.HttpsServerImpl

А теперь расскажи мне, какие исторические причины заставили разработчиков Java 6 использовать com.sun.net и sun.net одновременно? Или почему javadoc этих абстрактных классов попал в официальную документацию? https://docs.oracle.com/javase/8/docs/jre/api/net/httpserver/spec/com/sun/net/httpserver/HttpServer.html

матушка природа, которая по ходу была на тебя зла за что-то

Ты уже и с природой разговариваешь? Попробуй обратиться к психиатру.

не начинай в яву, это вообще не твоё если ты не можешь даже в названия :-)

Опять поучаешь, хотя сам и по-русски-то толком разговаривать не умеешь.

hummer
() автор топика
Последнее исправление: hummer (всего исправлений: 1)
Ответ на: комментарий от Nervous

Ну Spring штука хорошая, если его выкидывать, придётся тащить сборную солянку из кучи всего. Там и DI, там и MVC-фреймворк, там и куча вкусняшек вроде Spring JDBC. Конечно есть чем заменить, но лично у меня к самому Spring-у претензий никогда не было. Ну разве что тяжеловат, если применение не для сервера, например в десктопном приложении я бы поискал другие варианты. Или если оперативной памяти меньше 50 МБ хочется тратить. Но это всё же редкость в Java-разработке.

Legioner ★★★★★
()
Ответ на: комментарий от rukez

Ты не прав. Тот же com.sun.net.httpserver всегда имел жавадок и всегда был официально доступен. Сейчас выделен в отдельный официальный модуль. А с исходниками это не связано, раньше для кучи кода в JDK исходники не поставлялись. Никаких проблем с тем, чтобы его использовать, нет. Он имеется в любой JDK и официально задокументирован.

Не буду утверждать, что это так для всех com.sun.*, т.е. я с ними почти не сталкивался кроме httpserver и mail. Но вышеперечисленные пакеты абсолютно стандартны и используются кучей софта. При этом я вполне допускаю, что когда-нибудь их из JDK выкинут в отдельную зависимость, но в целом это не является проблемой на практике.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.