Search

Marcelo Lecar

Category

Java

ArrayList vs LinkedList vs Vector

Sometimes people ask me the difference between java.util.ArrayList, java.util.LinkedList and java.util.Vector.

Well, if it is important to you I will tell you the basic stuff about them:

ArrayList: It is an implementation of an array, simple as that.

LinkedList: It is an implementation of an doubly-linked list, attention, doubly-linked list, so each node is linked to the next node and linked to the previous node at the same time.

Vector: It is like an ArrayList, but it is synchronized.

So, add and remove are slower in ArrayList because it generates another array and copy values to it.

But LinkedList is slower in get and set methods, because you have to pass through the list to find the element.

 

But you can check more information about them at:

https://docs.oracle.com/javase/8/docs/api/java/util/ArrayList.html

https://docs.oracle.com/javase/8/docs/api/java/util/LinkedList.html

https://docs.oracle.com/javase/8/docs/api/java/util/Vector.html

And DZone written a post about it in https://dzone.com/articles/arraylist-vs-linkedlist-vs.

 

maven-shade-plugin e maven-jarsigner-plugin juntos

Trabalhando com os plugins:

maven-shade-plugin e maven-jarsigner-plugin

eu estava recebendo o seguinte erro ao executar o jar gerado com “maven clean install”:

java.lang.SecurityException: Invalid signature file digest for Manifest main attributes

Fiz a verificação da assinatura do jar com o seguinte comando “jarsigner -verify ” e obtive:

jar-not-signed

O motivo desse erro para mim era porque, como o maven trabalha baseado em FIFO e na configuração do meu pom, eu estava colocando o plugin do jarsigner antes do shade.

Após trocar a ordem dos plugins e executar o comando de verificação novamente eu obtive:

jar signed

voilà!

Jar assinado e agora eu agora consigo executá-lo.

java.lang.ClassNotFoundException: org.jboss.ws.core.soap.SAAJMetaFactoryImpl

Recentemente me deparei com a seguinte situação no jboss 4.2.3:

java.lang.ClassNotFoundException: org.jboss.ws.core.soap.SAAJMetaFactoryImpl

O artefato que possui a classe solicitada acima é o jbossws.sar que fica dentro da pasta deploy do jboss que havia sido removido porque a minha aplicação não dependia do jax-ws antes.

Porém não tenho interesse em restaurar esse artefato porque não pretendo mais depender das classes jax-ws do JBoss. Dependerei das classes do Spring Web Services que já possui uma implementação do javax.xml.soap.SAAJMetaFactory.

A primeira pergunta é: Quem está solicitando ao JBoss a instanciação da classe org.jboss.ws.core.soap.SAAJMetaFactoryImpl?

Dentro do artefato jboss-saaj.jar que está presente na pasta lib e lib/endorsed do JBoss existe um apontamento para essa classe no arquivo META-INF/services/javax.xml.soap.MetaFactory.

E a segunda pergunta é: Como fazer para que o JBoss deixe de procurar essa classe?

Basta remover o arquivo jboss-saaj.jar tanto da pasta lib quanto da lib/endorsed e dessa forma, no meu caso, o Spring Web Services será utilizado para carregar o meu artefato.

Maven Release: branch + Git

Há pouco tempo me deparei com uma certa dificuldade em gerar a release de um branch que eu havia criado. Isso se deve ao fato de termos mudado de SVN para Git recentemente.

A nossa linha de desenvolvimento é no trunk, reservamos as branches somente para corrigirmos bugs que aparecem em produção em versões fechadas e que não tenhamos capotado a versão seguinte ou que já tenhamos adicionado novas features que ainda não estão maduras ou testadas o suficiente de forma a garantirmos a qualidade do software.

Então, para a versão fechada, digamos 1.15, criaremos a versão de branch 1.15.0.1.1. (Descreverei em outro post esse versionamento)

Lembrando que utilizamos o Git e que sendo assim, criamos o branch a partir da tag 1.15 com o comando abaixo:

git checkout -b projeto-1.15 projeto-1.15

Está correto mesmo, criaremos o branch 1.15 para que consigamos fazer com que o maven crie uma nova branch de desenvolvimento que se chamará projeto-1.15.0.1.1 e em seus poms teremos a tag version como projeto-1.15.0.1.1-SNAPSHOT. Caso contrário vc terá de alterar todos os poms manualmente para esta versão, o que não se justifica.

Feito o checkout da versão projeto-1.15 agora é só executar o seguinte comando:

mvn release:branch -DautoVersionSubmodules=true -DbranchName=projeto-1.15.0.1.1 -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false

Feito isso, a branch projeto-1.15.0.1.1 será criada e os poms estarão com a tag version projeto-1.15.0.1.1-SNAPSHOT.

Agora é só fazer as devidas correções do bug, adicionar ao index do git, commitar no repositório e executar o comando:

mvn release:prepare

E se tudo der certo:

mvn release:perform

Caso alguma coisa dê errado, verifique o erro informado e se for necessário vc poderá executar o comando (mas lembre-se de NÃO deletar os arquivos de rollback gerados pelo mvn release:prepare, senão o passo seguinte não funcionará):

mvn release:rollback

Website Powered by WordPress.com.

Up ↑