[lang][collections] SortedProperties

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[lang][collections] SortedProperties

garydgregory
Hi,

I'd to have a new class called SortedProperties that extends
java.util.Properties.

Should that go in [lang] or [collections]?

I first thought [lang], but it _is_ a collection after all.

Gary
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

Amey Jadiye
My opinion is this should go to *lang* because the fact is it's extended
utility and not exactly as data structures though it looks like one. It's
main purpose is to hold properties and not the data.  Commons collection
aims to provide utlilities and extension to data structures and not to
properties  related utilities. Properties is very basic thing no matter
it's sorted or not sorted and should go to lang.

Regards,
Amey

On Tue, Jul 18, 2017, 11:58 AM Gary Gregory <[hidden email]> wrote:

> Hi,
>
> I'd to have a new class called SortedProperties that extends
> java.util.Properties.
>
> Should that go in [lang] or [collections]?
>
> I first thought [lang], but it _is_ a collection after all.
>
> Gary
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

Javen O'Neal
+1 for Lang.

There aren't any persistent data structures in Collections, nor would I
think to look in Collections to find one.

Properties is a persistent hashtable. SortedProperties is a persistent
TreeMap.

Unless you're thinking about a new family of SortedProperties. Were you
thinking about letting the user provide the Map implementation and the
SortedProperties would handle the persistence?
For example, if I wanted to persist a MultiValuedMap or a BidiMap, could I
do that?
new PersistentMap<MultiValuedMap<K, V>>();
new PersistentMap<CaseInsensitiveKeyedMap<String, Object>>();
Is there a real scenario where this would be needed?

On Jul 18, 2017 00:19, "Amey Jadiye" <[hidden email]> wrote:

> My opinion is this should go to *lang* because the fact is it's extended
> utility and not exactly as data structures though it looks like one. It's
> main purpose is to hold properties and not the data.  Commons collection
> aims to provide utlilities and extension to data structures and not to
> properties  related utilities. Properties is very basic thing no matter
> it's sorted or not sorted and should go to lang.
>
> Regards,
> Amey
>
> On Tue, Jul 18, 2017, 11:58 AM Gary Gregory <[hidden email]>
> wrote:
>
> > Hi,
> >
> > I'd to have a new class called SortedProperties that extends
> > java.util.Properties.
> >
> > Should that go in [lang] or [collections]?
> >
> > I first thought [lang], but it _is_ a collection after all.
> >
> > Gary
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

Jörg Schaible-5
In reply to this post by garydgregory
Hi Gary,

Gary Gregory wrote:

> Hi,
>
> I'd to have a new class called SortedProperties that extends
> java.util.Properties.
>
> Should that go in [lang] or [collections]?
>
> I first thought [lang], but it _is_ a collection after all.
>
> Gary

for me it's [collections]. [collections] is like [lang] also an extension to
the Java runtime, specialized for the collection/map/array stuff of
java.util. Especially since we tried to strip [lang] down and have already
moved stuff now into more specialized components.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

Jonathan Bluett-Duncan
In reply to this post by Javen O'Neal
Javen,

Just for clarity, by persistent collections, are you talking about
_functional_ persistent collections (a la Scala, Clojure and Haskell),
_disk_-persisted collections, or some other definition of "persistent"?

Jonathan

On 18 Jul 2017 08:41, "Javen O'Neal" <[hidden email]> wrote:

+1 for Lang.

There aren't any persistent data structures in Collections, nor would I
think to look in Collections to find one.

Properties is a persistent hashtable. SortedProperties is a persistent
TreeMap.

Unless you're thinking about a new family of SortedProperties. Were you
thinking about letting the user provide the Map implementation and the
SortedProperties would handle the persistence?
For example, if I wanted to persist a MultiValuedMap or a BidiMap, could I
do that?
new PersistentMap<MultiValuedMap<K, V>>();
new PersistentMap<CaseInsensitiveKeyedMap<String, Object>>();
Is there a real scenario where this would be needed?

On Jul 18, 2017 00:19, "Amey Jadiye" <[hidden email]> wrote:

