DEV Community: Rodrigo

JVM - Java é Verboso Mesmo? Parte V

Rodrigo — Mon, 10 Jul 2023 22:07:34 +0000

Isso aqui parece mais os filmes do Rocky Balboa...galera old school sabe do que to falando, né não? hehehe
Faaaaaala dominadores do café, tudo bem com vocês?
Sim, eu ando atribulado de coisa pra fazer, mas pra gente fechar esse ciclo e ir tocando assuntos novos, eu trouxe o artigo da vez - último da série - o qual nos fez vir até aqui destrinchando, entendendo o que é a JVM do Javinha das massas!
Foi uma série muito legal de artigos que me deixaram bem feliz de ter feito e compartilhado com vocês! <3

Perdeu algum? então segue o fio de todos os artigos desde o inicio:
Parte I
Parte II
Parte III
Parte IV

Então sem mais delongas... com vocês o motor de execução!

Pensem nele como o motor de um carro, a gasolina é o Java em bytecode, ele entra, circula pelo motor, é injetado em seus componentes. Foi construido para fazer com que o resto da carroceria possa se movimentar, você já viu como um motor funciona, não? então fica aqui uma provocação pra entender como o combustível chega lá e é gerada a energia pra que isso aconteça!

Intepretador- É nessa área que o bytecode chega e é executada uma interpretação para a linguagem nativa do SO em que a JVM está instalada. Só que a problemática dessa área é: não há nenhum tratamento do que é executado dentro do interpretador, por tanto, fatalmente o mesmo trecho de código poderá ser executado inumeras vezes, pois o interpretador vai apenas converter o que chegar até ele, gerando assim uma perda de performance.

Compilador Just In Time (JIT) - Então neste contexto foi proposto o JIT, que é a próxima área do desenho, que busca mitigar esse problema que existe no interpretador para além de manter a performance desejada, ela possa em certos casos até ser melhorada.
Em tempo de execução a JVM carrega os arquivos para a memória e é executado uma análise semântica para determinar quem melhor atende aquele trecho de código, nessa hora, pense em códigos repetidos, o JIT consegue entender que está sendo reexecutado um trecho e o mesmo não mais será jogado para o interpretador, ele ativa um conjunto de códigos nativos diretamente, sem ter que reexecutar o código no interpretador, melhorando assim o tempo no processamento do código que entra para a exeução.

Gerador de código intermediário - responsável por produzir um código intermediário no momento da execução do bytecode que precisará ser executado.
Otimizador de código - Responsável por captar o codigo acima e buscar fazer otimizações na sua execução.
Gerador de código alvo - Responsável por gerar o código fim baseado no sistema operacional onde a JVM se encontra, ou em outros termos, o código nativo.
Perfil - Responsável em buscar por pontos de possíveis execuções repetitivas para assim diminuir o trabalho da área do interpretador.

Coletor de lixo - É o responsável por retirar da memória referências que não possuem mais apontamento nenhum para o código em execução, ou seja, objetos mortos. Pode ser invocado dentro do código da seguinte maneira:

System.gc()

ps: porém essa invocação não tem garantias de que será executada pela JVM.

E por último, dentro da JMV ainda existem o JNI e o Native Method Libraries...

Interface de método nativo (JNI) - Área que fará a interface com a biblioteca de método nativo e disponibilizará para o motor de execução tudo o que precisar para que o código seja efetivamente executado.

Biblioteca de método nativo - Reside a coleção de bibliotecas nativas que são obrigatórias para o pleno funcionamento do motor de execução.

Pessoal, queria agradecer muito quem chegou até aqui! Espero ter sido de alguma maneira útil para você e se tiver alguma dúvida ou sugestão, me manda aqui num comentário ou nas redes sociais.
Um abraço fraterno e até a próxima!!

JVM - Java é Verboso Mesmo? Parte IV

Rodrigo — Tue, 14 Feb 2023 00:11:25 +0000

Fala dominadores (do Java, claro kkk)!
Sem muita delonga, vamos continuar nosso papo sobre a JVM !!! #partiu

Tivemos aqui o inicio das explicações da JVM e como ela procura trabalhar com o Java e hoje vamos dar seguimento a essa explicação.

O subsistema de área de pilha (Stack area)

Área de método (Method area)

Esta área na JVM é responsável por armazenar todos os métodos do escopo de uma classe, trazendo nosso exemplo da classe Programa, temos:

public class Programa{
    public static void main(String[] args){
        System.out.println("Hello Programa");
    }
}

O escopo de classe é tudo que está depois do colchete "{" após a palavra Programa até o fechamento deste escopo com o outro colchete ao contrário "}", então na nossa classe, podemos notar que só existe a declaração de um método, o método main. Então, na área de método, para o nosso exemplo, será disponibilizado em memória o método main, beleza?
Ah! vale lembrar que a área de método é um recurso compartilhado dentro da JVM e que só existe uma área por JVM, você não encontrará duas áreas de método dentro da mesma JVM, por tanto, fica ligado que neste exemplo, tinhamos apenas uma classe sendo enviada à JVM, um caso simples, mas há casos complexos onde a necessidade de analisar o que a JVM está recebendo é essencial pra entender se as classes estão fazendo a sua JVM trabalhar bem ou talvez um ajuste de código para otimizar o seu uso seja necessário, pois, dependemos de recursos de máquina, infraestrutura e sem um bom código infelizmente você precisará demandar muito mais poder de infra, memória, cpu, etc...

