Guus der Kinderen <[email protected]> writes: > Hi Simon, > > Although I do believe that a separate project for the java code has > considerable benefits, I wonder if it's worth doing that, given the > maturity of the entire project. It's decades old, and the foundation on > which it is based is frozen. Does splitting it up now make sense?
Probably not - but I wanted to mention the possibility. After removing the *.JAR file from the 'make dist' tarball, most of the Java stuff doesn't cause a lot of problems any more. It does add complexity to normal releases, though, since I need to have Java etc installed and updating javadoc pages takes some time. > Then again, from a cursory glance at libidn2, that doesn't have _any_ Java > port right now? Establishing a distinct Java project is perhaps something > that could be applied to both. Libidn (including the Java port) is IDNA2003 so really ancient. I would be surprised if there weren't multiple IDNA2008 Java implementations around? If not, doing one would be nice, but it is not a trivial job. I wouldn't want to add that to Libidn2 though, let's keep it separate if you or anyone wants to work on that. /Simon > So many pet projects though... > > What do you think? > > - Guus > > On Sun, Jul 12, 2026 at 8:55 PM Simon Josefsson <[email protected]> wrote: > >> Guus der Kinderen <[email protected]> writes: >> >> > Hi Simon, >> > >> >> No worries - getting things published definitely has priority. >> > >> > I pressed 'publish' moments ago. \o/ >> >> Great! >> >> > Though your reply did make me look more closely at something, and I don't >> > entirely like what I found. >> > >> > What struck me is that between 1.15 and 1.44 there are a great many >> changes >> > to the project, and essentially none of them touch the Java port. C-code >> > surely is quite different from the Java code, and the code is punned to >> > Unicode 3.2 so has little reason to move - but still: that's an awful lot >> > of non-Java-change releases. >> >> I don't think there has been any significant algorithm-related changes >> since pretty much forever though. >> >> > It makes me doubt my earlier assumption that the Java port isn't a >> > frozen-but-faithful twin of the C library; I'm now more inclined to >> believe >> > that it's an independent ~2004 implementation by a different author, that >> > may have drifted. >> >> That is right -- it was a contribution, and what little Java I ever know >> it has probably fallen out of fashion. >> >> > So perhaps, some of those releases probably *should* have touched the >> > Java side? >> >> Hard to tell -- but not certainly. >> >> > I've still published 1.44 today. What's on Central is 1.15 from 2009, >> > unsigned and without sources, so this is a clear improvement regardless. >> > But it maybe should not be the last word. What do you think? >> >> Improvements are always welcome, so maybe your update will spur some >> interest. Possibly all of the Java code could be moved into a separate >> git project, I think ~20 years ago multi-language projects made sense >> but today I think it is just a pain to have to coordinate independent >> implementations in a single release. >> >> /Simon >> >> > Regards, >> > >> > Guus >> > >> > On Sun, Jul 12, 2026 at 5:28 PM Simon Josefsson <[email protected]> >> wrote: >> > >> >> Guus der Kinderen <[email protected]> writes: >> >> >> >> > Hi Simon, >> >> > >> >> >> Yes I am happy if you can sign artifacts and make the upload. >> >> > >> >> > Thanks! >> >> > >> >> >> Are they reproducible? >> >> > >> >> > Not as things stand. The jar and javadoc tooling both embed >> timestamps. >> >> > Fixable, but I'd rather leave it out of scope for now and get 1.44 >> out. >> >> > >> >> > What I built: the Java code from the 1.44 tarball, unmodified, >> recompiled >> >> > with Java 8 for compatibility. >> >> >> >> No worries - getting things published definitely has priority. I don't >> >> know about Java reproducible artifacts, or if anyone in the Central/Java >> >> community cares. >> >> >> >> >> I suspect Java people aren't using *.JAR's from GNU tarballs, but get >> >> >> things through Maven or other sites, though. >> >> > >> >> > That's exactly right, and the current situation isn't very good: >> Central >> >> > has only 1.15 (2009) and 0.6.5 (2006): >> >> > https://mvnrepository.com/artifact/org.gnu.inet/libidn People can >> route >> >> > around it with private repositories (e.g. >> >> > >> https://igniterealtime.org/archiva/repository/maven/org/gnu/inet/libidn/ >> >> ), >> >> > which is unsigned and unofficial and not a real fix - and likely >> outdated >> >> > too. Not having it in Central will effectively make it unavailable to >> >> most >> >> > developers. Getting 1.44 onto Central should sort it. >> >> >> >> Yay! >> >> >> >> /Simon >> >> >>
signature.asc
Description: PGP signature
