I came to this forum to report the very same issue. I definitely disagree with the statement that hanging is normal for any software, Java software included. The issue with Java software tends to be that it is often times an Enterprise software. Enterprise software tends to be done for deadlines, not quality. Due to historic reasons the Java tends to be the technology for creating Enterprise software, which might explain the impression that all Java software is of low quality and has problems. Another aspect with anything with the word “Enterprise” in it is that unlike freelancers and home users and small businesses, the Enterprises have a lot of money to waste and fast delivery is more important than efficient use of money. Optimized, efficient, software takes longer to develop, so it makes sense to leave things unoptimized and just buy a lot of hardware that has a lot of CPU-power and RAM. That may also explain the typical “good” software development practice of first writing really low quality, crappy, software and then later trying to gradually turn shit into gold by trying to rewrite parts of software with dirty-hackish-flawed-architecture and then hope to fix the speed and RAM and other resource consumption issues like that, in stead of taking far longer to deliver the very first version, but then deliver a version that is reasonably optimized from the very start. Well, Enterprises have a lot of money to burn and the software companies that do that kind of contract work certainly do not complain about a situation, where a client is offering a lot of money for an additional project.
I find the YaCy project to be a very inspirational and from functionality point of view a step in the right direction. However, my observations are that the GUI problems seem to start after the YaCy instance has indexed some pages and the GUI problems seem to not occur, if the YaCy instance Java VM has a lot of RAM allocated to it. In my case, 600MiB of JVM allocated RAM will run without the GUI, but about 1.2GiB will kind of work. I also noticed that the original authors of the YaCy project seem to run a consultancy business, where they use the YaCy as their core technology. That may explain, why they might not test the YaCy with lower RAM consumption scenarios. After all, businesses have the money to just buy computers with a lot of RAM and speed and comfort has higher priority than RAM consumption. Unfortunately the business use case differs substantially from the hactivist use case. In my opinion it is perfectly OK for a P2P-search engine to crawl with the speed of 1 HTML-page per 5s or even 10s and have a ~5GiB index on an USB-stick that is connected to a 1-core, 700MHz Raspberry_Pi with 512MiB of RAM and an USB storage read/write speed of about 1MB/s. It seems to me that the YaCy is totally unoptimized for that kind of a use case.
I mean, think of the 512MiB RAM and 700MHz single CPU core as something that is far more powerful than desktop computers were at the late 90-ties. Even if the Java VM takes about 200MiB and needs some warm-up, then it should be possible to run a pretty decent P2P-node on such a machine, provided that it is running in a server mode, id est the GUI/X11 of the Raspberry_Pi has been switched off, not started. With an exception of video files and sound files, a well crafted company web page with proper static pages with may be a JavaScript based menu and none of the nonsense JavaScript framework bloat is about 300MiB, most of it photos. If one Raspberry_Pi indexes just a few of such pages, may be the home page of a small business owner, then those Raspberry_Pi-s can already offer a lot of data to the P2P-search-engine-network. Given that people tend to have old Android phones that they do not use and that have at least 256MiB of RAM, may be at some point the old Android phones might just lay next to home WiFi router and run a small P2P-search-engine node. Basically “free” hardware that consumes relatively little electrical power and has greater computational power than 90-ties desktop computers. The Android phones might be used only as servers, id est there is no need to create an elaborate native mobile app GUI for them. A very primitive GUI for setting up administrator username and password and port number(s) might do.
I remember that one of texts at the YaCy command line console kindly asked for feedback, how the YaCy could be updated to make it fit better with the end user use case. I’m not sure that it makes sense to start re-writing the current YaCy implementation, but it certainly makes a lot of sense to CREATE AN API THAT CAN BE USED BY OTHER P2P-search-engines so that different P2P-search engines can use the same P2P-seach-engine-network and YaCy could also use the indexes of those other P2P-search-engines.
The idea of defining a common P2P-interface for different P2P-software projects is not new. For example, there are multiple BitTorrent clients that all use the same protocol and therefore can exchange files, despite being written in different programming languages. A concrete example is also the Fediverse of P2P-social network software, where different P2P-social-network applications support multiple P2P-social-networking-protocols and form a common, huge, network. The details of that might be found from
So, all in all, I think that the YaCy is IDEOLOGICALLY a very nice project, but its implementation is absolutely ill-suited for non-enterprise use cases. But, it’s a nice first step and if it is possible to agree on a P2P-protocol, then things can start moving
Thank You for reading my comment.