Consider upgrading BEViewer.jar to Java 8 or 11 LTS

[joachimmetz]

While setting up MacOS Travis CI tests, I encountered the following warning/error (From: https://travis-ci.com/github/simsong/bulk_extractor/jobs/348995196#L4280)

warning: [options] bootstrap class path not set in conjunction with -source 6
error: Source option 6 is no longer supported. Use 7 or later.
error: Target option 6 is no longer supported. Use 7 or later.
make[2]: *** [BEViewer.jar] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

A note at https://github.com/simsong/bulk_extractor/blob/master/java_gui/Makefile.am#L134 indicates to update to 1.7 or later.

Java 6 is end of life per https://en.wikipedia.org/wiki/Java_version_history.

I opt to consider upgrading BEViewer.jar to Java 8 or 11 LTS

[joachimmetz]

I've included changes to use Java 8 in simsong/bulk_extractor#133 (technically OpenJDK 13 https://travis-ci.com/github/simsong/bulk_extractor/jobs/349018073#L46)

[simsong]

My understanding is that significant charges are required to support current versions of java. Is that not the case?

I have been looking for someone to do a totally rewrite of the GUI As a web app or just drop it. What do you think?

[joachimmetz]

I think sticking with OpenJDK is free of costs. The information I could find https://www.itassetmanagement.net/2019/02/21/oracle-java-new-licensing-model/

[joachimmetz]

I have been looking for someone to do a totally rewrite of the GUI As a web app or just drop it. What do you think?

I personally would move it out of this repo into its separate repo and if there is a strong desire for someone to have an UI they can contribute. So I'm also fine with removing it.

[simsong]

I have been looking for someone to do a totally rewrite of the GUI As a web app or just drop it. What do you think?

I personally would move it out of this repo into its separate repo and if there is a strong desire for someone to have an UI they can contribute. So I'm also fine with removing it.

The issue is packaging. Currently this repo has all of the documentation, the Java viewer, and it builds a windows installer. If we create another repo, it would be logical for it to be a repo that has the installer and the GUI, and this one to be a subrepo. But that is a lot of work and I currently do not have anyone other than you and me working on this project, and I have 3 other jobs...

[joachimmetz]

Agree that available time is a large limiting factor. Maybe then the best option might be discontinuing it. If people feel strongly about a revamp, they can always salvage the last version from the git history.

[simsong]

A surprising number of people still use it. I am also looking for a summer intern that can rewrite it using HTML, python, JavaScript and Bottle. It shouldn’t be that hard.

…

On Jun 15, 2020, at 7:43 AM, Joachim Metz ***@***.***> wrote: Agree that available time is a large limiting factor. Maybe then the best option might be discontinuing it. If people feel strongly about a revamp, they can always salvage the last version from the git history. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/simsong/bulk_extractor/issues/136#issuecomment-644078063>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMFHLHAM2JIXJGDWYSUIJDRWYCNVANCNFSM4N532F4A>.

[joachimmetz]

Maybe let's create a "help wanted" issue for the rewrite? And keep it on minimum Java 8 for now?

[simsong]

I don't think that the current GUI works under Java8. I recall that @BruceMty looked at it a long time ago and thought it was more work than he wanted to spend.

[BruceMty]

I don't recall any forward-compatibility conflicts with BEViewer. I do recall that my autotool implementation for rejecting older versions of Java was clunky and it rejected newer versions of the JVM, thinking it was old. BEViewer is based on Swing. I expect Swing has remained forward-compatible. Possible gotchas might relate to differences in Mac/Linux/Win OSs, specifically, keyboard mappings and cut/paste buffering. Bringing BEViewer to run on current Java may be fairly trivial.

It seems reasonable to me to move BEViewer out of bulk_extractor and into its own repository. The Windows installer pluming for BEViewer would also move over.

If it did get ported out of Java, I might recommend using Python3 with the Qt5 widget toolkit. I have been happy with this combination.

[simsong]

@BruceMty , thanks for responding!

I will take as an action item to move the GUI into its own repo and to move the Windows installer into its own repo. Realistically, they could be the same repo.

[BruceMty]

@simsong, sounds good. It seems appropriate to have the GUI and its Windows installer together in their own repo, completely decoupled from bulk_extractor.

[simsong]

It seems reasonable to me to move BEViewer out of bulk_extractor and into its own repository. The Windows installer pluming for BEViewer would also move over.

If it did get ported out of Java, I might recommend using Python3 with the Qt5 widget toolkit. I have been happy with this combination.

My feeling was to make it a web app, with the backend running locally with Bottle and CherryPy, and the business happening in a web browser with JQuery. I think that the browser's handling of JavaScript, HTML, and CSS is much faster than Qt5 at this point, there are far more people who know how to program JavaScript/HTML/CSS, and this would allow use in a client/server application moving forward.

I've now programmed enough large-scale applications with both pyqt and with HTML and JavaScript that I will not start another app using QT.

[BruceMty]

Okay, sounds good.

[simsong]

To be clear, this project is a LONG WAY from being ready for Travis-CI. I just disabled it.

[simsong]

Maybe let's create a "help wanted" issue for the rewrite? And keep it on minimum Java 8 for now?

Unfortunately,I have not been successful with "help wanted" advertisements in the past.

[simsong]

I think sticking with OpenJDK is free of costs. The information I could find https://www.itassetmanagement.net/2019/02/21/oracle-java-new-licensing-model/

My understanding is that every version of Java is free.

[fcgreg]

Chiming in here as well. I'm happy to contribute to BEViewer and possibly the NSIS/Windows installer work. I'm currently working on a fork of this repository and noticed we should update the baseline Java version to at least Java8. I'd be fine with Java11 as well. There are well-supported, freely available open source Java runtimes that support all major language features (Adoptium/Eclipse Foundation being a really good one). The open source community is committed to maintaining these well into the distant future.

A few additional thoughts/questions for everyone, including @BruceMty and @joachimmetz if you feel like giving some guidance:

• I believe having GUI front-end is critical to keeping Bulk_Extractor a viable tool for most modern examiners out there. Since we already have a working Java-based GUI, that is by-far the quickest route to giving BE 2.x a working front-end as well. I'm happy to migrate the existing 1.x build to an implementation on a 2.x branch (or Main).

• What is the consensus on the minimum Java version... 8 or 11?

• Would it be beneficial to splitting the build framework for BEViewer into an Ant/Gradle type system instead of relying solely on Autotools-based components? (It might help with minimum version checks and other language-specific things.)

• Do you feel it's necessary to continue coupling the BEViewer project/repo to the Windows-installer project? (Since a Java-based BEViewer should work on any platform, I don't see a particular need to couple the two in the same repo.)

[fcgreg]

After doing more research, it seems certain that Java 11 is the better minimum version these days, especially since Java 8 is no longer supported by certain platforms/vendors (esp. Oracle). Between that and the significant language/JVM improvements, the good LTS versions available, including open source (Adoptium) versions, and since 11 is the version where many of operating systems are providing base-support for Java, 11 seems to be very appropriate here.

Unless someone disagrees, I'll be porting BEViewer to Java 11 as I make my updates.

[simsong]

I strongly support moving to Java 11.