Hello, world!

As WireShare's first developer, maintainer, and Grand Pooh-Bah, it is my honour and privilege to announce that the source for WireShare 6.0 has now been committed to the SourceForge Git repository, and that a new release (for all platforms---see below for caveats) is imminent.

As you can see from the version number, this is a major release, and as such, it contains a number of critical updates and fixes.  It is therefore strongly suggested that you download and install it as soon as you can.  Because of developer attrition, this is also the first (and, I hope, only) version of WireShare that required money to produce.  We therefore request that you read the following, try our software, calculate how much it's worth to you, and donate at least part of that number to our Indiegogo.  Those among you with Java skills might also consider joining the project.  Given that nearly all our funds go towards labour costs, a few expert volunteers is all we need to continue our stewardship of WireShare and the Gnutella network. Without further ado, on to the changelog.

The foremost new feature for this release is that it now runs under Java 11 and better.  Although this might at first sound like a minor bug-fix, its significance can not be overstated.  In particular, "dependency hell" is no longer a nuisance for Unix users who previously experienced it when trying to install WireShare.  This issue arose because Oracle Java 8 (until now a prerequisite, or "dependency", for installation) was not always present in the package manager, and even if it was, it sometimes failed to install or function, or caused system instability because of its obsolescence.  WireShare 6.0 obviates this problem by including its own "potted" Java runtime environment and thus having no external dependencies of any kind.

For everyone else, making the switch has resulted in WireShare 6 being blazingly fast, consuming less memory, and connecting almost instantly.  Here at the office, for example, it shows 5 bars within thirty seconds of startup.  The new Java deployment process (as above already mentioned) means that users need not download a separate Java package before installing; the WireShare installer now includes everything it needs.  Although credit for these improvements goes largely to the "upstream" developers (not least, the OpenJDK community), making WireShare compile in this new version of Java took a lot of work.  A =lot= of work.

Passive alerts (what Google calls "toasts") are much improved in this version as well.  The passive alert, in the form of a textual notification in the corner of the screen that takes no input and vanishes automatically, was first popularised around the time of OS X Mountain Lion, Ubuntu Precise Pangolin, and Windows 8, but it dates back to long before 2012.  Prior to its invention, it may be noted that events taking some degree of input would trigger a pop-up dialogue box, while those that didn't would typically play a sound; some workflows were sorely missing an unobtrusive, intermediate level of user interaction.

Because of WireShare's usage pattern, we were arguably pioneers, together with MSN Messenger, in this new kind of notification.   As such, we were forced at the time to "roll our own" implementation on the app level; being in Java, it never really "meshed" with the look-and-feel of any particular operating system, it was sluggish and buggy to boot, and when Mountain Lion and its peers came along, we were left to contend with app-level and system-level "toasts" side by side.  The fix has been a long time coming, but WireShare now fires system-level toasts on every OS.

PACKAGING: The typical distribution method for Java 8 software was to require the user to download a so-called "Java Runtime Environment" (which contains a "Java Virtual Machine"), and to distribute application software on its own.  With Java 11, this has changed.  Developers are now advised to bundle a separate Java Virtual Machine with each individual program they distribute, customised for that specific program.  I can attest from experience that the new way is much better... with two caveats.  One: there is not a lot of documentation on adjusting from "the old way" to "the new way".

Two: Oracle does not currently provide any kind of utility to bundle software for distribution, and, what's worse, they removed support for the ones they used to provide (javapackager, jarbundler, jpackage). After much time and effort, a third-party port of jpackager was successfully located, theoretically solving the problem to satisfaction.

Owing to the change of paradigm detailed above, and egregiously unclear (third-party) documentation, an adjustment period was necessary, which accounts for the slow pace in releasing packages.  On top of this, jpackager doesn't cross-compile (in other words, to make a package on a Mac, you need to go through the process on a Mac). Notwithstanding the speed bumps, though, we expect to have a release available soon for every platform.

java.base,java.datatransfer,java.desktop,java.logging,java.management,java.naming,java.net.http,java.prefs,java.security.jgss,java.security.sasl,java.sql,java.xml,jdk.xml.dom


KNOWN ISSUES: With the move to Java 11, there have been a few structural changes.  On Macintosh, WireShare no longer looks "inside itself" to find a few DYLIB files that are necessary for it to function, so they now need to be put in a designated directory.  Furthermore, some proprietary Apple libraries in the code were "walled off", notably com.Apple.eawt.*  Anything that relied on this was "stranded", leaving the whole code base unable to compile.  We've managed to turn the fatal error into a bug: WireShare 6 now runs on Mac, but dialogue boxes won't open.

This just goes to show that while software in Java ideally follows the Write Once, Run Anywhere philosophy, it's really Write Once, Debug Everywhere in practice.  We decided that holding back release until the problems were fixed would be grossly unfair to our Windows and Unix user base, especially because it's been mitigated to some extent on Mac as well.  Still, a product having so much as one outstanding bug is a clear indication that it's Not Ready for Prime Time; would-be developers should take note that the v6.0 source in the Git repository is in no way final and can change without warning.
