Etapa 3 Realização das Transformações Sugeridas

Nesta etapa foram realizadas as transformações das estruturas de dados recomendadas pela CECOTOOL. As transformações foram realizadas manualmente, embora não seja difícil construir uma ferramenta para automatizá-las. A Tabela 4.3 apresenta o resumo das trans- formações realizadas no Xalan. Foram realizadas 23 transformações para o Ambiente1 e 10 transformações para o Ambiente2. Para realizar as 23 transformações no Ambiente1, foram alteradas 67 linhas de código. Enquanto para realizar as 10 transformações no Ambiente2, foram alteradas 11 linhas de código. Essa diferença deve-se ao fato que no Ambiente1 foram realizadas mais transformações, dentre elas Vector ⇒synchronizedList que, além de trocar o tipo da variável, necessitam de trocas entre os métodos equivalentes. Já para o Ambi- ente2, todas as transformações foram Hashtable ⇒ ConcurrentHashMap que, em geral, as trocas ocorreram apenas no tipo das variáveis. Além disso, para o Ambiente1, todas as 13 transformações de Vector ⇒synchronizedList foram realizadas com sucesso, assim como 10 transformações Hashtable ⇒ ConcurrentHashMap para ambos os ambientes. A linha da tabela Vector ⇒ Vector significa que o tipo recomendado para aquela variável é Vector, porém como ela originalmente já é implementada com o tipo Vector, então nenhuma transformação foi realizada de fato.

Para o Xalan percebe-se que, apesar das recomendações para substituição dos tipos de algumas variáveis de Vector para CopyOnWriteArrayList, optou-se por não realizar as transformações. Como mostrado no trabalho de Pinto et al. (2016), a coleção CopyOnWrite- ArrayListapenas deve ser usada em cenários onde leituras sejam muito mais frequentes que inserções. Além disso, ao executar os bechmarks para identificar os perfis de consumo de energia nos ambientes deste trabalho, pôde-se confirmar o grande consumo de energia da coleção ao realizar inserções. Portanto, mesmo que exista a recomendação para o uso de CopyOnWrite- ArrayList, essa troca deve ser avaliada pelo desenvolvedor. Dessa forma, antes de realizar as trocas, foi verificado que muitas das recomendações foram feitas devido ao fato que a variável referenciava outras variáveis que realizavam inserções e que foi recomendo que os tipos dessas últimas não fossem trocados para CopyOnWriteArrayList. Logo, as transformações não foram realizadas. Esse problema pode ser detectado através de uma análise estática de definição- uso mais sofisticada e não é uma limitação inerente à abordagem proposta e sim da análise estática implementada. A Figura 4.5 mostra um trecho de código, simplificado, que exemplifica esta situação, onde foi recomendada a substituição do tipo da variável vars do tipo Vector

4.2. RESULTADOS DOS EXPERIMENTOS 49 (linha 5) por CopyOnWriteArrayList. Entretanto, esta variável é uma referência para a variável m_variables, a qual realiza operações de inserção.

Tabela 4.3: Xalan: transformações realizadas

Ambiente1 Ambiente2

Transformação # Transformações # Não Transformações # Transformações # Não Transformações

Vector⇒ CopyOnWriteArrayList 0 11 0 11

Vector⇒ synchronizedList 13 0 0 0

Vector⇒ Vector 0 7 0 20

Hashtable⇒ ConcurrentHashMap 10 1 10 1

Total de linhas de código alteradas 67 – 11 –

1 public class TransformerImpl extends Transformer

2 {

3 public void setParameter(String name, String namespace, Object

value)

4 {

5 Vector vars = sroot.getVariablesAndParamsComposed(); 6 int i = vars.size();

7 while (--i >= 0)

8 {

9 ElemVariable variable = (ElemVariable)vars.elementAt(i);

10 }

11 }

12 } 13

14 public class StylesheetRoot extends StylesheetComposed

15 implements java.io.Serializable, Templates