Área de empilhamento (Heap area)

Nesta área ficarão armazenados todos os objetos e suas instancias correspondentes. Importante lembrar que assim como a área anterior, a área de empilhamento (heap area) também é um recurso compartilhado que deve ser olhado com carinho, já que um código mal implementado por ocasionar estouro de pilha (que é quando não há mais espaço em memória para armazenar novos objetos, gerando exceções como java.lang.OutOfMemoryError: Java heap space)

Área de dados em tempo de execução (Stack area)

Nesta área, vamos arranhar a superfície do conceito de Threads:

Threads - São criadas em decorrência de processos computacionais, por exemplo, quando um processo dentro de um computador precisa ser executado, aí nasce a thread. Toda vez que uma aplicação é aberta, é lançada uma thread dela mesma e a cada nova tarefa daquela aplicação, outra thread poderá ser criada...logo, quanto mais aplicações abertas você têm, mais sobrecarga você coloca sobre o processamento do seu equipamento.

Então como vimos acima, cada execução cria-se uma Thread e para cada execução alocada na memória damos o nome de Stack Frame. No Stack Frame todas as variáveis locais serão inicializadas, e também dizemos que é thread-safe, pois esse recurso, diferente dos anteriores não á um recurso compartilhado, ele é exclusivo daquela execução.
Dentro do Stack Frame temos ainda três subcategorias:

Local Variable Array (LVA) - Corresponde a quantas variáveis locais estão envolvidas e seus respectivos valores serão armazenados aqui, no nosso exemplo:

Na nossa classe, por ser simples, o método main pode ser representado por uma única referencia de LVA que pode ter de 0 até n entradas quando invocado;

Operand Stack (OS) - É um recurso que entra em cena caso haja a necessidade de alguma operação intermediária para ser executada, o OS age como area de trabalho para realizar as operações demandadas. Vamos alterar um pouco nossa classe para tentar exemplificar isso:

public class Programa{
    public static void main(String[] args){
        System.out.println("Hello Programa");
        System.out.println("O resultado da soma é: " + soma(2,3));
    }

    public static int soma(int a, int b){
        return a + b;
    }

}

Vejam que para que o segundo System.out.println seja possível, é necessário invocar um novo método que chamamos de soma, essa seria uma tentativa de exemplificar quando o OS entra em ação devido a necessidade de uma operação extra!

Frame Data (FD) - O frame data é o carinha que agiliza as coisas na execução, é como se fosse um assistente de execução, ele fica de olho no pool da Stack Frame e consegue linkar as referencias de forma a agilizar aquela execução através de ponteiros de classe, interface, campos ou métodos.

PC Registradores (PC Registers)

Cada Thread terá seu próprio registrador que será responsável por armazenar o seu endereço, isso viabiliza a execução atual para ser realizada e prepara aquele endereço armazenado para a próxima execução que essa Thread necessitar fazer.

Pilha de método nativo (Native method stacks)

É uma pilha que guarda informações de métodos nativos para que quando houver uma nova execução (Thread), ela seja feita da maneira mais performática possível já tendo algumas informações (como métodos nativos) carregados e disponíveis para uso.

E por hoje é isso dominadores, cada vez mais mergulhando no que o Java pode nos oferecer, você tá satisfeito em ser só usuário? Vem nos comentários e me diz, fico mega feliz quando vejo vocês por aqui, um abraço e até a próxima!

Referências:

The JVM Architecture Explained - https://dzone.com/articles/jvm-architecture-explained
How JVM Works – JVM Architecture? - https://www.geeksforgeeks.org/jvm-works-jvm-architecture/?ref=rp
What are Threads in Computer Processor or CPU? - https://www.geeksforgeeks.org/what-are-threads-in-computer-processor-or-cpu/?ref=gcse
The Java Virtual Machine - https://www.artima.com/insidejvm/ed2/jvm8.html

JVM - Java é Verboso Mesmo? Parte III (já dizia Jack "vamos por partes")

Rodrigo — Fri, 27 Jan 2023 15:29:50 +0000

Edição: Correção no título, quem disse a frase, foi o Jack, não o Jason. Obrigado ao colega Eduardo, que corrigiu a gafe lá no LinkedIn. 🤓

Deêm uma boa olhada na imagem abaixo e processem a informação de que sim, a JVM é complexa, nem de longe é algo simples, até para que seja possível a portabilidade do código, foi pensado em como fazê-la de maneira que fosse capaz de executar comandos ao mesmo tempo que faz gestão de memória, melhoramento de processamento, entre outras funções e claro, tudo isso e mais um pouco, de forma independente do sistema operacional que ela esteja. Eu mesmo não conhecia algumas nuances de dentro desse universo, mas bora lá aprender juntos? #partiu

