| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | A pergunta que faço é curta e concisa. Qual a vantagem do java sobre qualquer outra linguagem de scripting ou de de desenvolvimento e... É assim tão lento como o fazem crer?
|
| |
| |
| | E claro que o projecto está de parabéns se passou (23 mil, fdx sao mais q as maes) todos os testes :)
|
| |
| | Qual a vantagem do java sobre qualquer outra linguagem de scripting ou de de desenvolvimento e
Falando em relação àquilo que o Java me interessa:
- É multi-plataforma, mesmo o GUI (Swing ou SWT);
- Tem uma API muito muito extensa e muito bem documentada;
- Tem uma syntax muito clara e concisa;
- Exceptions e error handling muito eficiente;
- Existem bons IDEs (livres) que auxiliam muito o desenvolvimento.
Mas claro que depende do objectivo em questão. Se fosse para fazer o motor gráfico de um jogo, seguramente optaria por C++, dado que a performance é crucial. No entanto, e porque sei menos de C++ e porque a considero mais complicada, levaria bem mais tempo a fazer aquilo que faria em Java.
Quanto ao scripting (web services), poderia usar JSP em detrimento de PHP, mas prefiro, para a maioria das tarefas, o PHP, pela excelente documentação e suporte. No caso do aplicações server-side para web services, aí talvez já recaíria no Java outra vez para os servlets.
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
| | php e excelente documentação.... hmmmmm nope. foi-me mais útil o google para construir um XML de RSS para o blog que a documentação em modo wiki da Zend.
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | - Existem bons IDEs (livres) que auxiliam muito o desenvolvimento.
Parece que o IDE KDevelop 3 suporta Java (para além de uma centena de outras). Já o experimentaste? Se sim, aconselhas?
Se fosse para fazer o motor gráfico de um jogo, seguramente optaria por C++, dado que a performance é crucial.
Olha que não, olha que não... O Alien Flux é um jogo cheio de efeitos gráficos espectaculares e tu nem notas que este corre sobre a máquina virtual Java.
Como o conseguem? Usando bindings de OpenGL e OpenAL. ;)
|
| |
| | Entre o KDevelop 3 e o Eclipse... epá, venha de lá o Eclipse. Tem plugins que nunca mais acabam.
Sobre jogos em Java, olha, tens o Quake II (http://www.bytonic.de/html/jake2.html) :) e o Tribal Trouble (http://www.tribaltrouble.com).
Com os bindings de OpenGL/AL, a LWJGL e o Java3D, o que não falta são opções para programação em 3D. O resto, só os benchmarks dirão se compensam ou não.
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | olha lá, e plugins para webservices, conheces? sou capaz de precisar disso, poupavas-me trabalho ;)
-----
Microsoft has funded 13 studies over the past year comparing Linux with its own products. Guess what: All of them come out in favor of Microsoft. |
| |
| | | seguramente optaria por C++, dado que a performance é crucial. Se simplificarmos o conceito de performance, performance=velocidade. C++ e velocidade na mesma frase não faz sentido. Por outro lado eu sofro de exposição prolongada a código assembly, o que me faz ter alergias e comichões só de pensar em C++...
|
| |
| | C++ e velocidade na mesma frase não faz sentido Epah essa foi para rir, espero que estejas a ser irónico!
____________________
Pedro Santos :: psantos.net |
| |
| | Por acaso não... Estima-se que o processo de late binding te diminua a performance em até 5%. Além disso, o overhead nas rotinas de gestão de memória é muito maior.
|
| |
| | O late binding -- leia-se, métodos virtuais -- são totalmente opcionais em C++. Se usas, é porque precisas ou não estás minimamente preocupado com performance. Se precisas, ou usas ou tens de os substituir por alguma coisa.
A gestão de memória é igual à que tens em C, o mais simples que podes ter num SO convencional.
|
| |
| | i love java, but...
sintaxe clara? então explica-me lá como se adiciona um elemento a um vector, é add ou put? e numa lista? pq são diferentes? pq é q n é mantida a consistência entre nomes: "Runtime" inves de "RunTime", outros q n me apetece pesquisar :P
sucinta? tenta python... em java é tipico:
for (Iterator i=c.iterator(); i.hasNext(); ) {
ClassX x=(ClassX) i.next();
i.qqcoisa();
}
sem falar na falta de um operador lambda, para n ter q declarar uma classe só para por um método a responder a um evento. and so on...
exceptions... sim, mas tens q ter metade do código a apanhar excepções que sabes que nunca vão acontecer, tipicamente com handlers q não fazem nada (má política).
quanto à performance, é boa. o início da JVM custa um bocado, mas à medida que o código é executado várias vezes, o JIT compila e optimiza o código de maneiras que nenhum compilador pode fazer. agora se gravasse isso para disco (julgo que .net se pode fazer) era interessante... n sendo, as aplicações para desktop sofrem um bocado, pois n tendem a correr durante horas e sofrem de um certo efeito de retardamento da resposta no início.
-----
Microsoft has funded 13 studies over the past year comparing Linux with its own products. Guess what: All of them come out in favor of Microsoft. |
| |
| | O operador lambda em Java não serve para nada, uma vez que as funções não são tipos de primeira ordem. Aliás, não existem funções, só membros de classes.
Mas as classes anónimas costumam resolver bem esse tipo de situação.
|
| |
| | a discussão nesse ponto era sobre a linguagem ser concisa e clara. concisa não é, nem nunca foi (por muito q andem a tentar agora com o 1.5), e clara não é completamente.
-----
Microsoft has funded 13 studies over the past year comparing Linux with its own products. Guess what: All of them come out in favor of Microsoft. |
| |
| | Comparada com a maioria.. é bem concisa e clara.
|
| |
| | x.add => para List
x.put => para Map
acho que não tem muito que enganar...
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | FINE, I GOOGLED THIS TIME!
TextField.setText();
Label.setText();
Button.setLabel();
AbstractButton.setText();
Frame.setTitle();
---
lenOfArray = myArray.length;
lenOfString = myString.length();
myList.size();
---
consistência do standard de nomenclatura:
Beans.isInstanceOf
Character.isWhitespace
Checkbox
Color.RGBtoHSB
Date.getTimezoneOffset
File.mkdirs
GridBagConstraints.gridwidth
hashCode
Hashtable
instanceof
java.lang.Runtime
java.util.TimeZone
JpopupMenu
Keymap
org.omg.SendingContext.RunTime
StreamTokenizer.whitespaceChars
System.arraycopy
---
and on and on... bem, o gajo também tem um osso para roer e faz uma comparação entre as coleções antigas e as novas, "esquecendo-se" que as velhas foram oficialmente descontinuadas.
-----
Microsoft has funded 13 studies over the past year comparing Linux with its own products. Guess what: All of them come out in favor of Microsoft. |
| |
| | O Java é rápido, o Swing é lento. Separar as águas, necessário é.
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | O Swing era mais lento do que é agora (JRE 1.4.2 e principalmente 1.5).
E claro, depois há sempre o SWT que ainda por cima é livre :-)
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
| | Epá, não sei se foi o Swing que ficou mais rápido se foi o meu processador :)
De qualquer das formas, o SWT passou a ser o meu toolkit de eleição porque para as aplicações desktop caseiras que faço, estou-me um bocado a borrifar para que a coisa não funcione que não no Linux/GTK... se alguém quiser ou abre a goela (apontando o problema que vai para a queue de TODO, ai, TODO não, AFAZER...) ou contribui com código.
Voltando ao Swing, apesar da brincadeirinha, concordo que está a ficar mais utilizável e ainda não mexi palha no JDK 1.5... está na mesma queue que o AOP.
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | | Java vs J2EE O Java é uma linguagem de programação e o J2EE é um modelo para componentes distribuidos, com mais algumas coisas à mistura. Neste caso o JBoss é um servidor aplicacional que suporta esse modelo. Se bem que podemos comparar o Java com outras linguagens C,C++,Phyton no que diz respeito ao J2EE não e assim tão claro, pois estamos a falar de um conjunto funcionalidades que neste caso não se encontram na linguagem proprimentente dita.
___________________________________ (linooks (at) zmail (dot) pt) |
| |
| | | Alguém já experimentou nevow? Pertence (ou pelo menos usa o Twisted, e é totalmente em python. Uma obra prima de engenharia, digo eu. Código compacto e perfeitamente reutilizável. Só a documentação e os exemplos é que necessitam de ser melhorados. Francisco Colaço
Deus dê saúde aos meus inimigos para que assistam de pé à minha vitória. Lema inscrito num barco bandeirante. |
| |
| | Bom, eu ontem dei de caras com o JFront e isto sim, deixou-me de queixo caído! O que eu vejo, é o Java a ficar tudo e mais alguma coisa, o AspectJ é simplesmente genial, o JFront é bestial, o hibernate é genial, o ant, o junit... são uma catrefada de "pequenas" coisas que mudam por completo a produtividade e podem reduzir a complexidade do código.
Falando em produtividade, o meu brinquedo novo é o bsh, já não vivo sem isto :(
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | É assim tão lento como o fazem crer?
Resposta curta: não.
Resposta longa: Como plataforma para aplicações servidor o Java nunca foi lento, requer alguma memória -- pouca memória == muito garbage collection == mais lento -- e nos últimos tempos (2 anos ou assim) até consegue bater em performance alguns programas nativos em aplicações com longos períodos de execução graças à Hotspot VM (especialmente com a versão servidor, "java -server").
Quanto ao desktop, nunca foi o forte do Java, pois as aplicações normalmente não correm durante períodos extensos e assim nota-se mais o impacto dos primeiros tempos de execução (overhead da JIT e falta de dados de análise do programa em execução). Mas isto também tem vindo a ser tratado recentemente e desde o 1.4.2_04 (pelo menos) tenho assistido a saltos enormes de performance nesta área, ao ponto de dizer que o Java é hoje uma boa opção nesta área -- onde a portabilidade e a maior facilidade de desenvolvimento superarem as vantagens de uma aplicação nativa, como sempre, mas agora sendo mais fácil esta situação ocorrer.
-- Carlos Rodrigues
|
| |
| | O facto de o runtime e as aplicações virem em .jar que têm de ser descomprimidos on-the-fly -- provavelmente para RAM -- também não deve ajudar.
|
| |
| | Não sei bem como o jar é descomprimido, possivelmente os ficheiros são descomprimidos conforme vão sendo necessários. Mas já agora, muito do Firefox, Mozilla e Thunderbird também está em jar (só que neste caso os jar são zips enquanto que no Java são tars) e não fica lento por causa disso. Se por um lado consomes CPU, por outro tens de ler menos do disco.
-- Carlos Rodrigues
|
| |
| | Oops, mentira, são ambos zips só que o comando jar tem uma sintaxe semelhante ao tar...
-- Carlos Rodrigues
|
| |
| | CPU, I/O, RAM/swap...
Sempre me perguntei porque é que a JVM não usa um daemon para gerir uma cache de ficheiros .java e depois faz simplesmente mmap() dos .java.
Aposto que pelo menos diminuia muito aquela impressão de os programas de java levarem muito tempo a abrir e poupava um bocado de memória a quem tem várias aplicações em java a correr ao mesmo tempo.
|
| |
| | Duvido que a descompressão do .jar seja feita a pedido, isto é, quando quer a classe XYZ vai buscar a dita ao .jar. Deve ser mais do tipo, carrega o .jar para memória e descomprime o bicho quando estiver a arrancar.
Isto resulta na tal cache de que falas.
O footprint de memória, pode ser controlado pelo utilizador. Nem faço ideia de quanto é o default heap size mas posso mandar uma posta de pescada e dizer que são 32mb.
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | Isso não sei. Seria viável extrair ficheiros .class conforme necessário. Os .jar são .zip e permitem que isso seja feito eficientemente. Mas uma vez que a JVM precisa de verificar a disponibilidade das classes necessárias quando a aplicação arranca, o mais provável é acontecer como dizes.
Contudo, indedentemente da tática de extracção, a verdade é que cada cópia da JVM tem de extrair os .class que necessita e ocupar memória com os mesmos.
A cache que eu falei não era em memória mas em disco. Uma cache de ficheiros .class, extraidos dos .jar, gerida por um serviço do sistema. As JVM poderiam então mapear em memória os .class que necessitam.
Evitas que múltiplas invocações da JVM percam tempo a descomprimir classes e evitas que múltiplas invocações que coexistem desperdicem ocupem memória com múltiplas cópias das mesmas classes.
|
| |
| | Mas uma vez que a JVM precisa de verificar a disponibilidade das classes necessárias quando a aplicação arranca,
Isto não é assim... a JVM só verifica se a classe existe quando alguém a vai usar pela primeira vez.
Pelo que li, a JVM 1.5 (oh Paulo, desculpa mas não lhe vou chamar JVM 5! ;-)), já faz o share das classes pelo que suponho que uma JVM possa executar várias aplicações. Alguém já experimentou?
O .jar é um bocadinho mais que apenas um zip com um monte de .class lá dentro... senão o pessoal só usava um .zip que depois podia descomprimir para um directório e usar este directório directamente no CLASSPATH. Um .jar pode conter as dependências (outros .jar) e no MANIFEST.MF podes indicar N parâmetros para a JVM (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#JAR%20Manifest).
A questão de várias JVM a correr, é algo que faz um bocado de confusão a muita gente, mas se vires bem, até faz sentido porque uma JVM é uma sandbox (eu gosto de lhe chamar playground :))... Essa sandbox é melhor compreendida quando lhe aplicas uma série de parâmetros no SecurityManager. uh?! Security Manager?! Yep, Security Manager :) É útil, por exemplo, olha, para um utilitário da treta que estou a fazer e que usa plugins. Este utilitário quando arranca, instala um securitymanager onde defino que a aplicação só pode escrever num determinado directório e só pode ler de um determinado directório. Não pode abrir sockets à parva, não pode carregar .jar's (plugins) que não estejam signed, etc...
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | fico com a sensação de que a conversa ficou a meio, mas a esposa está a chamar por mim :) anyway, podemos falar melhor sobre o assunto no IRC um dia destes...
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | A disponibilidade da classe tem de ser verificada cada vez que a aplicação arranca, tal como a disponibilidade de um DSO (lib) tem de ser verificada cada vez que a aplicação arranca.
Quanto ao sharing de classes entre várias JVMs no 1.5, estou a usar um beta e não vejo sintomas disso (memory maps ou segmentos de memória partilhada).
Quanto à natureza do .jar ser um .zip, só a referi porque o .zip/.jar permite extrair eficientemente ficheiros do meio do arquivo sem ter de processar os anteriores (por oposição a algo como um .tar.gz por exemplo).
De qualquer forma, não tenho nada contra ter várias JVMs a correr. Acho muito bem. Só acho que elas poderiam partilhar os recursos relacionados com a descompressão dos .jar e que o que sugeri seria uma boa forma de o fazer.
|
| |
| | O Java não procura os .class quando a aplicação arranca, apenas quando a classe pública que eles definem é necessária pela primeira vez, o carregamento de .class é on-demand.
-- Carlos Rodrigues
|
| |
| | Argh, tens razão. Java acabou de descer uns pontos na minha consideração.
|
| |
| | http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html :)
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | | Partilhar a memória de classes é essencial ao bom desempenho da máquina. Diminui o tempo de arranque da segunda execução e pode catapultar a máquina virtual de java para o cliente. Se tivesse um desejo para a Intel/AMD/Via, era que incorporassem instruções microjava no microcódigo do x86. Francisco Colaço
Deus dê saúde aos meus inimigos para que assistam de pé à minha vitória. Lema inscrito num barco bandeirante. |
| |
| | isso sim, é wishfull thinking :)
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | Se tivesse um desejo para a Intel/AMD/Via, era que incorporassem instruções microjava no microcódigo do x86.
Se existiam processadores a incorporar código Prolog para Inteligência Artifical, quem sabe não faltará assim tão pouco para incluirem código Java :-)
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
| | | O ARM com as extensões gazelle (acho que era este o nome). Ou achas que é coincidência que o código JAVA corra tão depressa nos IPAQ? Francisco Colaço
Deus dê saúde aos meus inimigos para que assistam de pé à minha vitória. Lema inscrito num barco bandeirante. |
| |
| | The managment is impressed.. :)
|
| |
| | hu?
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| |
existe algum site portugues dedicado ao java ?
genero www.guj.com.br, www.j2b.com.br etc...
|
| |
| |
| | | existe o www.java.pt mas aquilo anda um beca parado !!!
___________________________________ (linooks (at) zmail (dot) pt) |
| |
| | acho que o java.pt nunca arrancou... todos os posts que lá andam, são da altura da conferência da Sun na FIL, portanto, T.d.M.
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| |
é estranho, o java esta em crescente expansão, e em PT o java não parece estar a cativar mt gente...
apesar de grandes empresas ja usarem o java em termos de aplicações web... e não só...
|
| |
| | o java está em expansão de facto, por isso dá-lhe mais um ano para chegar a Portugal a onda de choque. Até lá, a malta surfa mais no .Net.
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | Bem, felizmente no meu curso a tendência é mesmo para o Java em muitas cadeiras, sendo o .NET a excepção :-)
Curiosamente a primeira onde é leccionado o .NET (Base de Dados: SQL Server, .NET e IIS......) é dada por um docente de Gestão e Engenharia Industrial, sempre de fatinho, que tem aspecto de trabalhar na Microsoft... :-)
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
| | | Em relacção ao .NET, no mundo Java infelizmente ainda n existe nada comparado ao ASP.NET. O JSF nem sequer ainda está muito estável!!
___________________________________ (linooks (at) zmail (dot) pt) |
| |
| | Em relacção ao .NET, no mundo Java infelizmente ainda n existe nada comparado ao ASP.NET.
JSP e Servlets?
Como não conheço muito do ASP.NET (já programei em ASP 1.0/1.1. Lento como tudo..), gostaria de saber o que é que o ASP.NET tem que não possa ser feito em Java!
Obrigado desde já pela esclarecimento.
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
| | | Ser aprovado, sancionado e abençoado pela omnipotente, omnipresente Microsoft. Deixo o omnisciente para outra entidade, cujos favores prefiro, por falar nisso. E, acima de tudo, poder dizer: eu sou um incomptente, pois uso software Microsoft. Satisfeito? ;-) Francisco Colaço
Deus dê saúde aos meus inimigos para que assistam de pé à minha vitória. Lema inscrito num barco bandeirante. |
| |
| | estás bastante equivocado... a comparação correcta é: nada no asp.net se compara ao java! Para programação web, tens Servlets, tens JSP e tens Struts que não é bom, é excelente. A isto podes juntar um aplication server como o JBoss ou outro qualquer que aches apropriado. Podes usar simplesmente o Tomcat, conforme preferires. Aliás, esta dos application servers só por si, é o espelho das diferenças do mundo do Java e do .Net... Então o JBoss tem cada vez mais componentes que deixam uma pessoa assim: aaaahhhhhhhh!!!! ;-) <limpando baba>
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | | Struts que não é bom, é excelente Tou a usar a framework Struts e podo dizer com toda a certeza que o Struts está longe de ser bom Comparação correcta é: JSF == ASP.NET, JSF -> SUN SUN -> JAVA.
___________________________________ (linooks (at) zmail (dot) pt) |
| |
| | Vou dar o benefício da dúvida, porque o meu conhecimento de Struts é do papel.
Mas tenho de perguntar onde achas que o Struts falha?
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| |
| | tendo em conta o número crescente de fanboys da MS, aconselhava-te a n deixares muitas cadeiras para trás e a saires de lá depressa ;)
-----
Microsoft has funded 13 studies over the past year comparing Linux with its own products. Guess what: All of them come out in favor of Microsoft. |
| |
