RFR: 8309191: Reduce JDK dependencies of cgroup support

Aleksandar Pejovic apejovic at openjdk.org
Tue Jun 6 10:13:53 UTC 2023


On Mon, 5 Jun 2023 09:44:31 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> As far as I can tell, the delimiter hasn't changed since the file was introduced, and judging by the kernel mailing list (e.g., see [the following](https://lore.kernel.org/all/Yr5JVHhSUCrbT8OH@mtj.duckdns.org/)), I don't think it will change any time soon.
>
> I'm not convinced this is a good change. Going by that mailing list thread, it suggests that people considered changing it. If one of those attempts were successful, it would have broken this code. It makes it rather fragile. The issue, with container detection code going wrong is that you most likely never notice. Translating this to GraalVM means that the native image, would a) detect the wrong version in use or b) fail detection and use host values. In both cases the application will likely misbehave in a container setup with resource limits applied and you won't (easily) know why. So even though it's unlikely to be a problem, there is a chance it could be and it's asking for trouble for no good reason.
> 
> Therefore, being conservative about delimiters makes sense here. My choice in this case would be more robust code over relying on external factors. YMMV.

Okay, so how about something like the following, would that be more acceptable?
Suggestion:

        String[] tokens = Collections.list(new StringTokenizer(line, " \t")).toArray(new String[0]);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1219348952


More information about the core-libs-dev mailing list