Java 8 or Scala 2.12 are my personal choices. While Java 9 would be cool to use, yeah, it's still a bit early there. Thankfully, Chainsaw is primarily a GUI, so maintaining compatibility with older JVMs is unnecessary. With Java 9, we should be able to bundle just the modules needed to make a standalone executable, though I'm not clear on how licensing works with that since OpenJDK and HotSpot are all GPLv2 with some exceptions added.
Also, even if we use Scala in this, it could be possible that parts of the app make sense in Java while others make sense in Scala. It remains to be seen, but I'm sure we'll figure out a good match over time as we update the code. On 15 October 2017 at 15:31, Mikael Ståldal <mi...@apache.org> wrote: > I also think it is a bit to early to depend on Java 9. However, we should > depend on (and make use of) Java 8. Not sure if Java 9 give any > substanstial benefits in this project (Java 8 definitely does). > > If we want to rewrite it completely, I would go for Scala 2.12 (on JVM 8). > I don't think Kotlin is much used outside of Android, so Scala is probably > a safer bet. (I would choose Kotlin for an Android app though.) > > > > On 2017-10-14 20:12, Gary Gregory wrote: > >> I would really stay away from Java 9 at this point. There is too much >> incompatible tooling out there at this point. I can't even run most apps >> out of the box I have laying around on Java 9 without breakage. >> >> Gary >> >> On Sat, Oct 14, 2017 at 12:09 PM, Matt Sicker <boa...@gmail.com> wrote: >> >> I forgot to mention my current difficulty in the release process are >>> broken >>> tests. I just noticed that my default Java version on this computer is >>> actually 9, not 8, so that could be related. Any guidance from anyone >>> who's >>> successfully built this before would be great. >>> >>> On 14 October 2017 at 13:01, Matt Sicker <boa...@gmail.com> wrote: >>> >>> First off, for some reason, there are two repositories: >>>> >>>> https://github.com/apache/chainsaw >>>> https://github.com/apache/logging-chainsaw >>>> >>>> The second one appears to be up to date. Not sure what to do about the >>>> first one as it seems to be a relic of when Chainsaw was in SVN. >>>> >>>> Next, bug tracking. The pom says its bugs are tracked in Bugzilla. It >>>> was >>>> tracked as a component of Log4j 1. See this: <https://bz.apache.org/ >>>> bugzilla/buglist.cgi?bug_status=__open__&component= >>>> chainsaw&product=Log4j%20-%20Now%20in%20Jira>. I believe it would be >>>> useful to switch over to JIRA like we're using for the rest of the >>>> >>> logging >>> >>>> projects. Perhaps we can ask infra for some sort of issue transfer if >>>> possible. >>>> >>>> Another issue: the Java source version is set to 1.4. That means it >>>> doesn't even compile using Java 8 due to 1.6 being the oldest source >>>> version usable. That also means that this project hasn't been updated to >>>> use generics let alone anything else from the past 13 years (Java 5 was >>>> released in 2004 back when I was learning how to program in the first >>>> place!). As such, incrementing the base Java version to 1.6 would be a >>>> minimum change, and I think if we increased to Java 8 or 9 after a >>>> >>> release, >>> >>>> that would give us a nice opportunity to do some mechanical refactorings >>>> and such which can sometimes be fun. >>>> >>>> Really, though, the choice of Java version or JVM language in general >>>> for >>>> a modernized version should be determined by whoever is interested in >>>> helping clean everything up and move forward. In that case, since I feel >>>> >>> a >>> >>>> bit interested here, I'd propose going with either Java 9 or Scala 2.12 >>>> (Scala provides a neat Swing API wrapper as well). Kotlin could also be >>>> a >>>> contender here, though I haven't used it much at all yet, so I can't >>>> >>> really >>> >>>> make a real recommendation there. There's also the option of migrating >>>> >>> from >>> >>>> Swing to JavaFX if there is interest, though I've never really used >>>> >>> JavaFX >>> >>>> before (but have used Swing). >>>> >>>> Then there is the notion of distribution. Since this is a GUI app, it's >>>> not generally as simple as just publishing to Maven Central. Naturally, >>>> >>> the >>> >>>> standard Apache release process of publishing sources and binaries to >>>> SVN >>>> works fine, but there are additional options we can consider: >>>> * Publish a Java webstart thing (would require working with infra to get >>>> the releases signed; current build instructions tell the user how to >>>> >>> create >>> >>>> their own release using a signing key and such) >>>> * Publish a macOS .app bundle. This can be published through our normal >>>> release channel, but there may also be a way to publish to the Mac App >>>> Store. Also, a Homebrew formula (or cask) for this would be nice, though >>>> they're normally maintained by external package maintainers just like in >>>> GNU/Linux distros. >>>> * Publish a native-ish Windows bundle. I don't see anything in the build >>>> already, but there are some tools out there to distribute a Java GUI app >>>> for Windows that could be useful here. >>>> >>>> I have other ideas I'd like to see such as adding support for the JSON >>>> layout and future binary layouts (e.g., Avro/Thrift/Protobuf/custom >>>> >>> binary >>> >>>> logging format) so there is no reliance on serialized log events or >>>> >>> dealing >>> >>>> with ambiguous log files. I'm pretty sure I could come up with a nice >>>> backlog here, and we could try to recruit some interested developers >>>> through helpwanted.a.o and potentially next time we have Google Summer >>>> of >>>> Code or other similar hackathon-like things. In general, I always find >>>> >>> the >>> >>>> viewing and searching of logs to be a pain regardless of fancy tools >>>> like >>>> ELK or Graylog or Splunk, and having a nice local GUI to sort through it >>>> all could be super useful, and I'd be interested to see this succeed in >>>> that. >>>> >>>> With all that in mind, who would be interested in helping out on this? >>>> >>> I'm >>> >>>> having difficulty with the current version getting compiled let alone >>>> getting a release cut, so I'm not even sure how feasible it would be to >>>> >>> cut >>> >>>> a release before going ahead with the next generation. If we start >>>> >>> working >>> >>>> on a major version of Chainsaw without a release for the existing code, >>>> would that need to take place in the incubator, or can we go forward >>>> >>> here? >>> >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com> >>>> >>>> >>> >>> >>> -- >>> Matt Sicker <boa...@gmail.com> >>> >>> >> > -- Matt Sicker <boa...@gmail.com>
