On Mon, 5 Jun 2023 09:44:31 GMT, Severin Gehwolf <sgehw...@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/yr5jvhhsucrbt...@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
