[X] My Assistant

Awesome. Thank you for doing this!

Is there any problem if I use a newer java version? The wiki said java version must be 8-11.

I want to try jdk18 on one of my box but don't want to have multiple java installations.

I have tried running one of client on j18 and it doesn't complain. But I'm not sure if it silently impedes any of the client's functionality.

This post has been edited by rozos: Apr 1 2022, 14:42

Is there any problem if I use a newer java version? The wiki said java version must be 8-11.

I want to try jdk18 on one of my box but don't want to have multiple java installations.

I have tried running one of client on j18 and it doesn't complain. But I'm not sure if it silently impedes any of the client's functionality.

If it runs, it's probably fine. I just haven't tested it against newer Java versions.

For the record, I've been using jdk-13.0.1, and while I got a few crashes apparently from java itself crashing, after 2 years of use, I'm probably below 10 of such crashes (maybe even below 5, but less sure, could even be exactly 5).
Not sure if someone both use a version not tested AND count accurately the number of crashes, and has been doing so for much longer to the point of being able to provide stats (IMG:[invalid] style_emoticons/default/tongue.gif)

24 hours on, no unexpected behavior. Should be fine long term as well.

While I'm at it, I should try running the client on Graalvm EE in my other box later.
Less java version to install is always better.

minute ?

Tried building Graalvm native image for possibility of running the client without jvm. But the builder doesn't like the jar too much, and only produces executables that still relies on jdk to execute

CODE

[user@localhost]$ native-image -jar HentaiAtHome.jar hath-native
========================================================================================================================
GraalVM Native Image: Generating 'hath-native'...
========================================================================================================================
[1/7] Initializing...                                                                                    (4.9s @ 0.24GB)
Version info: 'GraalVM 22.0.0.2 Java 17 EE'
[2/7] Performing analysis...  [***********]                                                             (33.1s @ 2.47GB)
   5,461 (90.61%) of  6,027 classes reachable
   7,446 (61.25%) of 12,156 fields reachable
  25,364 (79.43%) of 31,931 methods reachable
     350 classes,    96 fields, and   755 methods registered for reflection
      62 classes,    68 fields, and    54 methods registered for JNI access
[3/7] Building universe...                                                                               (2.0s @ 2.79GB)

Warning: Serialization method java.io.ObjectOutputStream.writeObject invoked at hath.base.CacheHandler.writeCacheObject(CacheHandler.java:266)
Warning: Aborting stand-alone image build due to serialization use without configuration.
Warning: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
------------------------------------------------------------------------------------------------------------------------
                        2.6s (6.4% of total time) in 17 GCs | Peak RSS: 3.38GB | CPU load: 3.63
------------------------------------------------------------------------------------------------------------------------
Produced artifacts:
/home/opc/test/hath-native.build_artifacts.txt
========================================================================================================================
Failed generating 'hath-native' after 40.4s.
========================================================================================================================
GraalVM Native Image: Generating 'hath-native'...
========================================================================================================================
[1/7] Initializing...                                                                                    (4.7s @ 0.25GB)
Version info: 'GraalVM 22.0.0.2 Java 17 EE'
[2/7] Performing analysis...  [******]                                                                   (8.6s @ 0.29GB)
   1,989 (75.80%) of  2,624 classes reachable
   1,935 (54.10%) of  3,577 fields reachable
   7,995 (66.01%) of 12,112 methods reachable
      21 classes,     0 fields, and   166 methods registered for reflection
      49 classes,    34 fields, and    47 methods registered for JNI access
[3/7] Building universe...                                                                               (0.7s @ 0.39GB)
[4/7] Parsing methods...      [*]                                                                        (0.8s @ 0.59GB)
[5/7] Inlining methods...     [****]                                                                     (1.2s @ 1.00GB)
[6/7] Compiling methods...    [****]                                                                    (17.8s @ 1.76GB)
[7/7] Creating image...                                                                                  (1.0s @ 1.93GB)
   3.16MB (42.56%) for code area:    3,896 compilation units
   3.65MB (49.16%) for image heap:   1,076 classes and 43,269 objects
629.69KB ( 8.29%) for other data
   7.42MB in total
------------------------------------------------------------------------------------------------------------------------
Top 10 packages in code area:                               Top 10 object types in image heap:
423.28KB java.lang                                          951.07KB byte[] for general heap data
297.91KB java.util                                          340.25KB byte[] for java.lang.String
248.96KB java.util.regex                                    278.55KB java.lang.Class
191.96KB com.oracle.svm.jni                                 261.52KB java.lang.String
130.64KB com.oracle.svm.core.reflect                        141.42KB char[]
124.66KB java.util.concurrent                                96.91KB java.util.HashMap$Node
107.26KB java.math                                           85.31KB java.util.HashMap$Node[]
105.68KB com.oracle.svm.core.genscavenge                     50.58KB byte[] for method metadata
  97.87KB java.util.stream                                    49.98KB int[]
  87.93KB com.oracle.svm.jni.functions                        42.98KB java.util.LinkedHashMap
      ... 93 additional packages                                  ... 536 additional object types
                                           (use GraalVM Dashboard to see all)
------------------------------------------------------------------------------------------------------------------------
                        0.8s (2.1% of total time) in 17 GCs | Peak RSS: 3.22GB | CPU load: 3.72
