Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epp-dev] EPP 2020-12 RC2



I've added this commentary to

It sounds like there are some things that would be good to be able to debug, but without the hardware that doesn't seem possible...

Perhaps if I can work remotely on the machine being used to build the JRE...  Let's see how many people download it and whether this is worth my "free time" investment...

Yes, the installer adding the -vm option is expected.  On Windows the installer can know if you're using the default VM or not and hence whether to add a -vm option or not, but that's harder to determine on the other OSes and the request for the launcher to record the PATH before the launcher mangles it hasn't moved forward.   Also on Windows, we can look in the registry to find JVM installation, and Mac has a lookup mechanism as well.  For Linux it's not so clear how to find all the available JRE/JDK choices (and no one has contributed something toward that effort)...

Wanting a full JDK within the IDE for development is of course orthogonal what's used to run the IDE, though of course the default JRE configured by JDT is the one used to run the IDE, so it doesn't really look so orthogonal.  In any case, the installer does have browse button that lets you choose a JDK located on your machine...


On 12.12.2020 00:04, Nitin Dahyabhai wrote:
I threw Fedora Workstation 33 onto a pi4 (well, a microSD card) and tried it. While I got the same console message as Liviu did about WebKit limitations, the installer opened and let me pick the Enterprise Java option. The extracted contents of the tarball didn't match the tarball's base name--I'm used to those being the same. I have more disdain for the lack of affordances and attention to UX in the default gnome shell than when I last spent time with it, the better part of a decade ago.

There were frequent banner messages about "the installation process is taking longer than usual", though, sometimes mentioning it was while fetching or installing a particular bundle, but at other times just listing the bundle name and no indication of what action was taking longer than usual. Installation of the Enterprise Java option failed for this first attempt, however, with the subsequent "installation log" display not accepting inputs, the desktop UI telling me that SWT had become unresponsive, and while I was typing this on another machine, closing itself out. The second attempt from a reflash of the card/system succeeded, and I'm not sure what the difference was between the two attempts. A third attempt on that same system install, for the JS package, also completed.

I don't have a lot of experience using the installer, but it wrote a -vm line into the eclipse.ini file. As it turns out, the Workstation install included a JRE, the path to which is what was written into the eclipse.ini, but I needed to install the full JDK package to properly develop Java and debug a .jsp file locally on an ApacheTomcat instance. The hard-coded -vm value wasn't updated automatically (not that I expected that), but is hard coding the path the expected behavior? I'd have thought it a choice between installing a JustJ with a -vm switch into the .ini, or trusting the newly installed Eclipse to find the same Java runtime that the installer found at its own launch time.

So I guess that's a +1 for the installer itself on aarch64?

Back to the top