...

Proposed Changes

We would like to add 2 one new APIs API to support window store as underlying storage option for windowed topic.

public synchronized <K, V> KTable<Windowed<K>, V> windowedTable(final String topic, final Materialized<K, V, WindowStore<Bytes, byte[]>> materialized);
public synchronized <K, V> KTable<Windowed<K>, V> windowedTable(final String topic, final Consumed<Windowed<K>, V> consumed, final Materialized<K, V, WindowStore<Bytes, byte[]>> materialized);

...

We don't support windowedTable function without `materialized` or `consumed`.

The reason to keep `materialized` is that the window store requires a concrete retention time, window size and number of rolling segments to construct. On the application side Stream job could not infer the windowed topic retention or window size, so these are required information from the user. 

The reason to keep `consumed` is that in the table() API, the reason we could omit `consumed` or `materialized` is that they could share the `keySerde` and `valueSerde` during state store and node construction. This in the windowed table context, however, is not true, since we are using both windowed keySerde and raw keySerde at the same time. So both structs are required.

Compatibility, Deprecation, and Migration Plan

...