Arch Linux User Repository

java8-openjfx was certainly a pain! I believe I ran into issues because I tried to compile it with clang, but had to switch to gcc. I agree that having a binary would really make all of this go a lot smoother, so here are my thoughts on those choices:

1. This seems like a great option, but those zulu8-fx-bin (newer, but orphaned) and openjdk-zulu8-ca-fx-bin don't seem to be as actively maintained of AUR packages compared to java8-openjfx.
2. A good choice, but obviously the downside is extra disk space if someone needs java8-openjfx elsewhere.
3. This is the only one I really don't like (and why I'm commenting). If I understand correctly, determining a package to use at install time could result in an undocumented package dependency. One day, someone might pacman -Rns a package that removes the openjfx dependency they needed for this package, then they're left scratching their heads when their MPLAB X stops working!
4. Workable, but the annoyances continue.

So I'd rank those choices: 4, 1, 2 (3 not on the list). I could be wrong, but I think the way you have it set up someone who's having trouble building java8-openjfx could go out and install openjdk8-ca-fx-bin instead, then since that package "provides" java8-openjfx, all will be well (and effictively that person has just implemented your solution from list item 1). So to all those out there who have trouble building java8-openjfx, the advice can just be "install openjdk-zulu8-ca-fx-bin, then try this package again". Perhaps that could even be a pinned comment here.

Given the pain that is building the current dependencies, I was wondering if it wouldn't be better to either:

1. replace the current jre8-openjdk / java8-openjfx dependency with zulu8-fx-bin (this is already the runtime that MPLAB bundles)

2. just use the bundled java runtime

3. Remove the hard dependency on jre8-openjdk, put zulu8-fx-bin as optdepends, use the more generic java-environment=8 and java-openjfx=8 dependencies and use the archlinux-java-run tool to automatically select a compatible runtime at install time

4. keep things as they are

Thank you so much @danwood76! I just edited the version variable in the PKGBUILD pkgver=6.20 and ran makepkg -si --skipinteg since I could not find the md5sums for this version in the pkg archive and this worked for me!

Pickit 3 support has been removed in this version: https://www.microchip.com/en-us/about/media-center/blog/2024/discontinued-ide-support-for-gen3-tools

My pickit3 isn't being detected.

running the script at /opt/microchip/mplabx/v6.25/mplab_platform/bin/mdb.sh with the following command shows this output:

>hwtool supported
May 28, 2025 8:33:25 PM com.microchip.mplab.mdbcore.platformtool.PlatformToolMetaManager init
INFO: Could not read file: MultiFileObject@28f3b248[Embedded/PlatformTool/seggerjlink]
May 28, 2025 8:33:25 PM com.microchip.mplab.mdbcore.platformtool.PlatformToolMetaManager init
INFO: Could not read file: MultiFileObject@57d7f8ca[Embedded/PlatformTool/segger-samice]
List of supported tooltype:
licensedprogrammer  (for Licensed Debugger)
icd4    (for ICD 4)
mchv    (for MCHV)
microstick  (for MICROSTICK)
skde33audio (for SKDE 33 AUDIO)
skdememory  (for SKDE Memory)
skdepic18fj (for SKDE PIC18FJ)
skdepic24f1 (for SKDE PIC24F 1)
skdepic24hsensor    (for SKDE PIC24H SENSOR)
skdepic32   (for SKDE PIC32)
icd5    (for ICD 5)
atmelice    (for Atmel-ICE)
edbg    (for EDBG)
medbg   (for mEDBG)
pkobnano    (for PKOB nano)
powerdebugger   (for Power Debugger)
jtagice3    (for JTAGICE3)
db32    (for DB32)
db32    (for DB32)
db32    (for DB32)
j32 (for J-32)
jlink   (for J-Link)
seggersamice    (for SEGGER SAM-ICE)
pickit5 (for PICkit 5)
pickit4 (for PICkit 4)
pkob4   (for Curiosity/Starter Kits (PKOB4))
sim (for Simulator)
pm3 (for PM3)
ice4    (for ICE 4)
snap    (for Snap)
pickitbasic (for PICkit Basic)

I tried the fixes mentioned for the java8-openjfx package, but no luck.

I really just want the udev rules from mplab so I can use the pickit4. Once I have them I thought about creating a package for just the udev rules.

@opamp22

That is an issue with the java8-openjfx package not this one, check the comments on that package and you will find your answers.

But yes java8-openjfx is a pain to build, maybe a binary version of that package needs to be created.

One thing I have been playing with recently is the VS code plugins from microchip, seem to be pretty good for simple projects.

java8-openjfx is causing problems.

CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:233 (message): Could NOT find Threads (missing: Threads_FOUND) Call Stack (most recent call first): /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake/Modules/FindThreads.cmake:226 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) Source/cmake/OptionsJava.cmake:38 (find_package) Source/cmake/WebKitCommon.cmake:61 (include) CMakeLists.txt:147 (include)

-- Configuring incomplete, errors occurred!

Task :web:compileNativeLinux FAILED

FAILURE: Build failed with an exception.

• Where: Build file '/home/$USER/.cache/yay/java8-openjfx/src/rt-8u202-ga/build.gradle' line: 2583

• What went wrong: Execution failed for task ':web:compileNativeLinux'.

  Process 'command 'perl'' finished with non-zero exit value 1

@phippu that's an issue with the java8-openjfx package

The link https://hg.openjdk.java.net/openjfx/8u-dev/rt/archive/${pkgver//./}-ga.tar.bz2 does return a corrupted archive for me.

The *.tar.gz variant seems to be still intact. I suggest to change this