16 {

17 private Vector m_variables;

18 public Vector getVariablesAndParamsComposed()

19 {

20 return m_variables;

21 }

22 void recomposeVariables(ElemVariable elemVar)

23 {

24 m_variables.addElement(elemVar);

25 }

26 }

Figura 4.5: Xalan - exemplo onde o tipo de uma variável coleção não foi modificado (para CopyOnWriteArrayList), apesar da recomendação

Outra transformação que não foi realizada foi o caso da a variável uriTable, do tipo HashTable, que não pode ser substituída para ConcurrenHashMap, pois a aplicação utiliza o método clone(). Apesar de ConcurrentHashMap herdar o método clone() da classe AbstractMap, este método não é visível externamente à classe, diferentemente do que ocorre em HashTable, que implementa a interface Cloneable e disponibiliza o método clone() para seus clientes. Dessa forma, com intuito de preservar o comportamento da aplicação, a

4.2. RESULTADOS DOS EXPERIMENTOS 50 transformação não foi realizada.

Similarmente, ao substituir Vector por synchronizedList, fez-se necessário substituir os métodos específicos da coleção Vector pelos métodos equivalentes da interface List, de acordo com a documentação Java. Apesar de implementar List, a implementação Vectorpossui métodos específicos, entretanto equivalentes com os da interface List. Por exemplo, o método addElement é específico de Vector, porém este método é equivalente ao método add da interface List. A Tabela 4.4 mostra todas as equivalências entre os métodos que foram necessárias para as substituições.

Tabela 4.4: Equivalência entres os métodos de Vector e List

Método de Vector Equivalência em List

addElement(E obj) add(E e)

elementAt(int index) get(int index)

setElementAt(E obj, int index) set(int index,E element)

removeAllElements() clear()

Tabela 4.5: Tomcat: transformações realizadas

Ambiente1 Ambiente2

Transformação # Transformações # Não Transformações # Transformações # Não Transformações

Vector⇒ synchronizedList 1 1 0 0

Vector⇒ Vector 0 3 0 5

Hashtable⇒ ConcurrentHashMap 20 2 20 2

Total de linhas de código alteradas 28 – 24 –

A Tabela 4.5 apresenta o resumo das transformações para o Tomcat. Para o Tomcat foram realizadas 21 transformações para o Ambiente1 e 20 para o Ambiente2. Das 21 transformações do Ambiente1, 20 foram Hashtable ⇒ ConcurrentHashMap e 1 transformação Vector ⇒ synchronizedList. Para realizar as 21 transformações no Ambiente1, foram alteradas 28 linhas de código. Enquanto para realizar as 20 transformações no Ambiente2, foram alteradas 24 linhas de código. Além disso, para o Ambiente2, todas as transformações foram Hashtable ⇒ ConcurrentHashMap. As transformações em geral foram simples e diretas, trocando apenas o tipo da variável e suas referências. No entanto, ocorreram dois casos em que não foram realizadas as transformações das variáveis de Hashtable para ConcurrentHashMap. No primeiro caso, a variável staticProp do tipo Hashtable é um parâmetro de um método, po- rém esse método de fato espera uma variável que implementa a classe Properties que herda de Hashtable. Por isso decidiu-se também por não fazer a transformação. No segundo caso, apresentado na Figura 4.6, a variável env, do tipo Hashtable, da classe NamingContext não foi transformada, pois esta classe implementa a interface javax.naming.Context. Esta interface possui o método getEnvironment(), cujo retorno é um objeto do tipo Hash- tablee a implementação deste método pela classe NamingContext retorna justamente a variável env.

4.2. RESULTADOS DOS EXPERIMENTOS 51

1 public class NamingContext implements Context {

2 protected Hashtable env;

3 public Hashtable getEnvironment()

4 throws NamingException {

5 return env;

6 }

7 }

Figura 4.6: Tomcat - exemplo de não transformação para ConcurrentHashMap

para synchronizedList no Ambiente1. Esta variável é referência de outras variáveis cuja recomendação foi continuar utilizando Vector. Assim também não foi transformada.

4.2.4 Etapa 4 - Execução e Medição das versões (Original e Transformada) nos Ambien-