> My opinion is this should go to *lang* because the fact is it's extended
> utility and not exactly as data structures though it looks like one. It's
> main purpose is to hold properties and not the data.  Commons collection
> aims to provide utlilities and extension to data structures and not to
> properties  related utilities. Properties is very basic thing no matter
> it's sorted or not sorted and should go to lang.
>
> Regards,
> Amey
>
> On Tue, Jul 18, 2017, 11:58 AM Gary Gregory <[hidden email]>
> wrote:
>
> > Hi,
> >
> > I'd to have a new class called SortedProperties that extends
> > java.util.Properties.
> >
> > Should that go in [lang] or [collections]?
> >
> > I first thought [lang], but it _is_ a collection after all.
> >
> > Gary
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

Matt Sicker
Yeah, I was confused. Persistent collections have a meaning (e.g., see <
https://pcollections.org/> for a Java library implementation) a bit
different from persistent entities.

On 18 July 2017 at 05:18, Jonathan Bluett-Duncan <[hidden email]>
wrote:

> Javen,
>
> Just for clarity, by persistent collections, are you talking about
> _functional_ persistent collections (a la Scala, Clojure and Haskell),
> _disk_-persisted collections, or some other definition of "persistent"?
>
> Jonathan
>
> On 18 Jul 2017 08:41, "Javen O'Neal" <[hidden email]> wrote:
>
> +1 for Lang.
>
> There aren't any persistent data structures in Collections, nor would I
> think to look in Collections to find one.
>
> Properties is a persistent hashtable. SortedProperties is a persistent
> TreeMap.
>
> Unless you're thinking about a new family of SortedProperties. Were you
> thinking about letting the user provide the Map implementation and the
> SortedProperties would handle the persistence?
> For example, if I wanted to persist a MultiValuedMap or a BidiMap, could I
> do that?
> new PersistentMap<MultiValuedMap<K, V>>();
> new PersistentMap<CaseInsensitiveKeyedMap<String, Object>>();
> Is there a real scenario where this would be needed?
>
> On Jul 18, 2017 00:19, "Amey Jadiye" <[hidden email]> wrote:
>
> > My opinion is this should go to *lang* because the fact is it's extended
> > utility and not exactly as data structures though it looks like one. It's
> > main purpose is to hold properties and not the data.  Commons collection
> > aims to provide utlilities and extension to data structures and not to
> > properties  related utilities. Properties is very basic thing no matter
> > it's sorted or not sorted and should go to lang.
> >
> > Regards,
> > Amey
> >
> > On Tue, Jul 18, 2017, 11:58 AM Gary Gregory <[hidden email]>
> > wrote:
> >
> > > Hi,
> > >
> > > I'd to have a new class called SortedProperties that extends
> > > java.util.Properties.
> > >
> > > Should that go in [lang] or [collections]?
> > >
> > > I first thought [lang], but it _is_ a collection after all.
> > >
> > > Gary
> > >
> >
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

garydgregory
In reply to this post by Javen O'Neal
My use case is to write a Properties object in sorted key order, nothing
fancy. The simplest way is to subclass Properties and override keys().

Loading a SortedProperties with a Map is not on my to-do list.

Gary

On Jul 18, 2017 00:41, "Javen O'Neal" <[hidden email]> wrote:

> +1 for Lang.
>
> There aren't any persistent data structures in Collections, nor would I
> think to look in Collections to find one.
>
> Properties is a persistent hashtable. SortedProperties is a persistent
> TreeMap.
>
> Unless you're thinking about a new family of SortedProperties. Were you
> thinking about letting the user provide the Map implementation and the
> SortedProperties would handle the persistence?
> For example, if I wanted to persist a MultiValuedMap or a BidiMap, could I
> do that?
> new PersistentMap<MultiValuedMap<K, V>>();
> new PersistentMap<CaseInsensitiveKeyedMap<String, Object>>();
> Is there a real scenario where this would be needed?
>
> On Jul 18, 2017 00:19, "Amey Jadiye" <[hidden email]> wrote:
>
> > My opinion is this should go to *lang* because the fact is it's extended
> > utility and not exactly as data structures though it looks like one. It's
> > main purpose is to hold properties and not the data.  Commons collection
> > aims to provide utlilities and extension to data structures and not to
> > properties  related utilities. Properties is very basic thing no matter
> > it's sorted or not sorted and should go to lang.
> >
> > Regards,
> > Amey
> >
> > On Tue, Jul 18, 2017, 11:58 AM Gary Gregory <[hidden email]>
> > wrote:
> >
> > > Hi,
> > >
> > > I'd to have a new class called SortedProperties that extends
> > > java.util.Properties.
> > >
> > > Should that go in [lang] or [collections]?
> > >
> > > I first thought [lang], but it _is_ a collection after all.
> > >
> > > Gary
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

Simon Spero
On Jul 18, 2017 11:39 AM, "Gary Gregory" <[hidden email]> wrote:

My use case is to write a Properties object in sorted key order, nothing
fancy. The simplest way is to subclass Properties and override keys().

Loading a SortedProperties with a Map is not on my to-do list.




Would your use case be served by one or more static methods?
These methods might need as  arguments:
1) Some form of output sink
2) An instance of Map<?,?> m satisfying the conditions:
   a) every key in m is an instance of String.
   b) every value in m is an instance of String.