Na parte dois chegamos a dizer a forma que a classe Programa era compilada e enviada para execução. Agora vamos ver os caminhos que uma classe pode percorrer dentro da JVM. Então vou tentar explicar cada camada como venho fazendo nos artigos, pois acho que tá sendo uma boa maneira de me expressar e fica bastante didática (ao meu ver, claro)

Alô galera, deêm feedbacks!! assim eu sei se tá sendo legal (ou não) a experiência de vocês por aqui <3

Spoiler: Uma classe enviada à JVM pode ter até 256 opcodes possíveis em sua estrutura e seus operadores podem ser de 8 ou 16 bit. (Olha que artigo legal temos aqui! kkk)

Dado o Spoiler, bora lá então! A galera quer ser dominadora do café, né? Então vamos explorar cada pedaço pra melhorar nossas habilidades e pra começar, na Java Virtual Machine têm-se três principais subsistemas:

Subsistema de carregamento de classes (ClassLoader Subsystem)
Subsistema da área de pilha (Runtime Data Area)
Subsistema do motor de execução (Execution Engine)

Tentei traduzir pro pt-BR pra que a galera vá entendendo em português, mas já consiga também fazer um paralelo com o inglês onde esse material é mais farto e detalhado.

Subsistema de carregamento de classes

Fazem parte desse subsistema: Carregamento | Vinculação | Inicialização

Carregamento (Loading)

O carregamento performa afim de preparar a JVM para a execução e avalia os seguintes pontos:

O caminho completo da classe invocada na execução e o caminho de seu parente imediato; O que quero dizer com isso é: imagine que nossa classe Programa esteja no caminho, por exemplo:

C:\Desktop\projeto\Programa.java

O caminho completo é este mesmo exibido acima (em inglês fully qualified name, também chamado de FQN ), já o seu parente imediato é:

C:\Desktop\projeto

Qual referência o Bytecode (.class) é relacionado: Se a uma classe, se a uma Inteface ou a um Enum: No nosso exemplo, o arquivo Programa faz referência a uma Classe!

- Onde tu olhas pra ter tanta certeza disso, Rodrigo?

...Olhem a assinatura da nossa classe:

public Class Programa{

Basta por hora entender que por ter escrito ali ao lado de Programa a palavra Class, isso indica qual a referência será vinculada ao nosso Bytecode, que neste caso, a referencia é à Classe.

Informações dos modificadores, variáveis e métodos:

Modificadores: public, protected, default;

Variaveis: qualquer variável encontrada na classe ou nos blocos de execução dela;

Métodos: qualquer outro método que pode ser invocado dentro da classe, incluindo o método main;

E nesse contexto, o fluxo abaixo é realizado:

Inicializar o carregador de classes (BootStrap ClassLoader) - Que tem a responsabilidade de carregar as classes nativas para o classpath, ou seja, carrega os arquivos em memória a partir de onde está instalada a JVM no sistema operacional; E a biblioteca que se encarrega disso e terá a maior prioridade de todas nesta execução é a rt.jar (Runtime do Java); Ex.: Todas as bibliotecas dentro de $JAVA_HOME/jre/lib serão inicializadas a começar pela rt;
Extensor do carregador de classes (Extension ClassLoader) - Filha da Bootstrap e é responsável por carregar as demais bibliotecas da instalação a partir do caminho lib/ext; Ex.: Todas as bibliotecas dentro de $JAVA_HOME/lib/ext também serão carregadas para a memória após a inicialização anterior;
Carregador de classe de aplicação (Application Class Loader ou System Class Loader) - Responsável por carregar os Bytecodes encontrados no diretório invocado na execução. Ex.: No nosso exemplo, será a classe Programa.

_Usando a classe Programa como exemplo, vamos para a próximo fluxo...

Vinculação (Linking)

Performa afim de avaliar o que será necessário da JVM para a execução.

Verifica (Verifying) - Analisa a classe que entrou na JVM (Programa.class) e quais vinculações ela possui (se possui herança, se possui extensão, se há dependências de outras classes através de seus imports), caso haja falha, nessa verificação podemos encontrar a exceção java.lang.VerifyError por exemplo;
Prepara (Prepare) - Carrega a classe, fazendo a alocação de memória necessária e inicializando todas as referencias estáticas e seus valores padrões;
Resolve (Resolve) - É o processo que reaplica as referências simbólicas aos tipos e suas referências diretas. Essa resolução é dada através da busca e localização da entidade na área de método. Ex.: Nossa classe possui um System.out.println que imprime saídas no prompt (ou terminal), mas essa referencia é de uma biblioteca a System da biblioteca java.lang e a out (PrintStream) da java.io;

Inicialização (Initialization)

Nessa fase, já temos todas as variáveis estáticas definidas e seus valores padrões (caso tenham sido declarados), referencias de imports, se código referencia a uma Classe, uma Interface ou a um Enum. Então a inicialização se dá de cima para baixo, seguindo as nomenclaturas de pacotes, imports, definição de classe, definição de métodos, variáveis e modificadores;
A JVM segue o princípio de Delegação-Hierarquia para carregar as classes. Isso significa que é uma sequencia definida pela classe que entra e suas relações com as classes nativas da JVM...
Caso a JVM não consiga identificar essa relação com suas classes nativas, classes de extensão ou de aplicação, que foi o fluxo que explicamos acima, haverá uma exceção do tipo java.lang.ClassNotFoundException, indicando que o código não possui referência de classe capaz de tratar aquela execução que entrou na JVM.

Ufa! Hoje foi bastante detalhado, não foi? Mas por hora, como tá no título, vamos concordar com o Jason, porque o assunto é extenso e por isso, vamos por partes. hehehehehe

Espero que esteja gostando do conteúdo e se quiser me seguir, minhas redes estão aqui no meu perfil, fiquem a vontade!!

Um grande abraço e até a próxima!

Referências:

Como a JVM opera (em inglês) - https://www.geeksforgeeks.org/jvm-works-jvm-architecture/?ref=lbp
A arquitetura da JVM (em inglês) - https://dzone.com/articles/jvm-architecture-explained

JVM - Java é Verboso Mesmo? Parte II (A saga continua...)

Rodrigo — Thu, 19 Jan 2023 23:10:18 +0000

Fala Galera!
Bom, voltando aos estudos, hoje vamos trazer pra vocês a parte dois do estudo que iniciamos sobre a JVM e vou confessar, que doidera, quer mergulhar nesse conteúdo comigo? Vamos nessa!
No artigo anterior falamos um pouco da JVM e agora vamos detalhar um pouco mais esse assunto...
No artigo anterior, ao fim dele, tivemos o problema da nossa execução no terminal não funcionar e o abismo se abrir diante de nós, certo? certo. Só que não só de abismos vive o ser humano!!
Nos sistemas operacionais, quando temos casos semelhantes a este, significa que falta alguma coisa pra que aquele comando seja aceito, então, lembram do primeiro desenho das camadas de uma aplicação? Se não, olhem aqui.
A JVM fica guardada dentro de uma outra camada também conhecida como JRE, que por sua vez fica guardada dentro de outra camada que é a JDK, se tiver duvidas sobre o que é, revisita o link aí de cima que explico o que é cada camada.
E até aqui não fizemos nada além de escrever uma classe Java e como queremos ser desenvolvedores, né? então a JRE não é suficientemente capaz para apoiar a vida de um dev cabuloso do Java e por isso precisaremos do poder da JDK!
Então por isso o sistema diz que "javac not found", ou seja, o sistema não encontrou o executável responsável pelo comando javac que está contido na JDK. Claro, não fizemos a instalação de nada pra isso ser possível...ainda.
Então queridona, queridão, veja como fazer a instalação do JDK no seu sistema e vamos continuar em frente!! :)
Aqui, supondo que você já tenha uma JDK instalada no ambiente e o comando javac finalmente foi salvo o que será que você virá quando rodar o comando:

javac Programa.java

A resposta é um sonoro: Nenhum Acontecimento Deliberadamente Aconteceu ou podemos dizer também: N.A.D.A.

Calma!! Isso é bom, significa que sua classe Java COMPILOU!!! (uhull \o/)

No diretório que sua classe está, aparecerá agora um arquivo chamado Programa.class que também já expliquei nos artigos anteriores quem que lê e trata dele. E é agora que a brincadeira de verdade começa...
Antes de continuar, acho que aqui é legal deixar duas dicas bem importantes por causa desse momento:

Erros de Compilação Vs Erros de Execução

Você então aprendeu a compilar uma classe .java para um Bytecode .class.
Então, primeiramente:

Parabéns!! <3

Dito isto, um conceito essencial dentro do Java é o de erros.
Na certificação é comum haver um enunciado dizendo "Dado o código abaixo, diga se ele compila", "Qual das opções há erro de execução?" ou qualquer coisa semelhante... e saber esse conceito vai te ajudar bastante.
Na prova ele tá perguntando é: Hey, essa classe ai, segue as semanticas da linguagem, está correta e se eu usar o comando de compilação vai dar bom? e caso não esteja, isso é o que dizemos ser erros de compilação. Uma classe compilada está escrita de, maneira tal, a passar pelo compilador e obtermos o Bytecode dela.
Ah Rodrigo! e aquele erro de execução então? Eu não to executando o comando javac pra compilar? como é isso ai...?
Os erros de execução são erros de lógica de escrita, quando você por descuido ou desconhecimento não cobre completamente um trecho do seu código e durante a execução dele, isto é, após a classe já compilada, dá erro. A execução neste caso não é o do comando de compilação, mas sim de dentro da tua classe Java por quaisquer que sejam os motivos.

Vejamos:

public class Programa {
    public static void main(String[] args) {
        System.out.println("Hello Programa!" + args[0]);
    }
}

Se fizermos essa alteração no nosso código a classe compila? Siiiim.

Ah cara, mas tá, eu sei que pra compilar usamos o javac, mas tu comentou ai de executar, como que eu faço?

Bom, se você conseguiu compilar uma classe, a execução dela é bem simples, chamamos o famoso comando java. Vamos ver ele usando o nosso exemplo:

java Programa

Diferente da compilação, não precisamos dizer agora que vamos executar uma classe .java ou usar o Bytecode .class, o comando java entende que onde ele é invocado, existe uma ou mais classes compiladas pra execução, ele passa a classe invocada (no nosso caso a Programa) e envia ela para quem? para a JRE que possui quem? A JVM, muito bem!
O arquivo Programa.class então é recebido para a execução, porém neste momento...

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 0 out
of bounds for length 0
        at Programa.main(Programa.java:3)

E esse é um exemplo prático de um erro de execução.

- Rodrigo, mas que erro foi esse?

Essas, meus amigos, são as queridinhas Exceções ! Nesse exemplo, vemos a ArrayIndexOutOfBoundsException uma das muitas exceções possíveis de serem lançadas durante uma execução.
Ela está dizendo que em um dado Array, ou seja, numa lista de objetos, foi feita a tentativa de se obter um dado no índice 0, mas tal indice não existe e por isso a execução falha.

Sacou a diferença?

* javac - comando de compilação (que pode gerar erros de compilação) 
* java - comando de execução (que pode gerar erros de execução)

Por agora é isso pessoal, espero que estejam gostando da nossa jornada, se quiser tirar dúvidas, no meu perfil tem meu linktr com todas as minhas redes, sintam-se a vontade pra se conectarem comigo. Vamos juntos e até mais!! :)

JVM - Java é Verboso Mesmo? Parte I

Rodrigo — Mon, 09 Jan 2023 17:07:28 +0000

A resposta de muitos devs mais seniores é: depende!
O caminho até você se tornar capaz de deixar de ser um usuário da linguagem e passar a ser um criador dela não é um caminho simples ou pequeno e acima de tudo não haverá atalhos; e isso vale para qualquer linguagem de programação...
Por muito anos eu fui/sou usuário do Java, mas essa condição começou a me incomodar e a partir disso, eu tomei a decisão de dissecar o que eu puder dessa linguagem e assim, entender ela melhor, conseguir explicar conceitos aos que desejam entrar nesse universo que é o Java, aprender e juntos conseguirmos construir melhores produtos usando essa linguagem que está presente nos mais variados sistemas produtivos ao redor do globo.
No artigo anterior falamos um pouco sobre o cenário macro - do que na minha visão é importante sabermos primeiro - antes de cair matando na linguagem sem nenhum preparo mínimo que seja...
e hoje vamos falar um pouco do primeiro ponto: a JVM.
Na Alura, você encontra essas e outras explicações no curso Java Primeiros Passos, vamos lá?
A JVM ou por seu nome completo Java Virtual Machine nasceu pela necessidade de haver um artifício comum entre os dispositivos da época e que pudesse - independente do dispositivo - se comunicar e fazer com que tais equipamentos operassem de forma a termos um único código fonte.
Não vou entrar no detalhe da história e nomes dos responsáveis porque esse não é o foco, o foco aqui é apresentar de maneira mais didática possível o funcionamento do Java no dia-a-dia do usuário ou desenvolvedor, então bora seguir!

Vamos então fazer um primeiro exemplo de código, que apenas imprime uma mensagem no terminal do usuário com o texto "Hello Programa".

public class Programa{
    public static void main(String[] args){
        System.out.println("Hello Programa");
    }
}

Podemos ver esse diálogo
- O que você usa para escrever esse código, Rodrigo?
- Ah...qualquer editor de texto. Se tu usa Windows, o notepad, se usas o Linux, qualquer mousepad da vida, se tu usa o Mac (eu não sei o nome, não tenho Mac hehehe), mas você entendeu, né?! Desde que seja um editor de texto, tá valendo!

Show demais né? lembra que eu falei da necessidade de ser possível usar Java independente do dispositivo? Então, sistemas operacionais também vai nessa pegada ai!!
- Então se eu escrevo um código num sistema ele vai valer pra outro? SIM, graças a JVM isso é possível! E sendo assim, vamos dar uma olhada em como isso acontece por baixo dos panos:

Na imagem acima temos o nosso código fragmentado e particionado para exemplificar os pedaços que compõem o arquivo Programa.java e são eles:

Nome do arquivo: Programa.java;
Declaração de classe: public class Programa{};
Declaração do ponto de entrada principal: public static void main(String[] args){}
Trecho para execução: System.out.println("Hello Programa");
Classe compilada: Programa.java ao ser compilada torna-se Programa.class

Ali vemos dois pedaços, um acima, que escrevemos e queremos executar, ou seja, a linguagem humana e abaixo a linguagem compilada ou Bytecode como é conhecida, que é a linguagem que a JVM entenderá para enviar em seguida aos dispositivos para quaisquer execuções que sejam possíveis dado o dispositivo alvo.

Vamos em frente, num terminal qualquer você poderá executar o comando javac para compilar seu arquivo e obter o Programa.class:

javac Programa.java

Mas ao executar o comando acima, você pode topar como o seguinte problema:

/bin/sh: javac: not found

e o desespero vir: MAS O QUE HOUVE???? TÁ TUDO IGUAL AO QUE TU FEZ ALI EM CIMA, LINHA POR LINHA!!

