Mensagens enviadas por: Daniel Quirino Oliveira
Índice dos Fóruns » Perfil de Daniel Quirino Oliveira » Mensagens enviadas por Daniel Quirino Oliveira
Autor Mensagem
já que a Vanessa tocou no assunto "java performance", acho curiosa (no mínimo) a leitura deste documento: http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
não sei qual tipo de aplicação você quer, mas no site http://www.gotocode.com você consegue os fontes de alguns aplicativos JSP bem simples.
<ponto_de_vista_pessoal>
você quer aprender Java ou quer aprender a "mexer" com Java? Se quiser optar por aprender Java, não comece usando IDEs. Use o bom e velho notepad/vi. IDEs viciam os iniciantes fazendo com que se aprenda muito mais sobre a IDE em si do que sobre a tecnologia Java (que deveria ser o foco).
</ponto_de_vista_pessoal>
E para desenvolver, use o SDK e não o JRE
Opa!! Pode contar comigo!!!
obrigado Luiz e Dukejeffrie...
se quiserem ver a continuação deste debate, eu e o Fábio Galuppo (DotNet Specialist) estamos dando prosseguimento a ele, mas mantendo o alto nível que nós, programadores profissionais, devemos ter. Eis as urls:
.NET vs. Java: http://www.msdnbrasil.com.br/forum/ShowPost.aspx?PostID=1080&PageIndex=2.
Portabilidade: http://www.msdnbrasil.com.br/forum/ShowPost.aspx?PostID=6210

Até...
particularmente gosto muito deste: http://rzserv2.fhnon.de/~lg002556/struts/
em algum ponto do arquivo server.xml (TOMCAT_HOME/conf/server.xml) troque
<Context path="/"
docBase="ROOT"
debug="0"
reloadable="true"
crossContext="true">
</Context>

por
<Context path="/"
docBase="meuapp"
debug="0"
reloadable="true"
crossContext="true">
</Context>

o atributo "Context path" é relacionado ao sub-domínio em que vai estar localizada sua aplicação, isto é: se vc tem um aplicativo cujo nome seja "meuapp", seu dominio seja "meusite.com.br" e o valor do Context path é igual a "meuapp", então você vai acessar sua aplicação através do endereço "www.meusite.com.br/meuapp" (considerando que você mudou a porta em que o tomcat estará servindo para a porta 80).
já o atributo "docBase" se refere ao diretório físico em que seu aplicativo está instalado dentro do diretório TOMCAT_HOME/webapps.

maiores informações aqui: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html

esclarecimentos:
- sei que peguei pesado, por isso, desculpem-me;
- sei que fui muito rigoroso no que se trata de português, mas prefiro maltratar o menos possível a nossa língua. Mas também não humilho ou desprezo (embora o que tenha escrito diga o contrário) alguém por escrever errado ou usar abreviaturas do tipo "vc" "eh", etc (mesmo porque as uso com muita freqüência em IM);
- concordo que para se discutir "Java vs. .NET" deve-se, primeiro finalizar este tópico e depois ter certeza de que coisas cosmésticas não vão ser discutidas, como por exemplo a discussão do "objeto.prop = 1; ou objeto.setProp(1);?";
- minha memória não é tão boa assim ;
- sobre ética, acho que todo mundo fala mal do projeto de alguém quando ele não nos agrada. Mas dizer isso publicamente, principalmente quando o nome do autor do projeto já tinha sido divulgado, é, pelo menos, uma falta de educação e respeito com o autor. Vale sempre ressaltar que, um dia, todo nós já escrevemos códigos ruins e se nós melhoramos, foi porque várias pessoas nos ajudaram.

that's all folks...

p.s.:
Aonde está a Sun? Ela não faz parte do WS-I... (DotNet Specialist)