The constraints 2a and 2b   are required   be satisfied by any Properties
object  any time at  it is output.

(Because of the legacy derivation from Hashtable, these  conditions may be
violated at other times without an error being signaled. This also makes
the concept of a Sorted Properties instance problematic, as these
keys/values may be comparable with String.)

There might be different entry points for sorted output, and for output in
the natural order of the map (which might  be sorted).

There may need to be a specialized default comparator if parts of the keys
are to be compared in non lexicographic order (for example, if  a key
contains sequences of digits that should be compared as numbers, or if keys
are hierarchical, with components  separated by periods).

Values need to be encoded wrt the special escape format defined for
properties files.

As a separate set of functionality, a corresponding method or set of
methods could be provided to support populating a Map from an input source
containing contents formatted as specified in j.u.Properties.

So,  io with a touch of codec?

Simon
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

garydgregory
Nope. All that I want is to write a Properties object with sorted lines.
Simple as that. I do not even need to read a properties file into a
SortedProperties but we can do that as well of course.

This works:

https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/util/SortedProperties.java

Gary

On Tue, Jul 18, 2017 at 11:02 AM, Simon Spero <[hidden email]> wrote:

> On Jul 18, 2017 11:39 AM, "Gary Gregory" <[hidden email]> wrote:
>
> My use case is to write a Properties object in sorted key order, nothing
> fancy. The simplest way is to subclass Properties and override keys().
>
> Loading a SortedProperties with a Map is not on my to-do list.
>
>
>
>
> Would your use case be served by one or more static methods?
> These methods might need as  arguments:
> 1) Some form of output sink
> 2) An instance of Map<?,?> m satisfying the conditions:
>    a) every key in m is an instance of String.
>    b) every value in m is an instance of String.
>
> The constraints 2a and 2b   are required   be satisfied by any Properties
> object  any time at  it is output.
>
> (Because of the legacy derivation from Hashtable, these  conditions may be
> violated at other times without an error being signaled. This also makes
> the concept of a Sorted Properties instance problematic, as these
> keys/values may be comparable with String.)
>
> There might be different entry points for sorted output, and for output in
> the natural order of the map (which might  be sorted).
>
> There may need to be a specialized default comparator if parts of the keys
> are to be compared in non lexicographic order (for example, if  a key
> contains sequences of digits that should be compared as numbers, or if keys
> are hierarchical, with components  separated by periods).
>
> Values need to be encoded wrt the special escape format defined for
> properties files.
>
> As a separate set of functionality, a corresponding method or set of
> methods could be provided to support populating a Map from an input source
> containing contents formatted as specified in j.u.Properties.
>
> So,  io with a touch of codec?
>
> Simon
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

Rob Tompkins
In reply to this post by Jörg Schaible-5


> On Jul 18, 2017, at 4:43 AM, Jörg Schaible <[hidden email]> wrote:
>
> Hi Gary,
>
> Gary Gregory wrote:
>
>> Hi,
>>
>> I'd to have a new class called SortedProperties that extends
>> java.util.Properties.
>>
>> Should that go in [lang] or [collections]?
>>
>> I first thought [lang], but it _is_ a collection after all.
>>
>> Gary
>
> for me it's [collections]. [collections] is like [lang] also an extension to
> the Java runtime, specialized for the collection/map/array stuff of
> java.util. Especially since we tried to strip [lang] down and have already
> moved stuff now into more specialized components.