E pode ser que esteja mesmo, daí em algum momento pode surgir o questionamento:
- tá, mas então como eu executo esse código, bicho?

E essa resposta ficará para a parte dois desse artigo sobre a JVM, nos vemos lá, abraços!

ps: pode mandar perguntas ou me seguir nas redes!! #VamoJunto

E a certificação hein?

Rodrigo — Wed, 04 Jan 2023 16:33:35 +0000

Olá pessoal, tudo bom?
Antes de mais nada, feliz 2023! Que tudo de melhor aconteça com você <3
Faz tempo que não venho por aqui, então peço desculpas, eu tô tentando me organizar pra melhorar meus estudos no Java e tenho feito bastante experimentos com conteúdos, podcast, código, cursos, aliando isso a jornada de trabalho e por isso a coisa tá meio devagar, mas parado, nunca!
Pensando nisso, o que tô querendo executar agora por aqui é simples, tô iniciando uma leitura nova sobre o famigerado Oracle Certified Associate (OCA), que é a certificação inicial pra quem quer se aprofundar no mundo Java, dito isso, a ideia é trazer essa leitura pra cá e trocarmos experiências sobre o meu modo de ver o que estudei, compartilhando com vocês essa visão, logo, vamos ter bastante pano pra manga, certo?! #Partiu rumo a certificação!
Bom, o lance com a certificação (pra mim) é me condicionar a perseguir o que ela pede como requisito e usar esses requisitos como norte para aprender de forma mais direcionada sobre a linguagem Java (que é um universo bem grandão, fala ai?), mas isso pode valer pra qualquer outra certificação também, beleza?

Plano de estudo

Aqui um material de apoio sobre plano de estudo produzido pela Zup, muito legal! recomendo a leitura: https://www.zup.com.br/blog/plano-de-estudo-zup
Você fazer um plano de estudo hoje é relativamente fácil, embora devemos ter uma cautela para não sair fazendo ele de qualquer forma. Então bora lá?

Teu direcionamento pra estudo, de onde vêm?

Minha principal fonte de estudo hoje, bom...será da Alura. Aqui você será direcionado para a página da Formação Certificação Java, mas caso eu use as referências de algum outro material ao longo da jornada, fica tranquilo que eu também vou colocar as referências pra gente ir seguindo juntos a cada novo tópico, beleza? Ah! e esse texto aqui não será o final, ele vai ser orgânico pra sempre que possível, ele ir melhorando...

Por onde começo?

Acho importante partimos do modelo conceitual pra depois a gente entender o que no detalhe o Java faz por debaixo de tudo. Hoje, se você fizer uma classe Java qualquer em um projeto, você sabe como ela se comporta e por onde ela vai até ser executada de fato? Vou te confessar que eu não, então vamos aprender juntos!?

Fonte: https://foojay.io/wp-content/uploads/2020/11/image2020-11-4_13-5-7.png

Detalhando um pouco a imagem acima, no desenho vemos várias camadas e vou tentar explicar cada uma adiante no que a imagem descreve como hierarquia de uma aplicação Java e tempo de execução - em tradução livre.
Da camada mais interna à mais externa temos:

JVM - O núcleo da aplicação que é conhecida como Java Virtual Machine ou em tradução livre Máquina Virtual Java, ou simplemente pelo acrônimo JVM. É na JVM que acontece a mágica do Java que ficou conhecido pelo ditado Write Once Run Anywere ou com pelo acrônimo WORA. Em outros artigos vou detalhar melhor o que é a JVM no detalhe e como ela trabalha, mas por hora, ficamos com esse conceito. É pra ela que vai todas as classes Java e independente do sistema operacional, o código será executado.
Java API libraries - Nada mais são do que as bibliotecas básicas para que o ecossistema Java funcione de forma adequada; Ex.: java/javac/tools/applet e outras;
JRE o Runtime - O runtime é a descrição do ambiente onde são concentradas as duas camadas anteriores (JVM + Java Lib) que são responsáveis pela de execução de um programa desenvolvido em Java. Então se você precisa executar um programa Java (um .jar da vida), por exemplo, da Receita Federal, você precisará ter um ambiente mínimamente preparado para essa execução e este ambiente é chamado de JRE runtime;
JDK - Já o Java Development Kit ou JDK é o ferramental que todo desenvolvedor Java necessita. Essa camada é necessária para que o desenvolvedor seja capaz de criar suas próprias lógicas de programação, seja ela, a execução mais simples como uma soma de dois números, um hello world ou uma execução mais complexa como uma classe de controle (Controller) dentro de uma API;
Apache etc. Open Source libraries - É o que a gente conhece hoje como Framwork ou até mesmo uma biblioteca adicional para uma dada execução qualquer. Ex.: Spring Framework ou a biblioteca para uso de logs na aplicação, o Log4J;
Application - É o produto final, um software, que foi desenvolvido e desenhado para cumprir um propósito. É muito comum dizermos que é o resultado de um desenvolvimento dado um cenário, seja ele uma pesquisa científica ou um fluxo de negócio dentro de uma empresa, por exemplo. E vejam, o produto pode ser uma biblioteca, um game, um app desktop, um web app, etc... Java é demais ☕