faltou dizer ao DotNet Specialist que a Sun faz parte da WS-I. Para não restar dúvidas, cá está: http://www.ws-i.org/Community.aspx?Alpha=S
Agora fica só uma dúvida: quem será que escreveu isso? o Paulo mesmo ou o lado "Tyler Durden" dele?
se não fossem os erros de português nos comentários, eu chutaria que o nosso caro NotYet Specialist é o nosso colega Mauro Sant'anna, MSDN Regional Director. Mas não vamos discutir isso, vamos ao que interessa de fato:
Pelo menos acha alguma coisa... Com relação aos generics compare primeiro antes de falar ... a versão Java não passa de macro substituição!!! A versão de generics da MS está intrinsica na CLR o que garanti otimização através do JIT... http://research.Micro$oft.com/~dsyme/papers/generics_abs.htm (NotYet Specialist)
.
1. Backward compatibility. Enquanto Java2 se chamar Java2, todo e qualquer programa escrito para plataforma VAI ESTAR dentro da filosofia "write once, run anywhere". Quando a tecnologia avançar para a versão 3, aí a história vai ser outra. Porém, como é muito bem sabido, a transição da versão 1.0 para a versão 1.1 do .NET Framework forçou que alguns (vários) projetos tivessem que ser recompilados para trabalhar adequadamente sobre o CLR antigo (http://www.3leaf.com/default/articles/ea/SBS.aspx). Você não acha isso impressionante? (nota: isso é uma pergunta retórica, se você não entendeu...)

Bem... O MSDN Forum é exatamente o tipo de aplicação que não deve ser escrita em da forma que foi em nenhuma plataforma... (NotYet Specialist)

1,5. só dois comentários: primeiramente, a educação e a ética profissional mandam lembranças, viu? Em segundo lugar, que tecnologia usaram para que tal aplicativo merecesse tal crítica? raw ASP?

>> Plataforma .NET por ser nova roda em toda família de SOs da MS (com exceção do Win95, NT 3.21, CE 3)... A CLI roda no MacOS X, FreeBSD e são simplesmente para provar a portabilidade e não para comercialização.. Outras iniciativas como o Mono (Linux), Intel (Unix), HP (Unix) estão caminhando... Veja por outro lado... ao invés da MS fazer CLRs meia-boca para todas as plataformas assim como a Sun faz (vide o problema da JVM com Solaris), ela forneceu as specs para que outros fornecedores implementem a CLI para suas plataformas... Ao invés de ficar atacando a MS, somente, pq vc não questiona outras empresas de SO tais como IBM (Aix), QNX (QNX OS), Palm (Palm OS), Apple (Mac OS X), ... para implementarem... Ou vc prefere JVMs escritas por um único fornecedor (mesmo levando em conta que outros fornecedores fazem JVM... Que alias a JVM da MS foi premiada várias vezes pela Sun...) (NotYet Specialist)


2. Antes de tudo, é verdade que a Microsoft soltou uma versão para o .NET Framework 1.0 para FreeBSD. Esta implementação se chama Rotor e está em algum lugar do site da MS para ser baixado. Agora, vamos à realidade das implementações .NET para SOs não-windows. Para começar, o licenciamento do rotor diz basicamente o seguinte (ou seja, isso é uma síntese): aplicações usando o .NET Framework e que tenham sido escritas e compiladas na plataforma Windows não poderão ser usadas para fins que não acadêmicos em implementações deste Framework para outras plataformas de sistema operacional. O uso da versão do .NET Framework para FreeBSD se destina unicamente para finalidades acadêmicas. Outstanding, don't you think so?
Enfim, o .NET Framework rodando no FreeBSD (se alguém tiver um FreeBSD por aí, recomendo que façam um teste, é muito engraçado) é um desastre. Peguei uma aplicação WindowsForms já pronta, construída no VS.NET e a coloquei para rodar em ambiente gráfico (óbvio! mas só para constar, o ambiente gráfico usado foi o Blackbox). Resultado: uma grande decepção, já que os componentes do form saíram todos mal dimensionados (ok, pode ser problema no blackbox) e vários eventos programados ou não eram executados ou lançavam aquele diálogo de exceção. Ainda não testei no OSX, mas já que existe tal versão do framework, vou testá-la. Mas, antes, só uma pergunta: se .NET é portável, por que um projeto não consegue rodar efetivamente em outra plataforma diferente daquela onde ele foi compilado?
Outro ponto importante a ser levantado: quando se fala de .NET, costuma-se englobar as linguagens-padrão (VB.NET, C#.NET, C++.NET, J#.NET), as APIs (System.XML, Windows.Forms, ...), as tecnologias associadas (ASP.NET, SmartClients, WebControllers, etc..) e o CLR. Ignorando o fato de não ter conseguido rodar corretamente um projeto WindowsForms no FreeBSD, como eu faria para rodar meu projeto ASP.NET sobre o Rotor sendo que ele é altamente acoplado ao IIS (que por sua vez só funciona em ambientes Windows) ?
Mudando um pouco de alvo, tocou-se no ponto das JVMs. A comunidade Java já está careca de saber, mas para quem é de fora é bom explicar: toda a tecnologia Java (incluindo aí JVM, JRE, J2EE, J2ME, JDO, ...) é pura especificação, criada pela JCP. JCP (Java Community Process) é uma entidade INDEPENDENTE, sem FINS LUCRATIVOS e FUNDADA pela Sun Microsystems para poder regular e especificar tudo que for referente a esta plataforma. Esta comunidade é formada por empresas do calibre de Hewlett Packard, IBM, Oracle, Borland, Fujitsu, Siemens, General Eletric, Nokia, Motorola, Sony, Ericsson, Phillips, Accenture e por aí vai; no seu início, até a Microsoft fazia parte da JCP e ela foi a responsável pela criação das melhores VMs para Windows enquanto esteve lá (isso é outra história). Porém, não existe só VMs feitas pela Sun. A Sun é responsável pela criação das VMs mais populares. Ela cria VMs para win32 e win64, SolarisOE e linux32/64 (aliás, tal VM é resultado do trabalho entre JCP e comunidade Open-Source - Blackdown). Mas se você achar que as VMs da Sun são muito "meia-boca", você pode instalar a implementação da BEA (JRockit), da Oracle (Aurora), da IBM... Você pode até mesmo fazer uma fusão de VMs, ou seja, usar a VM da Sun junto com o JITer da BEA, ao invés do Hotspot. Com todas estas características, dizer que o trabalho da JCP (e não da Sun) é tão ad-hoc como foi citado só demonstra 3 coisas: imparcialidade, falta de visão estratégica e de conhecimento básico sobre a plataforma Java. (p.s.: pergunte-se o porquê o pessoal do projeto Mono até hoje não ter uma versão estável para a API Windows.Forms. E pergunte-se também o porquê da necessidade de emulação por Wine http://www.go-mono.com/winforms.html).

pausa para tomar água...

Programador fica responsável pelos seus atos sempre! Ou afinal vc é mais um lobbista do que um desenvolvedor... O C# usa unsafe em 2 níveis (na instrução e na compilação) para utilização de ponteiros e isto não é mais perigoso do que fazer cagadas com JNI... (NotYet Specialist)

3. JNI... andou fazendo lição de casa, hein? Pois bem, JNI é a ponte entre Java e o mundo das bibliotecas nativas. Normalmente JNI é usado para que uma certa aplicação Java acesse funções implementadas nestas bibliotecas nativas que vai prover ao aplicativo acesso direto a recursos de hardware, como uma impressora. Se não estiver enganado (sorry, nunca precisei implementar nada que precisasse de recursos nativos da plataforma), as únicas coisas que o programador Java é obrigado a fazer são criar uma interface em C (blabla.h) para o driver da impressora (possibilitando, assim, que o objeto Java acesse os métodos/funções do driver) e "registrar os nativos" na classe que vai acessar o driver. Ponto final. O programador não vai brincar com os "unsafe types". Se houver algum erro devido a estes tipos, vai ser erro na implementação do driver, o que, convenhamos, é um pouco difícil de ocorrer.
Mas se isso não convencer que JNI é menos "error-prone" do que usar "unsafe types", pode-se explorar um modelo um pouco mais complexo, mas mais escalável que é a arquitetura CORBA (que, se não me falha a memória, não é suportada pela plataforma .NET).


>> O problema do Java é que ele é intrinsico a ele mesmo... O poder do acesso das bibliotecas do .NET Framework são estendidos para qualquer outra linguagem da plataforma, isto inclue COBOL.NET, Perl, Eiffel e outras. Álias as classes de XML do Java nem se comparam a System.Xml, isto só pra começar... nem vou falar de Code Access Security, Remoting e Windows Forms (NotYet Specialist)

4. Para a primeira parte, só duas palavras: AspectJ e Jython.
Sobre linguagens interpretadas (com Perl, Ruby e Python), que tal: http://www.freeroller.net/page/ceperez/20021205#net_clr_unsuitable_for_interpretive
Sobre XML, JDOM (open-source) faz as mesmas coisas que as classes do System.XML fazem. Então, tanto faz um quanto outro.
Sobre Code Access Security: se puder explicar, agradeço.
Sobre Windows.Forms, eu nem vou citar Swing, que é de fato portável. Vou falar de SWT, um novo conjunto de componentes para construção de "forms" que alia a portabilidade do Java com a agilidade de renderização que componentes GUI nativos possuem. Ahhh!! E qual é a outra API para desktop GUIs no .NET?


>> Javadoc padrãO ? Imagino que não seja mais "padrão" do que XML da W3C (NotYet Specialist)

5. <sarcasmo>De fato, HTML deixou de ser um padrão W3C e virou um padrão Microsoft. Tim Berners-Lee deve estar muito triste.</sarcasmo> Ironias à parte, documentação é algo para ser visto e navegado, e não manipulado. Então, para quê documentação em XML? Ok, pode-se considerar que, uma vez em XML eu poderia gerar, usando XML Stylesheet Transformation Language (XSTL), documentos em PDF, PS, Word, HTML... Mas qual costumava ser o sinômimo para HIPERTEXTO (e não documento) portável?


>>Inclusive é muito interessante o GUJ ser feito em PHP... Onde estão os JSPs e Servlet... Casa de Ferreiro, Espeto de Pau (NotYet Specialist)

6. Se isso é realmente importante para você, considere que o Hotmail rodava CGIs sobre FreeBSDs até pouco tempo atrás (http://www.securityoffice.net/mssecrets/hotmail.html). E considere também que o site da filial da MS no Reino Unido (se não estou enganado) rodava sobre um belo IBM Websphere 3 (camulflando as extensões .jsp para .asp).


>>Realmente o artigo é péssimo! Se vc quiser consistência... Antes de vc e seus colegas de DL me sairem me xingando... seria bom ler um artigo com base para comparações... (http://genamics.com/developer/csharp_comparative.htm) (NotYet Specialist)

7. Sinceramente: nós, da comunidade Java, já estamos de saco cheio destes comparativos com fins explicitamente publicitários feitos por MSDN-RDs, "Microsoft Certified qualquer coisa"'s. No final de tudo, sabemos que Java é melhor por zilhões de coisas que os programadores .NET nem sabem que existe. Quer persistência transparente sobre qualquer tipo de fonte de dados? Tome JDO, Hibernate, OJB. Quer framework para testes? JUnit, HttpUnit. Cansou-se de OOP? Que tal AOP, usando AspectJ ou AspectWerk? Protocolo para comunicação p2p? JXTA! Componentes distribuídos como serviço? Jini. Um protocolo RPC-style? Java RMI. Automatização de tarefas? Ant!! Droga, odeio esta IDE... Mude para JBuilder, Eclipse, Forte, Netbeans, IDEAJ, Together, Rational XDE, WSAD, JDeveloper ... Qual banco de dados usar para alcançar máxima performance? MySQL, PostgreSQL, Firebird (estes gratuitos), Oracle9i, SQLServer 2000, IBM DB2, Sybase, Ingres, isto é, qualquer um ... Ahhh banco de dados é coisa do passado? Prevayler!!! Utilidades para protolocos de rede? Jakarta Commons!! Reconhecimento de voz? JavaSpeech. Multimedia? JavaMedia Framework. Infra-estrutura para telecom? JAIN. Não gostei da linguagem Java, mas acho a API muito rica e gostaria de usá-la: Jython.org!! Frameworks para aplicações para web usando padrão arquitetural MVC? Struts, E-gene, Tapestry. Portlets? Jetspeed, Oracle PDK. Tem "ASP.NET" para Java? JavaServer Faces!!! E framework para agentes? Aglets... E para IA ou sistemas especialistas? JGAP, Joone, Jess. Relatórios? Jasper Reports, JFreeReport. Logging? java.util.logging, Log4J. E SmartClients para Java? Sim, JavaWeb Start.
Alguma coisa mais?

ahh sim, a última citação:
Com relação as listas MS, se vc entrar lá vai ver que o pessoal que começa com este papos furados de comparação vai logo sendo cortado... Aliás acreditar que nas DLs da MS fica rolando este tipo de coisas é mais uma lenda... (NotYet Specialist)

8. O que mostra o nível dos frequentadores de cada lista. Aqui nós não somos vaquinhas de presépio de nenhuma grande empresa. Além do mais, todos aqui gostam de discutir tecnologia (seja ela qual for); assim, sempre que surge mais um panfleto sobre as "inumeráveis e substanciais" vantagens do .NET/C# sobre Java gostamos de expor nossa sincera opinião (i.e. fazer piadas!!). E, embora você vá discordar, criticamos muito a tecnologia Java quando necessário (ver tópicos http://www.guj.com.br/forum/viewtopic.php?t=2320 e http://www.guj.com.br/forum/viewtopic.php?t=2339). E tudo isso só mostra uma coisa: o alto nível de maturidade e qualidade de nossa comunidade.

Para terminar, alguns links interessantes:
mito da portabilidade do .NET: http://www.neward.net/ted/weblog/index.jsp?date=20030130#1043955918414
JVM vs. CLR: http://www.freeroller.net/page/ceperez/20021209#net_clr_slower_than_most
RegExp benchmark: http://www.freeroller.net/page/ceperez/20030210#p_i_found_a_a
quanto ao receio de algumas empresas estarem usando projetos OpenSource, isso vem diminuindo, pois empresas como IBM, SUN, BORLAND entre outras estão apoiando e usando iniciativas OpenSource. (Richardson)

Aham. JSF é praticamente uma fusão de JSTL + Struts.
Eu não tenho receio algum de usar qualquer framework OS nos meus projetos, desde que eles sejam perfeitos no quesito "faça tudo o que eu quero fazer de maneira mais fácil e produtiva". Tanto é que alguns deles eu acho imprescindível, como Hibernate/TJDO, AspectJ (estou vendo o Aspectwerks, que o Carlos tanto adora), log4j. O que eu quis dizer com
acho que algumas coisas como Velocity e o Webwork sào uns exageros. JSP+JSTL (ou, o JSP 2) geralmente dão conta do recado
é que nem sempre vc precisa recorrer a frameworks para se ganhar em produtividade. Claro, este lance de produtividade tem muito a ver com a familiaridade do programador com determinada ferramenta, mas não creio que seja preciso aprender uma nova ferramenta/framework/o que for pois há muitas coisas no "bare j2ee" podem ser uma grande mão-na-roda.
Por exemplo: Só pq um sistema foi feito em JSP, todo em scriptlets com um código macarrão, não quer dizer que o jsp é ruim, a culpa é únicamente de quem resolve desenvolver assim. (Richardson)

Respondendo: não. Diria, acho que como a maioria, que ruim não é a tecnologia usada (JSP no caso do exemplo, EJB no caso da discussão) mas quem a usou não sabia como usá-la. E é isso que quero dizer quando digo que em 90% dos projetos, usar EJB é matar mosca com tiro de canhão (nota: esta frase tão usada é do filósofo chinês Confúcio). Mas, como eu disse em síntese no tópico "Morte aos EJBs", na seção J2EE, é um radicalismo dizer que EJBs não prestam e são só puro marketing. Mas acho que deveriam realmente usá-los só quando fossem necessários.
E por enquanto chega...


why not?





documentação: http://java.sun.com/j2se/1.4.1/docs/api/java/io/ObjectInputStream.html

e isso é tudo, p-pessoal
No Java, não existe passagem por valor para objetos, só por referências... logo, tudo que tem numa Collection é referência... (Carlos Villela)

acho que não é bem assim, Carlos. Em java, tudo é passado por valor, desde tipos primitivos até objetos. O que acontece com os objetos, é que o que é copiado é o endereço de memória do objeto (alguns consideram isso passagem por referência, mas pra mim é passagem por valor). Olha só (desculpa a identação):

public class testeObj{

public static void main(String argv[]){
Object o = new Object();
System.out.println(o); //* saída: java.lang.Object@defa1a
Object outro = o;
System.out.println(outro); //* saída: java.lang.Object@defa1a
//só para testar...
System.out.println(o==outro); //true
System.out.println(o.equals(outro));//true
}
}

Mais simples, só "hello world". Mas, quando fazemos "outro = o;", o que é copiado é o valor de "o", que é uma referência (lembre-se de que em Java, todo Objeto é um "ponteiro"). Logo, o que vai ser copiado é o valor da referência do objeto (ou seja, o endereço de memória) . Assim, se vc fizer "o==outro" ou "o.equals(outro)" vai ser "true" (diz a documentação: "The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any reference values x and y, this method returns true if and only if x and y refer to the same object (x==y has the value true). ").

e eis de onde eu tirei estes absurdos:
http://java.sun.com/docs/books/tutorial/java/javaOO/arguments.html
http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Object.html#equals(java.lang.Object)
.
.
ai ai.. que blablabla chato ...
abrindo um parênteses:
No fim das contas, o pessoal acaba usando a J2EE "bare metal" pq tem medo de bibliotecas e frameworks opensource...tsc tsc... (Carlos Villela)


acho que algumas coisas como Velocity e o Webwork sào uns exageros. JSP+JSTL (ou, o JSP 2) geralmente dão conta do recado
 
Índice dos Fóruns » Perfil de Daniel Quirino Oliveira » Mensagens enviadas por Daniel Quirino Oliveira
Ir para:   
Powered by JForum 2.1.8 © JForum Team