I'm stuck in the in-between here with the following thought: HashTable certainly feels like a collection of objects, but it clearly extends Dictionary and isn't in the collections family. But we are in java.util here and not in java.lang, so that feels more like it could be in collections. Plus properties are essentially a map, despite they're being implemented on top of hashtable.

-Rob

>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

Jonathan Bluett-Duncan
I would strongly discourage subclassing `Properties` and instead I'd
encourage composing it into the proposed `SortedProperties` class, as
subclassing classes which weren't designed for inheritance is risky
according to Effective Java 2nd Edition, Items 16 and 17.

So for example:
```
public final class SortedProperties {
  private final Properties properties;
  ...
  public static SortedProperties from(Properties properties,
Comparator<...> keyComparator) {
    ...
    return new SortedProperties(...);
  }
  private SortedProperties(...) { ... }
  ...
}
```

On 18 July 2017 at 19:25, Rob Tompkins <[hidden email]> wrote:

>
>
> > On Jul 18, 2017, at 4:43 AM, Jörg Schaible <joerg.schaible@bpm-inspire.
> com> wrote:
> >
> > Hi Gary,
> >
> > Gary Gregory wrote:
> >
> >> Hi,
> >>
> >> I'd to have a new class called SortedProperties that extends
> >> java.util.Properties.
> >>
> >> Should that go in [lang] or [collections]?
> >>
> >> I first thought [lang], but it _is_ a collection after all.
> >>
> >> Gary
> >
> > for me it's [collections]. [collections] is like [lang] also an
> extension to
> > the Java runtime, specialized for the collection/map/array stuff of
> > java.util. Especially since we tried to strip [lang] down and have
> already
> > moved stuff now into more specialized components.
>
> I'm stuck in the in-between here with the following thought: HashTable
> certainly feels like a collection of objects, but it clearly extends
> Dictionary and isn't in the collections family. But we are in java.util
> here and not in java.lang, so that feels more like it could be in
> collections. Plus properties are essentially a map, despite they're being
> implemented on top of hashtable.
>
> -Rob
>
> >
> > Cheers,
> > Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

garydgregory
In reply to this post by Rob Tompkins
On Tue, Jul 18, 2017 at 11:25 AM, Rob Tompkins <[hidden email]> wrote:

>
>
> > On Jul 18, 2017, at 4:43 AM, Jörg Schaible <joerg.schaible@bpm-inspire.
> com> wrote:
> >
> > Hi Gary,
> >
> > Gary Gregory wrote:
> >
> >> Hi,
> >>
> >> I'd to have a new class called SortedProperties that extends
> >> java.util.Properties.
> >>
> >> Should that go in [lang] or [collections]?
> >>
> >> I first thought [lang], but it _is_ a collection after all.
> >>
> >> Gary
> >
> > for me it's [collections]. [collections] is like [lang] also an
> extension to
> > the Java runtime, specialized for the collection/map/array stuff of
> > java.util. Especially since we tried to strip [lang] down and have
> already
> > moved stuff now into more specialized components.
>
> I'm stuck in the in-between here with the following thought: HashTable
> certainly feels like a collection of objects, but it clearly extends
> Dictionary and isn't in the collections family. But we are in java.util
> here and not in java.lang, so that feels more like it could be in
> collections. Plus properties are essentially a map, despite they're being
> implemented on top of hashtable.
>

You know what, after scanning the [lang] and [collections] code base, it
really seems better in [collections].

I'd like to propose
org.apache.commons.collections4.properties.SortedProperties.

Gary


>
> -Rob
>
> >
> > Cheers,
> > Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

Simon Spero
In reply to this post by Rob Tompkins
On Jul 18, 2017 2:25 PM, "Rob Tompkins" <[hidden email]> wrote:

I'm stuck in the in-between here with the following thought: HashTable
certainly feels like a collection of objects, but it clearly extends
Dictionary and isn't in the collections family. But we are in java.util
here and not in java.lang, so that feels more like it could be in
collections. Plus properties are essentially a map, despite they're being
implemented on top of hashtable.


HashTable<K, V> extends Dictionary<K,V> implements Map<K,V>.

Of course,  Properties extends HashTable <Object, Object> because legacy.

In jdk 9, Properties still extends HashTable.
 However, HashTable now has a magic package private constructor
"HashTable(Void)", which is used by Properties to tell HashTable to go sit
in a corner, with all fields left set to default values.

