i think these problems may have something to do with the dicey windows dll environment.
if i'm not wrong jssc is actually a serial driver / connector library
https://github.com/java-native/jssc
this is apparently used by processing and that java-loader is apparently written in processing.
if you are willing to go the distance i'd guess you could try to rebuild that java-loader.jar as the source code is there.
https://github.com/rogerclarkmelbourne/ ... ple_loader
but rebuilding this likely won't help.
rather, you probably would want to try using a updated release of jssc in the earlier link or literally build it from source.
the minefields are actually the windows dll interfacing the c libraries to the actual windows serial drivers dll.
this is a likely potential trouble spot that will not go away. never! whatever java distributions you are using.
the alternatives are to do that upload manually. it isn't too difficult. there are reliable tools
e.g. stm32cube programmer
https://www.st.com/en/development-tools ... eprog.html
or you can try with the updated open sourced tools like dfu-util, st-link, stm32 loader etc
http://dfu-util.sourceforge.net/
https://github.com/stlink-org/stlink
https://github.com/jsnyder/stm32loader
a main thing you may want to first try if you insist on 'integrated' flashing is perhaps to update that jssc.jar with an updated release jar.
in case anyone is looking for a release 'jssc.jar', and messing with windows sources and drivers is 'too intimidating' (it may not work even if you try), i think processing uses jssc.jar, so you may be able to find something there.
windows has various 'gotchas' such as that it may 'hog' drivers etc. those may cause other woes related to the usb-ports. e.g. if you unplug your blue pill without 'informing' windows, and your driver is after all 'hogging' that port e.g. actively using it. that driver may keep thinking that it is still connected even if the board is already disconnected. i'm not too sure if this is indeed the symptom, but accordingly such behaviors can happen in windows.
that java-loader magic is simply that it sends a DTR 1EAF command to the sketch and the sketch / core triggers a reset.
it is an old maple magic that's still there today
http://docs.leaflabs.com/static.leaflab ... oader-mode
https://github.com/rogerclarkmelbourne/ ... Bootloader
note that this 'resetting' has nothing to do with that 'old' maple/stm32duino libmaple dfu bootloader.
the resetting provides some convenience as otherwise you would just need to press that reset button manually.
after resetting it calls dfu-util in the 'good old' maple way to upload the firmware.
it is convenient but that if one runs into 'driver problems'. the 'work around' is to find alternative more reliable upload means including manually.
usb-serial (vcp) etc is a 'different thing', libmaple core offers usb-serial as a 'default' serial port, in stm core you'd need to select that.
all that 'bootloader' magic can sometimes confuse poorly configured os (windows etc) or poor hardware as it first initialize as a dfu-port, then if nothing happens, it runs the sketch firmware which initialize as a usb-serial port (re-enumerates). the old maple mini actually goes the distance and place a 'big' transistor there to do a 'no nonsense' usb reset on pressing reset. other boards try to mimic that by doing a single ended zero. rather often, some hardware didn't detect that change and u'd need to find a way to 'reset' that usb port.
oh and normally st-link jtag/swd is normally a 'no nonsense' programming solution. and you need no 'boot loader' for that.
still one may stumble on a *protected* board, accordingly only stm32cube programmer and st-link
viewtopic.php?p=6709#p6709
offers a way out of that