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.