------------------------------------------------------------------------------------------------------------------------
Produced artifacts:
/home/opc/test/hath-native (executable)
/home/opc/test/hath-native.build_artifacts.txt
========================================================================================================================
Finished generating 'hath-native' in 35.9s.
Warning: Image 'hath-native' is a fallback image that requires a JDK for execution (use --no-fallback to suppress fallback image generation and to print more detailed information why a fallback image was necessary).

CODE

Warning: Serialization method java.io.ObjectOutputStream.writeObject invoked at hath.base.CacheHandler.writeCacheObject(CacheHandler.java:266)
Warning: Aborting stand-alone image build due to serialization use without configuration.

Im not java people, is there any way to get around this warning (thus produce proper native image)?

--------

Update:
passing --report-unsupported-elements-at-runtime parameter lets the independent native image build anyway. The client runs natively and initializes without any error so far, but I still have a bad feeling about this.
However the result already looks good, with native binary runs with lower overhead at avg 70mb memory and half cpu time after 10 minutes running. compared to 130mb with jar; despite the native client having slightly higher static range and load.

jvm
(IMG:[i.imgur.com] https://i.imgur.com/wLLF8pl.png)
native
(IMG:[i.imgur.com] https://i.imgur.com/8VPsMIU.png)

This post has been edited by rozos: Apr 11 2022, 03:47

Recently I got some conditions (VPN?Streaming?Tablet?Windows Scaling?Incompatible resolutions?) that cause H@H taskbar icon to fade out until becoming nearly invisible.
At that time, I realized another icon was also affected (but it got blurred instead of faded), of a program called Sandboxie Plus, which isn't made in Java, but is open source.

I'm not mentioning this directly for Tenboro, but for anybody possibly having time to try and figure what H@H and this program could have in common or similar that lead them to draw their taskbar icon in a distorted way.

I think the only other open source program displaying an icon in the taskbar, and that doesn't seem affected by a similar issue (though there's always the possibility of it because any change is just "less visible" on it?), is Open Hardware Monitor (not in Java either).

H@H doesn't draw the taskbar icon, that is fully handled by Java. So if it looks blurry, it's probably whatever version of Java not properly handling whatever resolution/DPI scaling/whatever combination you have.

Those recent version talks made me think of running a search, and I found something:
[bugs.openjdk.java.net] https://bugs.openjdk.java.net/browse/JDK-8255439 (it was a pain to load, hopefully it's the legit site (IMG:[invalid] style_emoticons/default/mellow.gif) )

Good news is it was updated 2 days ago after almost 10 months and the comment said it's a WIP, so it should be fixed eventually.
Bad news is that it's not fixed yet, and confirmed on versions up to 19 (while I'm still on 13 lol, that's why I thought on running a search in the first place).

I guess it's good to keep an eye on this (IMG:[invalid] style_emoticons/default/lurk.gif)

Not affected by Spring4Shell right?

Not affected by Spring4Shell right?

H@H doesn't use any 3rd party libraries, so no.

How can I change the h@h status clients page time to my local time?

it displays UTC standard time right now, is there something I need to set in client?

I am running 1.61 on docker.

Hi tenboro, are there plans to add support for IPv6?

Due to Chinese policy, the use of IPv4 addresses on domestic home bandwidth has become extremely difficult to implement.

At present, the dual-stack technology used by ISPs allocates IPv4 addresses as NAT private network addresses, and IPv6 addresses as public network addresses.

If you want to continue to use IPv4 public network addresses, you need to file with the local public security bureau and communications bureau, and pay 6,000 RMB for a annual (about $1000) fee.

This policy doesn't look like it will get better in the foreseeable future, so I came to the forum to ask if you have any ideas for adding support for IPv6.

Thank you for everything you do to the community and wish you all the best

How can I change the h@h status clients page time to my local time?

it displays UTC standard time right now, is there something I need to set in client?

It's hardcoded to use UTC so you would have to change it in the code.

Hi tenboro, are there plans to add support for IPv6?

It's not really feasible to run any kind of server on IPv6-only in the foreseeable future, since IPv6 support is still spotty at best.

It's hardcoded to use UTC so you would have to change it in the code.

Thx, I thought I could simply set the time zone in client or my account page, like the some forum display times.

It's not really feasible to run any kind of server on IPv6-only in the foreseeable future, since IPv6 support is still spotty at best.

(IMG:[invalid] style_emoticons/default/sad.gif) ok, thanks for your answer, hope it gets better one day

I have recently upgraded to Gigabit Internet. I increased my upload speed limit from 4 MB to 40 MB. I see the speed test shows 36 MB, but the hitrate/min and Hath/day didn't really change much. Is this expected to go up eventually? I have 1000 trust and over 9000 quality. There is 2680ish static ranges.

Interesting (IMG:[invalid] style_emoticons/default/tongue.gif)

thanks for the update

It seems like my client is stuck at 54 range for about 2 months now despite it should be able to have more. It's set to have 180gb cache size, the max burst speed set at 200,000kbps, maybe it is too high? I see that for some people their Max Speed shows 88000 only. I set it to 100,000kbps and now the Max Speed is showing 80,000 instead.

[i.imgur.com] https://i.imgur.com/tkQqTgY.png

Before I had to do a reset back in November, 2021 my cache increased at an average of about 3KB/s.

Now, even though I've had three times the speed since January, 2022 and its stored on a pair of SSDs my cache won't generally show an average rate of more than about 0.9KB/s. I can understand slow growth when the client is absolutely brand new... but it's been over six months.