StringJoiner: detect or fix delimiter collision?

[Remi Forax]

On 07/23/2013 11:57 PM, ph wrote:
> 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.

Java is not PHP,
data are represented by objects not Strings so escaping (if needed*) is 
done by the API not by the users.

Rémi
* sql drivers in Java often use binary protocols not textual one.