Deixo aqui um podcast que complementa o artigo acima: Podcast do Lambda3 - Ecossistema Java

Teve dúvida? coloca aí nos comentários e vamos bater um papo!

Abraços e até a próxima 🚀

[pt-BR] Será que isso é o básico? [parte III] - A API SOAP

Rodrigo — Wed, 31 Aug 2022 20:10:09 +0000

Fala pessoALL,
Tudo certinho? Espero que sim!
Bom vamos continuar nosso papo sobre uns conceitos básicos que temos trazido? Vamos!
Na primeira publicação falamos um pouco da divisão que tem no universo do desenvolvimento de software. Já na segunda publicação trouxemos o conceito de APIs, o que são e pra que servem, vimos inclusive que há tipos diferentes de APIs e esse próximo texto vai se aprofundar exatamente nos tipos,então vamos lá!
O SOAP de acordo com a Wikipédia é: "um protocolo para troca de informações estruturadas em uma plataforma descentralizada e distribuída." e em tradução livre seria algo como Protocolo de Acesso a Objeto Simples, que tinha sua representação por meio de arquivos XML que eram dispostos em servidores web, inicialmente de forma privada, mas com o advento da Internet este protocolo se popularizou bastante, foi tão disseminado que até hoje se encontra em servidores mundo afora, seja em ambiente produtivo ou em simuladores de APIs...

Exemplo de uma página XML que mostra a chamada de uma requisição de nome GetCDLStat que repassa ao servidor os parâmetros (year, fips e CSV) e o GetCDLStatResponse que é a resposta da requisição e dá como retorno uma URL que entrega um arquivo .CSV.

E como é que essa comunicação era feita, Rodrigo? Bom, a imagem abaixo tenta esboçar esse cenário:

No lado esquerdo temos um dado cliente o Service Requester (lembrando que cliente é quem pede algo, que solicita alguma informação, quem requisita alguma coisa). Neste exemplo temos o Service Broker, que não vamos nos aprofundar, mas está aí para fazer uma especie de validação do que está sendo requisitado e se a requisição irá encontrar seu correspondente num dado servidor. Em seguida, há o Service Provider que é o nosso servidor da informação, o provedor da informação, quem cede o dado ao requisitante, ou seja, ao cliente.
Notem que entre o cliente e o servidor há o SOAP, mas que há outro carinha aí no meio da jogada, o famigerado WSDL!
Segundo a IBM: "WSDL é uma notação XML para descrever um serviço da web. Uma definição WSDL indica a um cliente como compor uma solicitação de serviço da web e descreve a interface que é fornecida pelo provedor de serviços da web."
Trocando em miúdos, é uma representação que te mostra quais informações estão disponíveis em um dado servidor e o que é preciso - pra você como cliente - enviar como informação, para obter do servidor uma resposta satisfatória à tua requisição. É o que chamamos hoje em dia de contrato.

Bom galera, espero que tenham curtido esse conteúdo hein?
E você, já mexeu com WSDL, com SOAP, conta aqui pra gente !
Ah! Conta também o que tu acharia interessante ver por aqui, me ajuda a criar esse conteúdo que é nosso, até o próximo protocolo pessoal,valeu demais!

[pt-BR] Será que isso é o básico? [parte II]

Rodrigo — Wed, 17 Aug 2022 04:07:00 +0000

Faaaala galera, todos bem? Espero que sim! O texto de hoje vai ser um pouco mais extenso...
No post anterior a gente comentou sobre quem é você no rolê da firma, pontuando alguns dos perfis existentes dentro do desenvolvimento de software...

"Ah Rodrigo, mas não tem só isso..."
Verdade! eu disse que foi um apanhado bem específico da área onde eu atuo que é o desenvolvimento de software; mas existem várias descrições dentro da área de TI, do desenvolvimento ou fora dele, inclusive pra designar um mesmo cargo (haja sigla, em português, em inglês, uns bem auto descritivo, outros nem tanto).
Mas ainda falando do texto anterior eu dei introdução a uma palavrinha - e vou puxar a sardinha pro meu universo, o Backend - que acho que é legal a gente detalhar um pouco hoje:

API - Application Programming Interface - O que é, como se reproduzem, o que comem? Calma...

A interface de programação de aplicação (API do inglês) nada mais é do que uma maneira que se criou de permitir a comunicação entre sistemas, usando variados tipos de protocolos (galera de redes e de circuitos tão ligados, né?) , isso vem bastante herdado do conceito de redes de computadores, protocolos de comunicação, envio/recebimento de pacotes e como cada unidade computacional pode ser integrada a um conceito maior e construir um novo conjunto de serviços.
Uma das primeiras interfaces visuais, foram as telas verdes com cursores de entrada de dados que piscavam numa tela que lembrava muito as TVs de cubo que a gente ainda vê por ai, eu já tive uma dessas TVs e vocês? Hahaha

