Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SLING-7752 - Deserializing and serializing a feature model file suffles the configurations #2

Closed
wants to merge 3 commits into from
Closed
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions src/main/java/org/apache/sling/feature/Configuration.java
Original file line number Diff line number Diff line change
Expand Up @@ -16,8 +16,9 @@
*/
package org.apache.sling.feature;

import org.apache.sling.feature.impl.OrderedDictionary;

import java.util.Dictionary;
import java.util.Hashtable;


/**
Expand All @@ -40,7 +41,7 @@ public class Configuration
private final String factoryPid;

/** The properties. */
private final Dictionary<String, Object> properties = new Hashtable<>();
private final Dictionary<String, Object> properties = new OrderedDictionary<>();

/**
* Create a new configuration
Expand Down
137 changes: 137 additions & 0 deletions src/main/java/org/apache/sling/feature/impl/OrderedDictionary.java
Original file line number Diff line number Diff line change
@@ -0,0 +1,137 @@
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
package org.apache.sling.feature.impl;

import java.util.*;

/**
* A dictionary implementation with predictable iteration order.
*
* Actually this class is a simple adapter from the Dictionary interface
* to a synchronized LinkedHashMap
*
* @param <K>
* @param <V>
*/
public class OrderedDictionary<K, V> extends Dictionary<K, V> implements Map<K, V> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need the Map implementation as well? In Configuration.java it is only used as a Dictionary implementation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rombert Yes, that is true, in Configuration.java it is only used as Dictionary, but I wanted to maintain backwards compatibility with all the other code that unknowingly used the implementation details of Hashtable. For example I've seen a lot of code doing things like object instance of Map and those conditions would fail.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My personal preference would be to keep it simple in the beginning and add the extra baggage only when it's needed.

private static class EnumarationImpl<E> implements Enumeration<E> {
private final Iterator<E> iterator;

public EnumarationImpl(Iterator<E> iterator) {
this.iterator = iterator;
}

@Override
public boolean hasMoreElements() {
return iterator.hasNext();
}

@Override
public E nextElement() {
return iterator.next();
}
}

private Map map = Collections.synchronizedMap(new LinkedHashMap());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a slight problem with the thread safety approach here. Collections.syncronizedMap warns that

It is imperative that the user manually synchronize on the returned map when iterating over any of its collection views (...)

We don't expose that for the user. Do we really need a Dictionary implementation or can we replace the properties object with a LinkedHashMap?

Copy link
Contributor Author

@andreituicu andreituicu Jun 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be in favour of switching to LinkedHashMap, but the baseline plugin complained that I need to bump the major version since it would change the getter API and I thought I should try like this first. Maybe @bosschaert could give his opinion too on this matter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rombert Looking at the code of SynchronizedMap, Hashtable and LinkedHashMap, it seems to me that the implementation has the same problems with the iterators as the Hashtable too, so the two implementations are equivalent in that regard, just that the Synchronized Map gives you the warning, while the Hashtable lets you figure that out for your self. I think it is the case for almost all collection implementations that Java offers. I could also add the warning to the Javadoc. Do you think we should do more than that or do you have a different recommendation?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did not see what we return it using a getter. Yes, that's a problem if changing to a LinkedHashMap, and probably @bosschaert or @cziegeler can tell us if that's a problem.

For the thread safety - I'm not sure we need it. A Hashtable is thread-safe but a Dictionary does not have to be. So IMO we could go with either a LinkedHashMap, while breaking backwards compatibility, or with a non-thread-safe Dictionary implementation backed by a LinkedHashMap.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're still at version 0.1.2 which means we didn't do a 1.0 release yet. In OSGi versions starting with 0.x.x indicate 'beta' releases and make no guarantees about backward compatibility, so I think we can apply that reasoning here too.

So I think we can still make things better without being 100% compatible.
The previous use of Dictionary is probably somehow related to the fact that in OSGi configuration properties are stored in Dictionary objects (because this spec predates Java Collections) but I think that where we need Dictionaries we can quite easily convert to them there.

So from me +1 for switching to LinkedHashMap.


@Override
public int size() {
return map.size();
}

@Override
public boolean isEmpty() {
return map.isEmpty();
}

@Override
public boolean containsKey(Object key) {
return map.containsKey(key);
}

@Override
public boolean containsValue(Object value) {
return map.containsValue(value);
}

@Override
public Enumeration<K> keys() {
return new EnumarationImpl<>(map.keySet().iterator());
}

@Override
public Enumeration<V> elements() {
return new EnumarationImpl<>(map.values().iterator());
}

@Override
public V get(Object key) {
return (V) map.get(key);
}

@Override
public V put(K key, V value) {
// Make sure the value is not null
if (value == null) {
throw new NullPointerException();
}

return (V) map.put(key, value);
}

@Override
public V remove(Object key) {
return (V) map.remove(key);
}

@Override
public void putAll(Map<? extends K, ? extends V> m) {
map.putAll(m);
}

@Override
public void clear() {
map.clear();
}

@Override
public Set<K> keySet() {
return map.entrySet();
}

@Override
public Collection<V> values() {
return map.values();
}

@Override
public Set<Entry<K, V>> entrySet() {
return map.entrySet();
}

@Override
public boolean equals(Object o) {
return map.equals(o);
}

@Override
public int hashCode() {
return map.hashCode();
}
}