Nothing against a "simple" joiner that forces users to catch or rule out a DelimiterCollisionException, and realise that simple is not good enough. Everything against a stupid joiner that silently assists users in creating bugs.
"Seems to work" means not tested thoroughly. People will be tempted into using this joiner to write csv files, and of course it will break as soon as a comma or semicolon delimiter turns up in a text field. They will use it to put br line break elements into HTML files, without checking for HTML syntax characters in each line. They will use it to separate SQL column values with commas, instead of binding them, or calling mysql_real_escape_string, which is a pain to use because it needs a database connection at runtime to find out exactly which characters need escaping depending on which SQL mode is configured. By all means use a "proper structured format", so long as the delimiting is properly specified and the parser and generator are fully tested. That might well be the case for JSON and XML, but it typically is not for CSV and HTML or properties files. Just because other languages may happen to have something similar does not automatically make it easy to use safely. The current behaviour encourages SQL injection. How hard is that to understand? There are some very good features coming in this release, but this joiner is not one of them; it is actually dangerous. -- View this message in context: http://openjdk.5641.n7.nabble.com/RFR-String-join-StringJoiner-additions-tp127375p145058.html Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com.