E com a evolução dos conceitos dentro da computação, as APIs hoje são representações abstratas de sistemas que produzem algum tipo de interface (meio que permite que execuções internas possam ser consumidas externamente) que perpetuam o conceito de envio/recebimento mas agora não apenas dos pacotes e não apenas por uma rede privada, mas agora também pela imensidão da Internet. Essa troca segue outro, o conceito de cliente/servidor, onde o que chamamos de cliente, ou seja, outro sistema ou outra API que se deseja se comunicar com quem serve/disponibiliza a informação o servidor. Essa comunicação tem por objetivo suprir um dado fluxo de negocio.

"Caramba Rodrigo, buguei aqui, como assim?"

Vamos a um exemplo prático: Eu estou desenvolvendo uma API que precisa ter em uma das rotinas os dados de endereço dado um CEP qualquer. Neste instante eu posso fazer uma integração a outra API, por exemplo, a dos correios que possui detalhamento do endereço passando como parâmetro o CEP do lugar, neste momento eu posso criar esse mecanismo de integração entre as interfaces do cliente/servidor, pegando o CEP e usando para consumir a API dos correios e receber como resposta os detalhes do dado, como rua, cidade, estado, se a rua é uma avenida ou uma travessa...

Deu pra entender melhor o conceito?
Como esse tópico é um pouco mais extenso, pra fazermos um corte pra uma parte III, fica aqui algumas opções de protocolos de APIs que existem hoje por aí...

API SOAP
API REST
API WEBSOCKET
API RPC

Na próxima podemos detalhar cada uma delas, beleza, que tal...? E você gostou desse conteúdo? Que tipos de APIs você já trabalhou, quais os desafios que encontrou, me conta aí nos comentários?!
Até a próxima pessoal!

[pt-BR] Será que isso é o básico? [parte I]

Rodrigo — Tue, 09 Aug 2022 19:01:00 +0000

Fala pessoALL!
Bem, nesta primeira empreitada sobre compartilhar conhecimento, vou tentar fazer uns apanhados sobre o que sei sobre programação. A pegada aqui vai tentar ser informal a principio pra todo mundo ir ficando a vontade e assim a gente ir crescendo juntos e se aprofundando nas teorias e práticas de programação.
Me ajudem nessa? Aqui ninguém aprende nada só, então vamos juntos que vamos mais rápido!
Não fiz um apanhado de tópicos pra trabalhar, vou então falar do teórico perfil de um dev no dia-a-dia...

Qual linguagem te atrai?
Isso é legal já ter uma noção, pois isso direciona teu estudo, já que na nossa área os assuntos são infinitamente fragmentados, então aqui vai o primeiro toque: Escolha um caminho!

Dica do Dev do amor: Dá uma olhada nelas, youtube, github, fóruns, documentação oficial pra ver como elas são de fato...assim, quando bater os olhos, quem sabe não role o amor a primeira codada? hahahaha

Que linguagens são essas?

Quando a gente fala de desenvolvimento, quais perfis mais se destacam?
Então, bem simplificado...

Backend - O indivíduo que está "por trás" do processo de desenvolvimento
Esse perfil de desenvolvedor é aquele que gosta mais de estar envolvido em rotinas por de trás dos panos, não curtem muito desenhar uma janela, fazer um estilo de página com CSS, construir um produto responsivo, enfim aquele que gosta de criar os mecanismos que não ficam destacados pro usuário final, é a pessoal que constrói uma API pra ser consumida ou que consuma outra API disponível... é quem garante que os sistemas visuais (janelas, app, integrações entre sistemas) conseguem conversar entre si.
Essa é a galera do Java, do Python, do NodeJS, do DotNet...

Frontend - O indivíduo que está "à frente" do processo de desenvolvimento
Esse perfil de desenvolvedor é aquele que agora sim, gosta de usar efeitos, saca bem sobre alinhamentos, estuda estruturas visuais, o que precisa pra que um produto seja responsivo, aquela pessoa que come CSS/SCSS no café da manhã, aquele que vê como plugar as coisas numa área visual pra agregar valor pro cliente.
Essa já é a galera do JavaScript, do TypeScript, do CSS, do HTML, do Angular, do VueJS...

Fullstack - O indivíduo que atua em ambas
Esse perfil é o Gotenks do DBZ, é a fusão dos dois primeiros perfis...é aquele que consegue e gosta de permear pelas duas nuances do desenvolvimento...
Aqui é a galera que pega o que vier...

DBA - Database Administrator ou Administrador de banco de dados
Gente o DBA é o perfil que pode ser considerado um backend, mas digamos que mais especializado ou seja, ele foca em um único tópico, nesse caso, o desenvolvimento de banco de dados. Como otimizar queries, consultas, tunning de indexação de tabelas em relação a bancos relacionais...
Aqui pode ser a galera que usa SQL, PLSQL, TSQL...

Espero que pra um primeiro texto vocês tenham curtido... e aí, quem é tu no rolê da firma? hahaha
Agora é com vocês, o que faria sentido trazer aqui pra vocês lerem?
Eu ia curtir demais esse feedback, que daí eu estudo e trago aqui pra gente debater, o que tu me diz? Diz aí nos comentários...