Properties now uses a ConcurrentHashMap internally, with only a few methods
remaining synchronized. Everything gets delegated to the chm.

Still full of unchecked goodness.

And a great example of  how sometimes inheritance is so useless you just
compose and delegate anyway.

Simon
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

Oliver Heger-3
In reply to this post by garydgregory


Am 18.07.2017 um 20:39 schrieb Gary Gregory:

> On Tue, Jul 18, 2017 at 11:25 AM, Rob Tompkins <[hidden email]> wrote:
>
>>
>>
>>> On Jul 18, 2017, at 4:43 AM, Jörg Schaible <joerg.schaible@bpm-inspire.
>> com> wrote:
>>>
>>> Hi Gary,
>>>
>>> Gary Gregory wrote:
>>>
>>>> Hi,
>>>>
>>>> I'd to have a new class called SortedProperties that extends
>>>> java.util.Properties.
>>>>
>>>> Should that go in [lang] or [collections]?
>>>>
>>>> I first thought [lang], but it _is_ a collection after all.
>>>>
>>>> Gary
>>>
>>> for me it's [collections]. [collections] is like [lang] also an
>> extension to
>>> the Java runtime, specialized for the collection/map/array stuff of
>>> java.util. Especially since we tried to strip [lang] down and have
>> already
>>> moved stuff now into more specialized components.
>>
>> I'm stuck in the in-between here with the following thought: HashTable
>> certainly feels like a collection of objects, but it clearly extends
>> Dictionary and isn't in the collections family. But we are in java.util
>> here and not in java.lang, so that feels more like it could be in
>> collections. Plus properties are essentially a map, despite they're being
>> implemented on top of hashtable.
>>
>
> You know what, after scanning the [lang] and [collections] code base, it
> really seems better in [collections].
>
> I'd like to propose
> org.apache.commons.collections4.properties.SortedProperties.

A heretical question: Is the use case generic enough that such a class
should be added to Commons?

Most users do not care about the order of properties. And if they do,
there might be special requirements, e.g. should the order be
case-sensitive or not, should newly added properties appear at the end
(keeping the original order), ...

Oliver

>
> Gary
>
>
>>
>> -Rob
>>
>>>
>>> Cheers,
>>> Jörg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

garydgregory
On Tue, Jul 18, 2017 at 1:16 PM, Oliver Heger <[hidden email]>
wrote:

>
>
> Am 18.07.2017 um 20:39 schrieb Gary Gregory:
> > On Tue, Jul 18, 2017 at 11:25 AM, Rob Tompkins <[hidden email]>
> wrote:
> >
> >>
> >>
> >>> On Jul 18, 2017, at 4:43 AM, Jörg Schaible <joerg.schaible@bpm-inspire.
> >> com> wrote:
> >>>
> >>> Hi Gary,
> >>>
> >>> Gary Gregory wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I'd to have a new class called SortedProperties that extends
> >>>> java.util.Properties.
> >>>>
> >>>> Should that go in [lang] or [collections]?
> >>>>
> >>>> I first thought [lang], but it _is_ a collection after all.
> >>>>
> >>>> Gary
> >>>
> >>> for me it's [collections]. [collections] is like [lang] also an
> >> extension to
> >>> the Java runtime, specialized for the collection/map/array stuff of
> >>> java.util. Especially since we tried to strip [lang] down and have
> >> already
> >>> moved stuff now into more specialized components.
> >>
> >> I'm stuck in the in-between here with the following thought: HashTable
> >> certainly feels like a collection of objects, but it clearly extends
> >> Dictionary and isn't in the collections family. But we are in java.util
> >> here and not in java.lang, so that feels more like it could be in
> >> collections. Plus properties are essentially a map, despite they're
> being
> >> implemented on top of hashtable.
> >>
> >
> > You know what, after scanning the [lang] and [collections] code base, it
> > really seems better in [collections].
> >
> > I'd like to propose
> > org.apache.commons.collections4.properties.SortedProperties.
>
> A heretical question: Is the use case generic enough that such a class
> should be added to Commons?
>
> Most users do not care about the order of properties. And if they do,
> there might be special requirements, e.g. should the order be
> case-sensitive or not, should newly added properties appear at the end
> (keeping the original order), ...
>

Valid question. Take a look at [collections] though. It is full of
variations on different kinds of collections.

