Mensagens enviadas por: rmendes08

Só perguntando para o admnistrador para saber, mas a JVM da antiga Sun, o Hotspot é de longe a VM mais usada.

é ... já que você não leu ... a resposta é sim, você pode inclusive desenvolver toda uma aplicação JEE para desktop.

Definitivamente não. Atores de maneira geral são agentes externos ao sistema que está sendo modelado, podem ser pessoas, equipamentos ou até mesmo outros sistemas, mas tenha em mente que eles são externos.

alana.gim wrote:Ola pessoal, tive uma aula de java e o professor falou que em 99% dos casos atributos de uma classe devem ser private. Porem eu nao entendo como isso pode ser se geralmente classes estão vinculadas com outras e, usamos seus atributos. Alguém pode me explicar?

Usar atributos de outra classe é um equívoco. Classes devem usar comportamento de outras classes, e não atributos. O ideal é que os atributos sejam usados para manter o estado de um objeto, mas apenas como um suporte para o seu comportamento.

rbcastro wrote:Com a experiência que tenho com Delphi meu parecer é o seguinte:

Só há necessidade de ser iniciar um bloco quando o mesmo for executar mais de uma ação:

Vejamos o exemplo do nel:

boolean teste = true; if(teste) for(String value : lista) for(int i = 0; i < lista.size(); i++) if(!teste) System.out.println("Fim do laço!"); else System.out.println(value);

Nesse caso se não for aberto um bloco na primeira condição e if (teste) = false, o segundo é quem será executado e isso com certeza fica confuso de compreender o que está acontecendo.

Acontece que no Delphi a abertura de blocos é muito verbosa. Geralmente identa-se o begin-end e depois identa-se novamente o bloco de comandos. Isso de fato torna o código poluído. Mas no caso do Java e linguagens com sintaxe C-like, as chaves tornam o código mais leve, além de que pode-se abrir a chave na mesma linha do if ou for, sendo assim, não fica muito caro, em termos visuais, abrir um bloco de chaves mesmo para um comando só.

Cara, você vai ter quer fazer 2 trabalhos que exigem equipes enormes:

1 - implementar um kernel próprio

2 - implementar uma JVM para o seu kernel

Eu imagino que esse trabalho lhe trará muita satisfação pessoal para você abrir mão do que já está pronto.

Não se instala o JEE. JEE nada mais é do que um conjunto gigante de especificações. O que você tem são produtos que implementam uma determinada especificação. Exemplos de especificações são: Servlets, JSP, JPA, EJB. Produtos que implementam JPA por exemplo: Hibernate, TopLink, etc.

De qualquer maneira, todo produto JEE é construído sobre a JSE, que é a linguagem Java + API's padrão. Ou seja, de um jeito ou de outro você precisa instalar a JDK, e a princípio, a JDK é tudo o que você precisa para desenvolver qualquer aplicação Java. O resto são atalhos e facilitadores.

alandiniz wrote:Bom aproveitando o tópico podemos discutir qual a melhror opção. Eu fiz o seguinte.

Criei uma entidade chamada config com alguns atributos tipo, "nomeDoSite", "versao", etc...

criei um ConfigBean do tipo ApplicationScoped que faz requisição no banco de dados e traz estas informações...

e nas paáginas eu chamo o #{configBean.config.nomeDoSite}

será que essa forma é ruim?

De maneira alguma, isso funciona muito bem. Mas nesse caso, essa é uma boa solução para quem está usando JSF e um banco de dados. Para o colega do post, não é viável ele migrar toda uma aplicação de framework por conta disso.

Antes de mais nada, que tecnologia você está usando ?

Se você está usando Servlet's você pode especificar um parâmetro no seu web.xml:

daí você pode recuperar o parâmetro pelo ServletContext:

ou em uma JSP:

Agora, se o atributo que você quer guardar é mais complexo que uma String ou número, por exemplo, um objeto do tipo Usuario você pode escrever um SerletContextListener e no método contextInitialized você cria o seu objeto e seta ele no ServletContext, para usar fica muito parecido.

Putz, foi mal, confundi os termos ...

GLEMES wrote:Discordo de vc rmendes08!! O tipo de REFERÊNCIA determina qual método sobrecarregado será usado em tempo de compilação e não em tempo de execução como em um teste IF. Portanto vinids, use instanceof ou o equals para testar se uma determinada classe passa no teste É-UM. Porém teste as referências e não FucnionarioEnsinoBasico.class.

Flw!!

Veja bem GLEMES, acho que você não entendeu. Para você acessar um método é preciso que ele esteja declarado no tipo de referência da variável (ou expressão) e que ele seja visível (public, protected, etc.). Uma vez que o método é acessível pela referência, a versão que de fato vai executar é a versão declarada no tipo da instância referenciada. Caso fosse diferente, se você chamasse um método por um refeência cujo tipo é uma interface você receberia um erro, pois interfaces não definem implementação, sacou ? Exemplo:

execute o código acima e você vai entender.

Bom, se tem futuro eu não sei, mas a Oracle não abandonou a tecnologia e continua investindo nela. Não sei se vale a pena para a Web, pois os arquivos ficam gigantes para uma interface Web, mas para desktop eu acho que vale a pena, pois é mais bonito que o Swing. Se eu não me engano, JavaFX vai ser o padrão para interfaces no Java 8.

rafaspimenta wrote:

ironmarq wrote:...acho que vc quis dizer se criar uma referência da classe filha e instanciá-la como pai, não é isso?

Se eu tentar criar uma ref. da classe Filha e instancia-la como Pai, dá o seguinte erro:
Filha fp = new Pai(); //Type mismatch: cannot convert from Pai to Filha acho que para fazer isso teria que ser através de cast.

Continuando, fiz os seguinte teste:
public class TestInherited{ public static void main(){ Filha ff = new Filha(); Pai pf = new Filha(); ff.metodoPai(); //OK ff.metodoFilha(); //OK pf.metodoPai(); //OK pf.metodoFilha(); //The method metodoFilha() is undefined for the type Pai }
Bom, sinceramente n entendi pq o compilador levantou essa excessão.
Achava que por ter instanciado meu objeto pf como Filha, teria acesso a todos métodos da mesma. Alguém pode me explicar?

Não. O que define o acesso a um método/membro é o tipo da variável, e não o tipo da instância. O tipo da instância por sua vez define a implementação do método que será invocada. À primeira vista isso é uma limitação, mas na prática, aí é que está a mágica do polimorfismo. O fato de você acessar os método de um objeto pelo tipo da variável e não pela implementação permite que você escreva métodos em termos de um contrato de interface sem antes mesmo ter uma classe que a implementa. Um exemplo prático é o JDBC. Praticamente, tudo no JDBC são interfaces e você as usa em termos genéricos. Assim, você pode escrever um programa todo que usa acesso a dados sem se preocupar com as peculiaridades de cada um.

Vingdel wrote:Olá, rmendes08!
Isso eu tenho que entender também, então não tem diferença entre esse dois caso?

Pai p = new Filha(); Pai p2 = new Pai();

Mas e se, no primeiro caso, o construtor da classe Filha (afinal ele é o responsável pela no instância), por acaso, fizer uso de um método da classe Filha, vai dar PAAAAAAUUUU?

Abraço!

Não, vai funcionar perfeitamente porque o construtor da classe pode acessar qualquer método/membro da classe, seja ele static ou não.

se você estiver no windows, provavelmente o que acontece é que você executa com duplo-clique, o programa funciona e fecha na mesma hora. Execute pelo prompt de comando que vai dar certo.

Notícias, artigos e o maior fórum brasileiro sobre Java