Artigos recentes
Mostrando postagens com marcador Java. Mostrar todas as postagens
Mostrando postagens com marcador Java. Mostrar todas as postagens
sábado, 17 de março de 2018
sábado, 17 de março de 2018
- 0 Comentarios
No artigo de hoje vamos falar não só de uma, mas sim de três versões do Java, a versão 9 (e os módulos), as melhorias da versão 10 e a futura versão 11. Este artigo é apenas para apresentar mudanças e não ensinar todos os aspectos delas.
Java 9
O Java 9 trouxe muitas melhorias, concatenação dinâmica de string, API de processos, cliente HTTP 2 (incubado, falarei disto também), Stack-Walking API, métodos privados em interfaces, métodos factory em coleções e o mais importante, sistema de módulos (Projeto Jigsaw).
Concatenação dinâmica de string
No Java 9, as concatenações de string, ou seja, isto:
"Seu nome é: " + person.getName() + ", e seu email: " + person.getEmail();
agora é compilado para um código dinâmico, ao invés de estático, mas o que muda com isto? Em relação a código Java, nada, você continua escrevendo a mesma coisa e recebendo os mesmo resultados, mas na prática, o desempenho deste código poderá ser melhorado com mudanças na máquina virtual Java, ao invés de apenas serem perceptíveis ao recompilar o código, como era antes do Java 9.
API de processos
No Java 9 agora temos uma nova API de processos, muitas coisas foram adicionadas nas classes existente e novas classes foram introduzidas, como a ProcessHandle. Com a nova API, você pode obter informações que antes não eram possíveis, como o id do processo (PID), processos filho, processo pai, argumentos, usuário, tempo na cpu, momento de inicialização, e até fechar o processo de forma natural ou forçada.
Cliente HTTP 2
O novo cliente de HTTP tem suporte ao HTTP/2, com autenticação, gerenciador de cookies, SSL, Proxy, classe para respostas de pedidos, etc... Veja a documentação da API.
Esta feature foi adicionada como incubação, o que isto quer dizer? É uma API que está em desenvolvimento mas foi exposta aos desenvolvedores por meio de um módulo de incubação, este módulo não é importado por padrão e as classes nele vão deixar de existir em futuras versões, seja porque foram descartadas, ou porque foram liberadas e movidas para outro modulo.
Stack-walking API
Esta nova API tem o propósito de tornar mais simples o ato de caminhar na stack, ou seja, conseguir inspecionar e encontrar os elementos da stack do Thread atual, os elementos estão ordenados do topo (sendo os primeiros elementos da stream) ao fundo (sendo os últimos elementos da stream).
Milling Coin e factory methods em coleções
Agora podemos declarar métodos privados em interfaces (teoricamente, já era possível desde o Java 8, com os lambdas dentro de métodos default), isto vai ajudar a diminuir códigos duplicados em métodos default em interfaces, permitindo a funcionalidade ser movida para um outro método sem ter que expor ele a quem irá consumir a API.
Agora também temos a possibilidade de anotar métodos privados com @SafeVarargs, usar o operador diamante (<>) em classes anonimas e também podemos usar variáveis efetivamente finais no try-with-resources, exemplo:
Resource res = openResource(...);
Resource res2 = openResource(...);
try (res; res2) {
...
}
Além disso, o underscore ('_') agora é uma 'palavra' reservada, ou seja, você não poderá usar ele como identificador.
Agora também temos métodos factory em coleções, como List.of, Set.of, Map.of, mas tenha em mente que a coleção retornada por estes métodos são imutáveis, diferente das coleções retornadas pelo Collections, que normalmente são visualizações de outras coleções, visualizações nas quais, em alguns casos, seus métodos de modificação não refletem na listas originais, mas sim lançam uma exceção.
Spin-wait hints
Este recurso foi adicionado com o propósito de diminuir latência e consumo de energia em threads com spin loop. Spin loops são loops que são executados a todo momento enquanto esperam um trabalho ser finalizado por outro thread, sabe aquele while (foo.isRunning()) Thread.sleep(100);, então, ao invés de usar Thread.sleep ou algo similar (ou simplesmente só o while), você poderá usar Thread.onSpinWait, que faz com que o Thread espere alguma atividade terminar para continuar trabalhando, isto também abre portas para a JVM otimizar este código e determinar até quando o Thread deve aguardar.
Outras mudanças
Também houve várias outras mudanças, como G1GC tornar-se o coletor padrão, suporte a Unicode 7.0 ,8.0 e UTF-8 em arquivos de propriedades, Javadoc em HTML5, novo formato de string de versão, pipeline de anotações 2.0, e muitas outras que você pode ver aqui.
Sistema de módulos e o famoso Jigsaw
Finalmente chegamos aonde importa (na verdade todas as mudanças importam, mas essa importa mais): o sistema de módulos e o projeto Jigsaw. Com o sistema de módulos, partes do seu sistemas podem ser separadas em módulos, o que permite um melhor desenvolvimento, já que você poderá trabalhar com os módulos separadamente (até mesmo com equipes separadas) e testar seu sistema com estes módulos mesmo que os demais não estejam prontos (contanto que os módulos dependentes estejam prontos), também permite melhor escalabilidade, segurança (com encapsulamento forte) e que a JVM faça melhores otimizações de performance. Também tivemos a extensão do sistema de serviços, agora é possível prover e requisitar serviços por meio da declaração do módulo.
Também foram introduzidas novas ferramentas para construir uma máquina virtual com apenas alguns módulos (jlink), isto é perfeito para aplicações standalone, você não precisará mais ter uma aplicação com 190MB da JVM e 1MB da aplicação em si, você poderá ter uma JVM com a aplicação com apenas ≃20MB (diminui pela metade com compressão).
Também tivemos algumas mudanças que quebraram compatibilidade, como por exemplo, o fato do ClassLoader da aplicação não ser mais um URLClassLoader.
Você deve estar se perguntando, e o Jigsaw? (Ou não né). O Jigsaw é o projeto que engloba todo o sistema de módulos: a modularização da própria plataforma Java, as novas ferramentas, o encapsulamento das APIs internas, e etc...
Também foram introduzidas novas ferramentas para construir uma máquina virtual com apenas alguns módulos (jlink), isto é perfeito para aplicações standalone, você não precisará mais ter uma aplicação com 190MB da JVM e 1MB da aplicação em si, você poderá ter uma JVM com a aplicação com apenas ≃20MB (diminui pela metade com compressão).
Também tivemos algumas mudanças que quebraram compatibilidade, como por exemplo, o fato do ClassLoader da aplicação não ser mais um URLClassLoader.
Você deve estar se perguntando, e o Jigsaw? (Ou não né). O Jigsaw é o projeto que engloba todo o sistema de módulos: a modularização da própria plataforma Java, as novas ferramentas, o encapsulamento das APIs internas, e etc...
Mudanças importantes
Como disse anteriormente, o Java 10 não virá com o Valhalla, tivemos grandes mudanças não só no Java como também no modelo de lançamento, agora o Java será lançado de 6 em 6 meses com menores quantidades de novidades; e como o projeto Valhalla é um projeto que ainda não está pronto então ele não será incluído no Java 10, e talvez nem mesmo no 11 (provavelmente, com sorte, no 12 ou 13). Além disso, teremos suporte por tempo limitado, assim que sair o Java 10 (que está perto, 20/03), provavelmente não teremos mais atualizações para o Java 9 depois de um tempo, e quando sair o 11, não teremos mais atualizações para o 10, mas não se preocupe, o Java 8 é LTS, então terá suporte até 2019 ou 2020 (ou mais tempo), e o Java 11 será uma LTS também, porém o tempo de suporte ainda será divulgado em setembro¹.
E falando em suporte, a Oracle irá parar de dar suporte gratuito a Oracle JDK (hora de mudar para outra JDK com a OpenJDK, Eclipse OpenJ9, Zulu. Fique a vontade, ou você pode pagar pelo suporte da Oracle JDK).
Java 10
Temos a omissão do tipo de variável por meio do var, ele poderá ser usado na declaração de variáveis no lugar do tipo, e ficará a cargo do compilador inferir o tipo da variável, exemplo:
Predicate<User> isEmailValidated = User::isEmailValidated; var users = userManager.getOnlineUsers().stream().filter(isEmailValidated.negate()).collect(Collectors.toList()); // List<User> var names = users.stream().map(User::getUserName).collect(Collectors.toList()); // List<String>
Isto tornará os códigos mais legíveis (ou menos, depende de como você usar), porém note que para o caso do predicado foi necessário especificar o tipo explicitamente, isto também acontecerá com métodos genéricos, operador diamante ou array sem tipo explicito (tipo var x = {1, 2}; não é possível, mas var x = int[]{1, 2}; é possível). Entretanto, diferente de outras linguagens de programação aonde você pode utilizar outra palavra, como o val, para declaração de variável final, isto não foi incluso no Java 10, mesmo após altos números a favor.
Parecido com o invokedynamic, mas para constantes, removendo assim alguns limites do invokedynamic e dando mais suporte ainda a linguagens dinâmicas e abrindo mais portas para melhorias de desempenho (tanto da linguagem Java quando de linguagens dinâmicas).
Um novo coletor de lixo que não coleta lixo (que?), este coletor de lixo irá gerenciar o alocamento de memória, mas não irá reivindicar a memória, se o memória ficar cheia a JVM irá ser fechada. Este coletor poderá ser usado para testes de desempenho, já que ele irá afetar o minimo possível o desempenho (isso se não afetar nada), poderá ser usado para testar a pressão na memória, também para tarefas rápidas onde o tempo de vida da máquina virtual é pequeno, ou até mesmo para aplicações que são muito sensitivas a latência; eu que não gostaria do GC coletando o lixo bem na hora que o piloto automático deveria fazer uma curva, brincadeiras a parte, este novo coletor será muito útil para vários outros propósitos.
Para quem ta por fora, o Java EE não é mais um projeto da Oracle, agora é um projeto da Eclipse, e alias, foi renomeado para Jakarta EE.
Mas bom, o motivo da remoção não é esse, mas sim porque o Java EE era entregado juntamente ao Java SE apenas por conveniência, tanto Java EE como CORBA serão removidos, se você precisar deles, bom, já sabe, terá de incluir as bibliotecas deles na sua aplicação (alias, alguém usa ou tem interesse em usar CORBA?).
Outras mudanças
Tivemos também a interface do coletor de lixo, coleção de lixo totalmente paralela para o G1, compartilhamento dos dados de classe da aplicação, remoção do javah, etc.. Veja todas aqui.
O que esperar do Java 11
Com o Java 10 próximo de ser lançado (dia 20/03), já temos uma ideia do que teremos na versão subsequente:
Constantes dinâmicas
Parecido com o invokedynamic, mas para constantes, removendo assim alguns limites do invokedynamic e dando mais suporte ainda a linguagens dinâmicas e abrindo mais portas para melhorias de desempenho (tanto da linguagem Java quando de linguagens dinâmicas).
Epsilon - um novo coletor
Um novo coletor de lixo que não coleta lixo (que?), este coletor de lixo irá gerenciar o alocamento de memória, mas não irá reivindicar a memória, se o memória ficar cheia a JVM irá ser fechada. Este coletor poderá ser usado para testes de desempenho, já que ele irá afetar o minimo possível o desempenho (isso se não afetar nada), poderá ser usado para testar a pressão na memória, também para tarefas rápidas onde o tempo de vida da máquina virtual é pequeno, ou até mesmo para aplicações que são muito sensitivas a latência; eu que não gostaria do GC coletando o lixo bem na hora que o piloto automático deveria fazer uma curva, brincadeiras a parte, este novo coletor será muito útil para vários outros propósitos.
Remoção dos módulos Java EE e CORBA
Para quem ta por fora, o Java EE não é mais um projeto da Oracle, agora é um projeto da Eclipse, e alias, foi renomeado para Jakarta EE.
Mas bom, o motivo da remoção não é esse, mas sim porque o Java EE era entregado juntamente ao Java SE apenas por conveniência, tanto Java EE como CORBA serão removidos, se você precisar deles, bom, já sabe, terá de incluir as bibliotecas deles na sua aplicação (alias, alguém usa ou tem interesse em usar CORBA?).
Sintaxe para variáveis locais de lambdas
Eis algo que incrementará a sintaxe Java, mas nada muito grande, esta mudança permitirá a utilização do var nas declarações de variáveis de lambdas, permitindo assim a adição de anotações sem perder a brevidade das declarações lambdas. Exemplo:
Function<String, Integer> toInteger = (@NotNull var s) -> Integer.parseInt(s);
Bom era apenas isso, se houver mais novidade com relação ao Java 11 farei um outro artigo. Obrigado por ler :D
quinta-feira, 11 de agosto de 2016
quinta-feira, 11 de agosto de 2016
- 0 Comentarios
O Android Nougat irá vir com uma nova tecnologia que promete economizar mais energia e fazer com que o Android ganhe um desempenho até 600% melhor, a Google já incluiu uma nova tecnologia para melhorar o desempenho do sistema, o ART.
Dalvik e ART
Primeiro, vamos entender qual é a diferença entre o ART e o antigo Dalvik.
O antigo Dalvik, carregava o aplicativo, e quando alguma parte precisava ser otimizada, ele parava o aplicativo e otimizava esta parte, fazendo com que o aplicativo travasse algumas vezes, com a vinda do ART, os aplicativos começaram a ser baixados ainda como aplicativos com código dex, mas, compilados para código nativo durante a instalação (por isso alguns apps demoram para instalar, principalmente os maiores).
O JIT
O que é a tecnologia JIT? Como ela funciona? Ela realmente melhora o desempenho?
Nas máquinas virtuais, o JIT é altamente importante, pois ele analisa as partes que necessitam ser otimizadas, e as otimiza. A antiga Dalvik VM fazia isto, mas não era muito eficiente.
O JIT é um compilador que transforma partes que estão escritas em uma linguagem intermediaria (o dex neste caso) em código nativo, porém, a função dele não é somente transformar estas partes, ele também as apaga quando vê que não precisa mais delas, e pode até descartar um código e tentar compilar novamente usando outra estratégia ou com base em novos dados, fazendo com que o aplicativo esteja em otimização constante.
O JIT melhora muito o desempenho dos aplicativos pelo fato dele poder transformar as partes do código com base na forma em que o usuário utiliza o aplicativo.
O ART somente compila o código antes de executar o aplicativo, enquanto o JIT pode otimizar enquanto o usuário utiliza o aplicativo, permitindo assim que o JIT faça o aplicativo ter mais performance com base na forma em que o usuário utiliza o mesmo.
Mas se o ART compila diretamente para código nativo, não deveríamos ter melhor desempenho? Não necessariamente, pois nem sempre o código nativo será melhor que o código dex, já que as VMs tem melhores tecnologias, e algumas coisas precisam de um trabalho extra para serem transformadas em código nativo, além do fato de que um compilador AOT precisa de um desenvolvimento longo para chegar a uma fase na qual o código nativo gerado consiga ser tão rápido quanto um aplicativo compilado diretamente para código nativo.
Mas se o ART compila diretamente para código nativo, não deveríamos ter melhor desempenho? Não necessariamente, pois nem sempre o código nativo será melhor que o código dex, já que as VMs tem melhores tecnologias, e algumas coisas precisam de um trabalho extra para serem transformadas em código nativo, além do fato de que um compilador AOT precisa de um desenvolvimento longo para chegar a uma fase na qual o código nativo gerado consiga ser tão rápido quanto um aplicativo compilado diretamente para código nativo.
Quais melhorias teremos?
Pelo fato do JIT compilar para código nativo sempre que for necessário, teremos um menor consumo de bateria, já que não será necessário interpretar todo o código dex; as instalações serão bem mais rápidas; e esqueça as telas de otimização de aplicativos.
Manterei vocês informados no caso de alguma novidade em relação ao JIT no Android.
domingo, 15 de maio de 2016
domingo, 15 de maio de 2016
- 0 Comentarios
Project Valhalla
Para quem não conhece, o projeto Valhalla visa melhorar os genéricos da linguagem Java. Como a própria página do projeto diz, ele não irá trazer os genéricos reificados para o Java, o objetivo principal é permitir que possamos utilizar primitivos nos genéricos.
É inevitável que, com a evolução da JVM seja necessário termos uma espécie de unificação entre Referencias e Valores (primitivos) no sistema de genéricos do Java, já que, cada vez os genéricos estão mais presentes na linguagem, como por exemplo, nas classes funcionais.
Atualmente, os genéricos só aceitam Referencias, e isto faz com que, se você quiser passar os tipos primitivos, você irá informar o tipo Wrapped (Integer, Character, Short, etc), e quando passar os valores, a JVM irá fazer boxing e unboxing, e como na maioria das vezes utilizamos primitivos, a JVM terá um grande problema com o desempenho. A solução atual desenvolvida pela equipe para a área funcional, foi criar classes funcionais que aceitassem primitivos (IntUnaryOperator, DoubleUnaryOperator), porém, em uma linguagem orientada a objetos, esta não é a melhor solução, sem considerar que, o método destas classes são: applyAsInt, applyAsDouble, etc.
A proposta atual da equipe do Valhalla é: manter o type erasure para os genericos de Referencia, e criar uma nova classe em runtime para os primitivos, esta é uma boa solução, mas ainda é apenas o começo.
Até o momento, a parte mais importante já foi implementada, a geração de classe para os primitivos e a possibilidade de usa-los nos genéricos.
Para que isto pudesse ser possivel era necessário que algumas instruções fossem substituidas por outras, por exemplo, quando se trata de um objeto é utilizado 'aload', 'astore', porém, quando se trata de um primitivo, é necessário usar por exemplo, 'iload', 'dload', etc, uma para cada primitivo. A proposta do modelo 3 era criar novas instruções que pudessem chamar outras instruções baseadas no tipo armazenado no 'constant pool' (cabeçalho da classe aonde ficam muitas das informações) das classes, sendo elas 'vreturn', 'vload', 'vstore', etc... que referenciam uma posição do 'constant pool', atualmente é este que esta sendo implementado no projeto.
Veja um exemplo abaixo:
Minha classe:
Para que isto pudesse ser possivel era necessário que algumas instruções fossem substituidas por outras, por exemplo, quando se trata de um objeto é utilizado 'aload', 'astore', porém, quando se trata de um primitivo, é necessário usar por exemplo, 'iload', 'dload', etc, uma para cada primitivo. A proposta do modelo 3 era criar novas instruções que pudessem chamar outras instruções baseadas no tipo armazenado no 'constant pool' (cabeçalho da classe aonde ficam muitas das informações) das classes, sendo elas 'vreturn', 'vload', 'vstore', etc... que referenciam uma posição do 'constant pool', atualmente é este que esta sendo implementado no projeto.
Veja um exemplo abaixo:
Minha classe:
A palavra 'any' será a nova palavra reservada do Java, que indica que este genérico poderá receber qualquer coisa, não só Referencias, mas também tipos primitivos. Também será inserida duas novas palavras reserdas, ref e val, ref será somente para referencias, e val para os futuros 'Value Types' e os primitivos. Quando compilada, serão geradas duas classes, a MinhaClasse e MinhaClasse$$any.
A classe MinhaClasse implementará a classe MinhaClasse$$any, a qual até o momento é só uma representação, não tem nenhum elemento dentro dela, somente algumas informações.
Agora vamos ver o que ocorre quando chamarmos esta classe com dois tipos distintos, uma int, e outra String.
Agora, quando executarmos este código, quando você instanciar a classe pedindo que o genérico seja int, a JVM irá gerar uma classe que também implementa MinhaClasse$$any que aceita int, e com um método getValue que retorna int, esta classe se chamara MinhaClasse$${I} (sendo I a representação de int). No segundo caso, a JVM continuará fazendo o mesmo que faz atualmente, inferindo os tipos, não irá gerar nenhuma classe.
A geração de classes fica a cargo de um "especializador", o mesmo faz logging dizendo que especializou a classe.
Vamos dar uma olhada no bytecode agora?
Na primeira declaração, vemos que o compilador gera uma chamada para uma classe chamada MinhaClass<I>, qual não existe em tempo de compilação, em em tempo de execução será gerada, assim permitindo que ela seja chamada ser dar erro de "ClassNotFound", também é chamado o construtor (I)V, que está presente na classe gerada, mas não na classe que escrevemos (a que escrevemos tem o constructor descrito como '(Ljava/lang/Object;)V' (MinhaClasse(Object)), qual se pode observar mais abaixo após '// String X'
O compilador gera o código desta forma pois, durante a compilação, não é possível chamar classes inexistente (o compilador oficial não permite), mas é possível sim, chamar métodos ou classes que não existem durante a compilação, contanto que elas existam durante a execução da aplicação.
Os obstaculos
Por mais que tenha muita coisa pronta, ainda não está completo, é necessário ainda correções no sistema de Arrays (proposta Arrays 2.0), Arrays de genéricos ainda precisam ser Object (o método toArray do List & Stream por exemplo, que aceita T[], só irá aceitar arrays de objetos, não os de int), melhorias de desempenho e refinamentos, também tem o problema com a compatibilidade, que é o maior obstáculo atual.
Fiquem ligados, mais noticias postarei no blog.
terça-feira, 7 de julho de 2015
terça-feira, 7 de julho de 2015
- 0 Comentarios
Que programador novato já não sofreu com erros chatos e ficou horas tentando resolver?
Um deles é o ConcurrentModificationException (Erro de modificação concorrente), o próprio erro ja diz, modificação concorrente, aonde 'alguém' mais está disputando uma modificação ou leitura no mesmo elemento.
Este erro ocorre quando você entra em um elemento da lista, e do nada ele é modificado, isto ocorre mais no caso de multi-threads, aonde vários 'núcleos' da aplicação irão compartilhar da mesma lista.
Como resolver?
É simples, permitindo que somente um thread acesse a lista por vez, existem várias formas, uma delas é usando synchronized, abaixo eu tenho um exemplo de modificação concorrente:
Saida:
Configurando sessao 0 Apagado sessao 0 Indo para proxima sessao: 1 Exception in thread "Thread-0" java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) at java.util.HashMap$KeyIterator.next(HashMap.java:1453) at cc.a.CCA$1.run(CCA.java:19) at java.lang.Thread.run(Thread.java:745)
Para corrigir precisaremos usar synchronized sempre que formos acessar está lista, assim permitindo somente que 1 thread acesse por vez, veja o resultado:
Saida:
Configurando sessao 0 Indo para proxima sessao: 1 Configurando sessao 1 Indo para proxima sessao: 2 Configurando sessao 2 Indo para proxima sessao: 3 Configurando sessao 3 Indo para proxima sessao: 4 Configurando sessao 4 Indo para proxima sessao: 5 Configurando sessao 5 Indo para proxima sessao: 6 Configurando sessao 6 Indo para proxima sessao: 7 Configurando sessao 7 Indo para proxima sessao: 8 Configurando sessao 8 Indo para proxima sessao: 9 Configurando sessao 9 Apagado sessao 0
O segredo?
Basicamente, o synchronized vai bloquear o acesso de qualquer thread enquanto outro já estiver acessando, e só irá liberar após o acesso terminar, ele não irá impedir o acesso, só irá fazer com que ele só seja operado após o termino do atual. O synchronized pode ser usado em métodos também (public synchronized void), permitindo somente uma chamada de método por thread.
Até a próxima dica :D
Basicamente, o synchronized vai bloquear o acesso de qualquer thread enquanto outro já estiver acessando, e só irá liberar após o acesso terminar, ele não irá impedir o acesso, só irá fazer com que ele só seja operado após o termino do atual. O synchronized pode ser usado em métodos também (public synchronized void), permitindo somente uma chamada de método por thread.
Até a próxima dica :D
domingo, 5 de julho de 2015
domingo, 5 de julho de 2015
- 0 Comentarios
Olá pessoal, vamos aprender hoje o primeiro passo para programar em java, eu estava querendo fazer isto a muito tempo, os tutoriais serão tanto em vídeo, como em um extenso texto que ninguém entende nada.
Primeiramente você deve ter o Java, e depois olhar o eclipse, ops, baixar o Eclipse. Há várias opções, eu recomendo a primeira, baixe conforme a versão do teu sistema operacional, geralmente ele vai detectar conforme seu navegador, no meu caso, o sistema operacional é Linux, de 64 bits, mais acredito que a maioria (99,999999...%) usa Windows, não se esqueça de baixar a versão 32 bits para sistemas de 32 bits e de 64 bits para a versão de 64 bits.
Mais como eu sei se o meu é 32 ou 64? É bem simples
Windows XP: Iniciar, clicar com o botão direito em Computador, depois em Propriedades, e na janela terá um texto escrito: Microsoft Windows XP, abaixo dele se houver x64 seu sistema é x64 (óbivo), se não houver x64, então é x32 ;)
Windows 7 e Vista: Iniciar, clicar com o botão direito em Computador, depois em Propriedades, e na janela você irá encontrar: Sistema Operacional de 32 bits, ou Sistema Operacional 64 bits.
Windows 8: Primeiro abra o iniciar, digite sistema, e logo abaixo clique em configurações, aparecerá vários resultados, clique no que diz somente Sistema, na janela que aparecer você irá encontrar: Tipo de Sistema, e na frente o tipo do seu sistema, 32 bits ou 64 bits.
Linux: Eu acho mais simples: abra o terminal e digite: uname -m, sistemas de 32 bits são: i386, i486, i586, i686..., os de 64 bits são: x86_64.
Após baixar o Eclipse, você poderá perceber que ele virá em um arquivo zip, então abra o arquivo zip, clique no diretório/pasta 'eclipse' e arraste para sua área de trabalho (desktop).
Próximo tutorial irei ensinar o básico da programação ;)
Começando pelo projeto...
JwHackingGame
Estou iniciando a programação do projeto hoje, dias 05/07/2015, vamos ver quando eu termino, estarei avisando aqui e no fórum Gamersboard quando estiver pronto, liberarei varias versões de testes conforme as coisas vão ficando prontas!
Blog
Em relação ao blog, voltarei a postar apartir de hoje, pretendo postar todo dia as 14hs, e pode ser que eu poste mais artigos no dia!
quarta-feira, 27 de maio de 2015
quarta-feira, 27 de maio de 2015
- 2 Comentarios
JwHakingGame
Estou iniciando um novo projeto, chamado JwHackingGame, ele será nada menos que um grande e complexo jogo de hacker, será lançado primeiramente para Computadores, há planos para ser lançado no Android.
O jogo terá o principio de simular uma vida de um hacker, podendo hackear várias redes, simulando o possível, iniciando com pouco dinheiro, obtendo um celular básico.
Inicio
Para hackear algum lugar deve-se antes obter uma informação, haverá simulação de ligações, onde você irá contatar a empresa e tentar extrair informações, também poderá consultar outros hackers para obter informações em troca de dinheiro, ou em troca de informações que você tenha.
Recursos
Possíveis recursos (durante as versões)
- Possivelmente compras online, para obter moedas.
- Jogo client-side e server-side.
- Versão client-side (Lado cliente): sem sincronia, tudo é perdido caso seja desinstalado sem backup, não poderá usar futuro recursos online (pvp, chat, ranking).
- Versão server-side (Lado servidor): sincronia com o servidor, salva suas informações e as mantém sempre que logar em outro jogo, poderá utilizar futuros recursos online (pvp, chat, ranking).
Inicialmente (versão alpha e beta)
- Nives de hacker (1 a 30).
- Dificuldades: Fácil, intermediário, difícil, extremamente difícil, profissional e mito.
- Cada dificuldade contém mais de 20 (aproximação) diferenciados atos hacker.
- Cada dificuldade necessita de um nível hacker especifico ou superior ao especificado.
Possíveis atos hacker (A maioria/todos será/serão implementada)
- Hackear Lan Houses
- Decodificar pulsos telefônicos.
- Invadir empresas e obter informações
- Hackear pessoas
- Hackear cartões de crédito
- Obter informações de clientes de bancos (vendo sua senha no banco, ou hackeando o local)
- Hacker pessoas importantes (banqueiros, empresários etc)
- Hackear redes sociais.
- Hackear jogos online.
- Entre outros.
Versões Release (Estáveis, pós-beta)
Nestas versões irei adicionar mais fases e atos hacker, também irá ter mais recursos, novos computadores, ferramentas, e novas formas de hackear.
Pretendo adicionar mais 50 fases, e dificuldades desafiantes.
Versões Sucesso (Se chegarmos lá)
Se conseguirmos um bom sucesso com o jogo haverá duelo de hackers (pvp, pessoa contra pessoa), valendo dinheiro, será possível hackear outros hackers, e se proteger deles.
Possivelmente será aqui que adicionaremos o modo online.
Possivelmente será aqui que adicionaremos o modo online.
Adição de modo server-side (online, lado servidor)
Desvantagens:
- Devido ao processamento pelo servidor, poderá haver um pequeno atraso.
- Não haverá migração do offline para o online (somente o contrário), porém seu jogo offline não é perdido quando jogar em nossos servidores.
Vantagens:
- Maior segurança, não haverá formas de fazer hack de moedas, já que tudo será processado pelos nossos servidores, logo todos os usuários que jogam online terão a mesma forma de evoluir.
- Equilíbrio hacking, níveis maiores que o seu, ou com mais moedas (aproximado) não podem te hacker, logo você pode hackear eles, assim mantendo o equilíbrio entre quem compra moedas, e quem joga somente conquistando as moedas.
- Maior interação com a sociedade.
BUGGY, SERÁ OPEN-SOURCE ?
Não sei ainda se deixarei código aberto, já que isto poderia afetar o projeto, mais pretendo, futuramente, se o projeto crescer deixar o código do cliente aberto, porém o servidor ainda será código fechado, poderá ser código aberto somente o servidor somente se o projeto de cliente código aberto der certo durante aproximadamente 2 (dois) meses.
Assinar:
Postagens (Atom)