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?
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. 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 > >> >
