On Tue, 6 Jun 2023 10:10:38 GMT, Aleksandar Pejovic <apejo...@openjdk.org> wrote:
>> 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]); `StringTokenizer()` is a legacy class and is discouraged in new code. So not ideal either. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1219542380