Supporting some way of sorting a Properties object seems quite reasonable
in that context.

Gary


>
> Oliver
>
> >
> > Gary
> >
> >
> >>
> >> -Rob
> >>
> >>>
> >>> Cheers,
> >>> Jörg
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

garydgregory
In reply to this post by Jonathan Bluett-Duncan
On Tue, Jul 18, 2017 at 11:27 AM, Jonathan Bluett-Duncan <
[hidden email]> wrote:

> I would strongly discourage subclassing `Properties` and instead I'd
> encourage composing it into the proposed `SortedProperties` class, as
> subclassing classes which weren't designed for inheritance is risky
> according to Effective Java 2nd Edition, Items 16 and 17.
>
> So for example:
> ```
> public final class SortedProperties {
>   private final Properties properties;
>   ...
>   public static SortedProperties from(Properties properties,
> Comparator<...> keyComparator) {
>     ...
>     return new SortedProperties(...);
>   }
>   private SortedProperties(...) { ... }
>   ...
> }
> ```
>

Yes, of course, that's one way to go and also create a bunch of methods to
delegate to the wrapped Properties... BUT I cannot pass this object to a
method typed with "Properties".

Gary


> On 18 July 2017 at 19:25, Rob Tompkins <[hidden email]> wrote:
>
> >
> >
> > > On Jul 18, 2017, at 4:43 AM, Jörg Schaible <joerg.schaible@bpm-inspire.
> > com> wrote:
> > >
> > > Hi Gary,
> > >
> > > Gary Gregory wrote:
> > >
> > >> Hi,
> > >>
> > >> I'd to have a new class called SortedProperties that extends
> > >> java.util.Properties.
> > >>
> > >> Should that go in [lang] or [collections]?
> > >>
> > >> I first thought [lang], but it _is_ a collection after all.
> > >>
> > >> Gary
> > >
> > > for me it's [collections]. [collections] is like [lang] also an
> > extension to
> > > the Java runtime, specialized for the collection/map/array stuff of
> > > java.util. Especially since we tried to strip [lang] down and have
> > already
> > > moved stuff now into more specialized components.
> >
> > I'm stuck in the in-between here with the following thought: HashTable
> > certainly feels like a collection of objects, but it clearly extends
> > Dictionary and isn't in the collections family. But we are in java.util
> > here and not in java.lang, so that feels more like it could be in
> > collections. Plus properties are essentially a map, despite they're being
> > implemented on top of hashtable.
> >
> > -Rob
> >
> > >
> > > Cheers,
> > > Jörg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

Jonathan Bluett-Duncan
>
> Yes, of course, that's one way to go and also create a bunch of methods to
> delegate to the wrapped Properties... BUT I cannot pass this object to a
> method typed with "Properties".
>

Oh, that's a fair point. You've convinced me. :)

On 18 July 2017 at 23:44, Gary Gregory <[hidden email]> wrote:

> On Tue, Jul 18, 2017 at 11:27 AM, Jonathan Bluett-Duncan <
> [hidden email]> wrote:
>
> > I would strongly discourage subclassing `Properties` and instead I'd
> > encourage composing it into the proposed `SortedProperties` class, as
> > subclassing classes which weren't designed for inheritance is risky
> > according to Effective Java 2nd Edition, Items 16 and 17.
> >
> > So for example:
> > ```
> > public final class SortedProperties {
> >   private final Properties properties;
> >   ...
> >   public static SortedProperties from(Properties properties,
> > Comparator<...> keyComparator) {
> >     ...
> >     return new SortedProperties(...);
> >   }
> >   private SortedProperties(...) { ... }
> >   ...
> > }
> > ```
> >
>
> Yes, of course, that's one way to go and also create a bunch of methods to
> delegate to the wrapped Properties... BUT I cannot pass this object to a
> method typed with "Properties".
>
> Gary
>
>
> > On 18 July 2017 at 19:25, Rob Tompkins <[hidden email]> wrote:
> >
> > >
> > >
> > > > On Jul 18, 2017, at 4:43 AM, Jörg Schaible
> <joerg.schaible@bpm-inspire.
> > > com> wrote:
> > > >
> > > > Hi Gary,
> > > >
> > > > Gary Gregory wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> I'd to have a new class called SortedProperties that extends
> > > >> java.util.Properties.
> > > >>
> > > >> Should that go in [lang] or [collections]?
> > > >>
> > > >> I first thought [lang], but it _is_ a collection after all.
> > > >>
> > > >> Gary
> > > >
> > > > for me it's [collections]. [collections] is like [lang] also an
> > > extension to
> > > > the Java runtime, specialized for the collection/map/array stuff of
> > > > java.util. Especially since we tried to strip [lang] down and have
> > > already
> > > > moved stuff now into more specialized components.
> > >
> > > I'm stuck in the in-between here with the following thought: HashTable
> > > certainly feels like a collection of objects, but it clearly extends
> > > Dictionary and isn't in the collections family. But we are in java.util
> > > here and not in java.lang, so that feels more like it could be in
> > > collections. Plus properties are essentially a map, despite they're
> being
> > > implemented on top of hashtable.
> > >
> > > -Rob
> > >
> > > >
> > > > Cheers,
> > > > Jörg
> > > >
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang][collections] SortedProperties

