Date: Sat, 27 Dec 2025 05:07:11 +0000 From: bugzilla-noreply@freebsd.org To: java@FreeBSD.org Subject: [Bug 272855] Mk/bsd.default-versions.mk: update JAVA_DEFAULT to 21 Message-ID: <bug-272855-8522-bg1InCtlvQ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-272855-8522@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272855 --- Comment #27 from Mikhail Teterin <mi@FreeBSD.org> --- (In reply to Michael Osipov from comment #26) > In C/C++ symbol versioning likely solves the problem I think, you misunderstood, what I was talking about. The version of the library, against which a program was LINKED would still matter to the software, that has just been built. But the port doesn't care -- if you have libjpeg.so.5 already installed on your system, all of JPEG-using software can be linked with that even if graphics/libjpeg is currently installing libjpeg.so.6. The APIs don't change that often. Loosening up the LIB_DEPENDS by default was a good thing -- and I'm proud to have been part of it :) > soft-deprecated version ranges That's quite wrong... Especially for the reasons listed: "people weren't using them correctly". A system with five Java applications, all using log4j, ends up with five different log4j-versions -- because none of the five application-maintainers can be bothered to just depend on ONE version, whichever it is. But they aren't satisfied with just telling you: "you need to provide log4j", because then some clueless reviewer somewhere will say: "it is not ready out of the box". And then many insist on creating a giant monolithic JAR (which Maven makes too easy), with all of the different dependencies inside it, so a sysadmin has to really stick his head out to split it apart and replace pieces -- because now he has "an unsupported configuration". (Been there, done that.) Had this line of thinking prevailed earlier, we'd never have had shared libraries either :( Sorry, I digress. > I think we need sane tradeoff w/o reinventing the wheel. The inherent conflict is UNSOLVABLE: application-authors/maintainers care about their one application working on all platforms. Platform people -- like FreeBSD ports-maintainers -- care about all applications working on our one platform. There is no solution, that both sides would like. Myself a platform person, I think, we ought to CONTINUE the 30+ years tradition of making the apps build on FreeBSD -- and do it the FreeBSD way... -- You are receiving this mail because: You are on the CC list for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-272855-8522-bg1InCtlvQ>