support multiple etag values in `no-tile-header`

[bastiK]

Currently, the following does not work:

<entry>
    <name>Mapbox Satellite</name>
    ...
    <no-tile-header name="ETag" value="&quot;067736a547cafe90014b4e59b6510abe&quot;" />
    <no-tile-header name="ETag" value="&quot;ee1f6802b0234046b553cbbc672ac7d9&quot;" />
    <no-tile-header name="ETag" value="&quot;9f5a2f1d7cc131e58befc2052c71c827&quot;" />
</entry>

It only respects the last entry.

(As a workaround one can use regexp, e.g.

    <no-tile-header name='ETag' value='"067736a547cafe90014b4e59b6510abe"|"ee1f6802b0234046b553cbbc672ac7d9"|"9f5a2f1d7cc131e58befc2052c71c827"' />

)

Build-Date:2016-01-24 13:27:02
Revision:9576
Is-Local-Build:true

Identification: JOSM/1.5 (9576 SVN en) Linux Ubuntu 14.04.3 LTS
Memory Usage: 614 MB / 1764 MB (344 MB allocated, but free)
Java version: 1.8.0_45-b14, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM

[stoecker]

See #12425.

[stoecker]

In 9613/josm:

fix #12437 - see #12425 - fix handling of equal no tile headers with different values - hope the related josm config change does not break anything

[stoecker]

Preferences saving needs to be fixed.

[stoecker]

In 9617/josm:

see #12437 - support new Map<String, List<String>> type in preferences

[stoecker]

Now only conversion of old preferences is needed. But as this setting is anyway overwritten with the Maps stuff maybe that's unnecessary?

[wiktorn]

In 9619/josm:

Finish removal of tile-size workaround code started in [9617].

Now WMTS TileSources with other than 256px tile size should work properly.
See #12437, #12186

Fix name of "valid-georeference", so it will be properly loaded from preferences

[stoecker]

Seems nobody complains :-)

[wiktorn]

Please check #12474

[simon04]

In 9713/josm:

see #12437 see #12474 - Add (failing) unit tests

[simon04]

What about using MultiMap<String, String> instead of Map<String, List<String>> (→r9617)?

[stoecker]

Ah I overlooked that we have our own implementation. Yes. Why not.

I'd leave the Prefs implementation of Map<String, List<String>>, as it does no harm.

Is MultiMap correctly handled in prefs?

[bastiK]

I would stick to Map<String, List<String>> as it uses only standard collections and does the same job as MultiMap.

[simon04]

The problem with supporting Map<String, String> as well as Map<String, List<String>> are unchecked assignments as demonstrated with testDeserializeStructTicket12474 in r9713. The shape of the string (in the preference XML file) determines the type in Java which leads to #12474/ClassCastException w/o any compiler error/warning.

[stoecker]

Replying to simon04:

The problem with supporting Map<String, String> as well as Map<String, List<String>> are unchecked assignments as demonstrated with testDeserializeStructTicket12474 in r9713. The shape of the string (in the preference XML file) determines the type in Java which leads to #12474/ClassCastException w/o any compiler error/warning.

That's only an issue when like here the preferences are changed and not updated as I left out the rewriting of existing prefs. Simple solution is to add a rewrite of the old entry in our preferences update section. But I'm still not sure how the two reports managed to get into that state, as the wrong entry normally gets immediately overwritten with a new correct one from the maps file.

You failing test simply says: Our deserializer isn't stable against JSON not matching the expectations. That's independent from the question what structure we use.

[stoecker]

I fixed the prefs, but not your failing test.

[bastiK]

Replying to simon04:

The problem with supporting Map<String, String> as well as Map<String, List<String>> are unchecked assignments as demonstrated with testDeserializeStructTicket12474 in r9713. The shape of the string (in the preference XML file) determines the type in Java which leads to #12474/ClassCastException w/o any compiler error/warning.

You are right, this doesn't work. It is kind of funny, we cannot even catch this kind of error proactively. Instead it will blow up somewhere in the calling code like a parcel bomb. This can be easily avoided by switching to MultiMap (or any other class != Map).

Type erasure is really one of the worst things in Java...

[bastiK]

In 9755/josm:

add preference type MultiMap (closes #12437)

[bastiK]

see [o32051]

[bastiK]

In 9756/josm:

fix test (see #12437)