garydgregory
I committed a simple SortedProperties class to [collections]. It's goal as
Javadoc'd is only to sort keys.

Tracking with: [COLLECTIONS-654] Add class SortedProperties to sort keys.

Gary

On Tue, Jul 18, 2017 at 3:50 PM, Jonathan Bluett-Duncan <
[hidden email]> wrote:

> >
> > Yes, of course, that's one way to go and also create a bunch of methods
> to
> > delegate to the wrapped Properties... BUT I cannot pass this object to a
> > method typed with "Properties".
> >
>
> Oh, that's a fair point. You've convinced me. :)
>
> On 18 July 2017 at 23:44, Gary Gregory <[hidden email]> wrote:
>
> > On Tue, Jul 18, 2017 at 11:27 AM, Jonathan Bluett-Duncan <
> > [hidden email]> wrote:
> >
> > > I would strongly discourage subclassing `Properties` and instead I'd
> > > encourage composing it into the proposed `SortedProperties` class, as
> > > subclassing classes which weren't designed for inheritance is risky
> > > according to Effective Java 2nd Edition, Items 16 and 17.
> > >
> > > So for example:
> > > ```
> > > public final class SortedProperties {
> > >   private final Properties properties;
> > >   ...
> > >   public static SortedProperties from(Properties properties,
> > > Comparator<...> keyComparator) {
> > >     ...
> > >     return new SortedProperties(...);
> > >   }
> > >   private SortedProperties(...) { ... }
> > >   ...
> > > }
> > > ```
> > >
> >
> > Yes, of course, that's one way to go and also create a bunch of methods
> to
> > delegate to the wrapped Properties... BUT I cannot pass this object to a
> > method typed with "Properties".
> >
> > Gary
> >
> >
> > > On 18 July 2017 at 19:25, Rob Tompkins <[hidden email]> wrote:
> > >
> > > >
> > > >
> > > > > On Jul 18, 2017, at 4:43 AM, Jörg Schaible
> > <joerg.schaible@bpm-inspire.
> > > > com> wrote:
> > > > >
> > > > > Hi Gary,
> > > > >
> > > > > Gary Gregory wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> I'd to have a new class called SortedProperties that extends
> > > > >> java.util.Properties.
> > > > >>
> > > > >> Should that go in [lang] or [collections]?
> > > > >>
> > > > >> I first thought [lang], but it _is_ a collection after all.
> > > > >>
> > > > >> Gary
> > > > >
> > > > > for me it's [collections]. [collections] is like [lang] also an
> > > > extension to
> > > > > the Java runtime, specialized for the collection/map/array stuff of
> > > > > java.util. Especially since we tried to strip [lang] down and have
> > > > already
> > > > > moved stuff now into more specialized components.
> > > >
> > > > I'm stuck in the in-between here with the following thought:
> HashTable
> > > > certainly feels like a collection of objects, but it clearly extends
> > > > Dictionary and isn't in the collections family. But we are in
> java.util
> > > > here and not in java.lang, so that feels more like it could be in
> > > > collections. Plus properties are essentially a map, despite they're
> > being
> > > > implemented on top of hashtable.
> > > >
> > > > -Rob
> > > >
> > > > >
> > > > > Cheers,
> > > > > Jörg
> > > > >
> > > > >
> > > > > ------------------------------------------------------------
> > ---------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> >
>