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
