Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
A Microsoft lançou a linguagem C# em meados do ano 2000. Desde então, um dos argumentos mais usados pelos concorrentes para desmerecer a nova linguagem é que ?o C# não passa de um clone do Java?. Este artigo mostra que embora existam várias semelhanças, o C# traz diversos recursos importantes e que simplesmente não existem ou são muito difíceis de implementar no Java.
Linguagem ou Plataforma?
Em primeiro lugar, antes de fazer qualquer comparação entre Java e alguma outra tecnologia, é bom enfatizar que ?Java? pode significar duas coisas bastante diferentes:
Uma linguagem de programação.
Uma plataforma de execução, que inclui, no mínimo, um ?runtime? e uma biblioteca de classes, usualmente conhecidos como ?Java Virtual Machine?.
Por uma questão de objetividade, esta comparação limita-se à linguagem de programação Java e não compara as plataformas da Sun e da Microsoft. Algumas características bastante interessantes no desenvolvimento de software, como por exemplo, o amplo suporte a diferentes culturas presente no C# foram deixados de lado por tecnicamente fazerem parte da ?.NET Framework?.
Não estou também comparando o Visual Studio.NET com nenhum ambiente integrado de desenvolvimento para Java, embora o Visual Studio seja, na minha opinião, um produto muito mais completo.
Semelhanças
O C# foi sem dúvida influenciado por diversas linguagens, dentre as quais evidentemente Java, C++, Delphi e Smalltalk. Veja no quadro a seguir algumas das semelhanças com o Java:
Semelhanças entre C# e Java
Característica
Implementação
Inspirado no C/C++
Boa parte da sintaxe de ambas as linguagens foi inspirada no C/C++, especialmente declaração de variáveis, funções e estruturas de controle.
Orientação a objetos
Ambas as linguagens suportam conceitos de programação orientada a objetos com a palavra reservada class.
Herança
Herança simples de classes a partir de ancestral comum e herança múltipla de interfaces.
Gerenciamento de memória
Automático, com ?coletor de lixo?.
Tipagem forte
Todas as atribuições tem os tipos validados. Os ?casts? são sempre verificados em tempo de execução. Não é possível violar o sistema de tipos.
Compila para código intermediário
Sim. No caso da Microsoft compila para ?Intermediate Language? e no Java para ?bytecode?.
Tratamento de erro
Exceptions.
Reflections
Ambas as linguagens suportam ?reflections?.
Unicode
Ambas as linguagens usam o padrão Unicode para representar caracteres e strings.
Classe que não pode ser herdada
?final? em Java; ?sealed? em C#.
Campo constante
?static final? em Java; ?const? em C#.
Operador que verifica compatibilidade de tipos
?instanceof? em Java; ?is? em C#.
Os aspectos acima são auto-explicativos e refletem o pensamento atual no desenvolvimento de software, especialmente o uso de orientação a objetos em um ambiente ?gerenciado?, no qual o programa não pode danificar o ambiente de execução.
Novidades do C#
O C# tem diversas novidades que tornam o desenvolvimento de software mais fácil e produtivo, como mostrado a seguir:
Recursos novos no C#
Característica
Java
C#
Compilado para código nativo
Raramente. O Java é quase sempre interpretado.
Sempre compilado para código nativo. A compilação pode ser feita na instalação ou na primeira execução do programa.
Todos os tipos derivados de ancestral comum
Não.
Sim, todos os tipos são derivados de object.
?Boxing? e ?Unboxing? - conversão de tipos por valor para tipos por referência
Não. Exige conversão manual.
Sim.
Structs
Não.
Sim.
Enum
Não.
Sim.
Passagem de parâmetros por referência
Não.
Sim, de duas maneiras: ref para parâmetros de entrada e saída e out para parâmetro apenas de saída.
Propriedades
Não. Podem ser simuladas com métodos Get/Set, com alguma dificuldade.
Sim, diretamente. A criação de ?componentes? é bastante facilitada.
Eventos e Delegates
Não, categoricamente (veja link abaixo).
Sim. Um ?delegate? é um ?ponteiro de função orientado a objetos?, permitindo a associação de um evento de uma classe ao código de outra de maneira conceitualmente simples e poderosa.
Atributos
Não.
Sim, permitindo ?etiquetar? o código com características que são interrogadas em tempo de execução através de ?reflection?.
Ponteiros
Não suportado diretamente, apenas indiretamente através de ?referências?.
A princípio suporta referências, mas os ponteiros podem ser usados em código ?inseguro? por questões de performance ou compatibilidade com DLLs.
Sobrecarga de operadores
Não.
Sim.
Operadores de conversão
Não.
Sim.
Operadores de cast
Um, sintaxe semelhante ao C/C++.
Dois, um semelhante ao C/C++ e o outro ?as?. Um retorna null e outro dispara exception em casso de erro de conversão.
Inteiros sem sinal
Não.
Sim.
Tipo numérico pouco sujeito a erros de representação e arredondamento
Não.
Sim, o tipo decimal pode ser usado em softwares que não toleram facilmente erros de arredondamento, como programas de contabilidade
Forech: loop para varrer arrays e coleções
Não.
Sim.
Campo readonly
Não.
Sim.
Documentação integrada em XML
Não.
Sim, permitindo que o programador escreva facilmente a documentação enquanto programa. Este documentação pode depois ser extraída do fonte ou usada no próprio ambiente de desenvolvimento.
Switch com strings
Não.
Sim, facilitando o desenvolvimento.
Controle sobre ?estouro de faixa? numérica
Não.
Sim. As palavras reservadas checked e unchecked permitem mudar o que o programa faz quando há um ?estouro de faixa numérica?: o checked dispara uma exception; o unchecked não.
Funções com número variável de parâmetros
Não.
Sim, de forma ?tipada?, com a palavra reservada params.
Formas do método Main
Uma.
Quatro. O main pode aceitar um array de strings ou nada; pode retornar inteiro ou nada.
Goto
Não.
Sim, com a restrição de que não pode entrar em um bloco.
Arquivo ?executável? independente do namespace
Um ?package? Java obrigatoriamente está associado a um único arquivo ?.class?.
Não existe relação direta entre o ?namespace? e a DLL que o implementa, dando mais flexibilidade ao desenvolvedor na hora de quebrar seus projetos em pedaços menores.
Especificadores de acesso
Quatro.
Cinco. O internal, adicional, especifica acesso apenas no mesmo ?assembly? (mesma DLL, a grosso modo).
Diretivas de compilação condicional (#ifdef etc)
Não.
Sim.
Destrutores
Não, mas o método Finalize pode ser usado.
Sim.
Padronização por algum organismo internacional
Não. Duas submissões da Sun foram posteriormente retiradas.
Sim. Submetido e aceito pelo ECMA (http://www.ecma.ch).
Chama APIs do Windows e DLLs
Não. Mesmo o suporte ?nativo? de alguns compiladores é extremamente limitado pela falta de ponteiros na linguagem.
Sim.
Chama objetos COM/COM+
Não.
Sim.
Cria objetos COM/COM+
Não.
Sim.
Existem alguns pontos importantes por trás dos tópicos acima:
O C# implementa características interessantes do C++ que foram removidas no Java, como passagem de parâmetros por referência, enum, struct, sobrecarga de operadores, operadores de conversão e compilação condicional;
O C# tem vários recursos que melhoram a performance, como uso de ?tipos por valor? (structs e enums) em situações simples onde o uso de uma classe seria muito ?caro? e suporte direto a ponteiros;
Suporte direto a componentes, através de a propriedades e eventos;
A unificação do sistema de tipos (tudo é derivado de object) e a conversão de valores para referências através de ?boxing? são recursos que, ao mesmo tempo simplificam a programação, como também permitem melhores abstrações;
Boa integração com código anterior escrito para Windows: suporte a ponteiros, chamar DLLs, chamar objetos COM e criar objetos COM. Não é necessário abandonar o C# para usar alguma facilidade não contemplada pela biblioteca de classes;
Diversos recursos que facilitam a programação, como switch com strings, ?loop? foreach para varrer todos os elementos de uma coleção ou array, campo readonly;
Conclusão
Embora compartilhe características com o Java, o C# é uma linguagem que traz vários recursos muito interessantes que não ou existem no Java ou dão muito trabalho para implementar ou têm performance ruim.
será que as comunidades C# crescem na proporção das comunidades Java tb? hauhahhuahuahuahauhahau _________________Carlos E. A. Barretto
Bacharel em Ciência da Computação
Sun Certified Java Programmer 1.4
Sun Certified Web Components Developer 1.4
JavaFree.org
Todos os tipos derivados de ancestral comum
JAVA: Não. C#: Sim, todos os tipos são derivados de object.
Desde quando não...
alguem já ouviu falar em java.lang.Object ?
É que em C# não existem tipos primitivos...
int, char, boolean, double, float . . realmente não derivam de uma classe ancestral comum!
O C# é uma boa linguagem tanto quanto Java, tem tb suas limitações, soh que eu acho que esse fulano fez uma comparação meio absurda . . em relação a ponteiros e uso de DLL's "Java não foi feito para rodar apenas em Windows como o .Net" Na minha opinião o uso de Dlls e outros recursos que ele citou não entram em questão de Linguagem, e sim de Plataforma.
É uma questão dificil de julgar..
Enquanto isso.. sou amante de [color=red:ee6e826b09]""Java""[/color:ee6e826b09] _________________Coutinho
É que em C# não existem tipos primitivos...
int, char, boolean, double, float . . realmente não derivam de uma classe ancestral comum!
E isso tb não é vantagem... Os tipos que herdam de Object (tanto em C# quanto em Java) consomem mais memória. Digamos que este seja um recurso que Java tem e C# não... Agora me diga uma coisa que você faz com o C# que você não faça com Java em todas as plataformas...
É que em C# não existem tipos primitivos...
int, char, boolean, double, float . . realmente não derivam de uma classe ancestral comum!
Ahhhh sim, mas na minha opiniao, o uso de tipos primitivos durante o desenvolvimento de uma app é muito útil, porem, quando "penso" que poderia ser mais facil.... ai uso as classes encapsuladoras....
para int -> Integer
para double -> Double
para float -> Float
para char -> Character
e etc.....
Fora o consumo excessivo de memoria como o Volnei disse...
Coutinho
O C# é uma boa linguagem tanto quanto Java, tem tb suas limitações, soh que eu acho que esse fulano fez uma comparação meio absurda . . em relação a ponteiros e uso de DLL's "Java não foi feito para rodar apenas em Windows como o .Net" Na minha opinião o uso de Dlls e outros recursos que ele citou não entram em questão de Linguagem, e sim de Plataforma.
Uma coisa eu sempre digo, nao podemos nos fanatizar em cima do Java...
com certeza é dele que eu gosto e nele eu programarei.... agora nós não podemos fechar as portas para outras tecnologias (como discutido no topico que o Fabio iria usar .net)
Acho muito importante nós conhecermos também o C#, porque essas pessoas que fazem os comparativos, apenas conhecem a linguagem deles, e deste modo, fica melhor (com certeza).... Se nós conhecermos mto bem a nossa, e acima de tudo, como ja dizia Sun Tzu (A arte da guerra), conhecermos nosso "inimigo" (hehehehe), com certeza estaremos muito mais preparados para uma eventual discussao do assunto..
Recomendo a todos, que abram suas mentes (lol... matrix) e deem pelo menos uma lidinha naquele livro:
C# for Java Programmers
Tem pra baixar na net.... bem legal, em cima deste livro, posso formar uma opiniao forte sobre as 2...
E isso tb não é vantagem... Os tipos que herdam de Object (tanto em C# quanto em Java) consomem mais memória. Digamos que este seja um recurso que Java tem e C# não... Agora me diga uma coisa que você faz com o C# que você não faça com Java em todas as plataformas...
Além do mais, C# é uma cópia RIDÍCULA do Java.
Não tem nem o que discutir.. sem sombra de dúvidas em Java é possivel fazer tudo!! _________________Coutinho
Uma coisa eu sempre digo, nao podemos nos fanatizar em cima do Java...
com certeza é dele que eu gosto e nele eu programarei.... agora nós não podemos fechar as portas para outras tecnologias (como discutido no topico que o Fabio iria usar .net)
Acho muito importante nós conhecermos também o C#, porque essas pessoas que fazem os comparativos, apenas conhecem a linguagem deles, e deste modo, fica melhor (com certeza).... Se nós conhecermos mto bem a nossa, e acima de tudo, como ja dizia Sun Tzu (A arte da guerra), conhecermos nosso "inimigo" (hehehehe), com certeza estaremos muito mais preparados para uma eventual discussao do assunto..
Depois dessa não precisa dizer mais nada ! esse também é o meu pensamento.. temos que saber de tudo um pouco .. mas dominar muito bem pelo menos uma Tecnologia (Sugestão Java)
hum... nunca pesquisei... mas Quanto custa o C# ????
FreeSoftware na veia... O que vem das comunidades não muda! Não é uma empresinha que vai mudar a minha metodologia de desenvolvimento.
Exemplo muito útil: Delphi. Quem disse que eu queria que o delphi fosse para .NET??? Nhaca.. Agora para executar o delphi (ou os aplicativos delphi, não sei e não estou interessado) preciso de um framework .NET. Tosco!.
Exemplo muito útil 2: Oracle Forms: Não conheço muito bem a história, mas parece que eles mudaram bastante coisa nas novas verões habilitando o uso na Internet. Alguns aqui da região reclamam muito disso.
Exemplo muito útil 2: Oracle Forms: Não conheço muito bem a história, mas parece que eles mudaram bastante coisa nas novas verões habilitando o uso na Internet. Alguns aqui da região reclamam muito disso.
Vitor,
Exatamente, Na versão 6i o forms era client/server versão 9i totalmente web. Eles não perguntaram nada para ninguem pra fazer isso.
A diferença é que a Oracle escolheu o caminho do Java, ainda bem
Compilado para código nativo
Raramente. O Java é quase sempre interpretado.
// Raramente pq ninguem configura a JVM pra compilar na primeira execucao/instalacao...
// Regra geral: a performance de um servidor J2EE aumenta a medida q passa o tempo
// por causa do JIT. Qto mais uma classe eh chamada, mais chance ela tem
// de ser compilada nativamente. Eh soh esperar alcancar um valor de chamadas Sempre compilado para código nativo. A compilação pode ser feita na instalação ou na primeira execução do programa.
?Boxing? e ?Unboxing? - conversão de tipos por valor para tipos por referência
Não. Exige conversão manual.
// O Java possui auto-boxing... versao Tiger filhao, SE ATUALIZA!
Sim.
Passagem de parâmetros por referência
Não.
// C# nao tem tipo primitivo, mas implementa passagem por referencia, VSF!!
// Em Java, quem quiser fazer, coloca os
// valores num array de int, byte, long... pois Array eh Objeto! e objeto, vc tem a referencia Sim, de duas maneiras: ref para parâmetros de entrada e saída e out para parâmetro apenas de saída.
Propriedades
Não. Podem ser simuladas com métodos Get/Set, com alguma dificuldade.
// Primeiro: q dificuldade eh essa q ele chama? Ctrl+C Ctrl+V? Nossa..
// Segundo: metadados versao Tiger, ou simplesmente, deixa public o field da classe...
// refresh your mind! DumbAss!
Sim, diretamente. A criação de ?componentes? é bastante facilitada.
Atributos
Não.
// Metadados, versao Tiger
Sim, permitindo ?etiquetar? o código com características que são interrogadas em tempo de execução através de ?reflection?.
Ponteiros
Não suportado diretamente, apenas indiretamente através de ?referências?.
// Graças a deus q nao suporta... e nao eh "nao suporta indiretamente", eh "NAO SUPORTA"
A princípio suporta referências, mas os ponteiros podem ser usados em código ?inseguro? por questões de performance ou compatibilidade com DLLs.
// nao eh a toa q se faz virus em C#, ou apps com bugs... pois deixam fazer codigos "inseguros"... hahahaha grande vantagem... _)_
Inteiros sem sinal
Não.
Sim.
// Alguem sabe o q significa isso?
Tipo numérico pouco sujeito a erros de representação e arredondamento
Não.
// Versao Tiger... sem contar q Java jah roda em 64bits... C# roda? nao pesquisei, admito... Sim, o tipo decimal pode ser usado em softwares que não toleram facilmente erros de arredondamento, como programas de contabilidade
Forech: loop para varrer arrays e coleções
Não.
// Versao Tiger PORRA!
Sim.
Campo readonly
Não.
// E botar final em um atributo quer dizer o q?
// explique melhor... Sim.
Documentação integrada em XML
Não.
// Desenvolva C# sem o Visual Studio .NET... quero ver se vc ainda vai ter essa funcionalidade...pato
Sim, permitindo que o programador escreva facilmente a documentação enquanto programa. Este documentação pode depois ser extraída do fonte ou usada no próprio ambiente de desenvolvimento.
Switch com strings
Não.
// jah ouviu falar de HashCode? Duck!
// axo incrivel isso... deixam ponteiros pq axam q tem gente querendo otimizar codigo,
// mas botam switch de String pra deixar o codigo lento!... fala serio
Sim, facilitando o desenvolvimento.
Controle sobre ?estouro de faixa? numérica
Não.
// me poupe, eh soh botar um try/catch ou nao... newbie
Sim. As palavras reservadas checked e unchecked permitem mudar o que o programa faz quando há um ?estouro de faixa numérica?: o checked dispara uma exception; o unchecked não.
Funções com número variável de parâmetros
Não.
// Ainda bem q nao tem, pois assim a documentacao fica clara, e a implementacao dos metodos limpa... // e o overwrite tb fica mais facil... pensa um pokin vai... por favor...
Sim, de forma ?tipada?, com a palavra reservada params.
Formas do método Main
Uma.
// Qual a vantagem de ter mais de um? me diga uma e eu tento te entender...
Quatro. O main pode aceitar um array de strings ou nada; pode retornar inteiro ou nada.
Goto
Não.
// Ei! ISSO NAO EH OO!!! VOLTA PRA AULA DE SMALLTALK!
Sim, com a restrição de que não pode entrar em um bloco.
Especificadores de acesso
Quatro.
// qual a vantagem de ter o 'internal'... java tem DLL? fala serio...
Cinco. O internal, adicional, especifica acesso apenas no mesmo ?assembly? (mesma DLL, a grosso modo).
Padronização por algum organismo internacional
Não. Duas submissões da Sun foram posteriormente retiradas.
// Pagando eh facil neh filhao... Sim. Submetido e aceito pelo ECMA (http://www.ecma.ch).
Chama APIs do Windows e DLLs
Não. Mesmo o suporte ?nativo? de alguns compiladores é extremamente limitado pela falta de ponteiros na linguagem.
// Alooooo, java nao foi feito pra rodar SOH no Windows... isso eh desvantagem? pq? pq Windows eh QUENTE? vsf...
Sim.
Objetos COM/COM+...
Não.
// agora me diz, pq q C# tem suporte a isso? PQ?! PQ FOI FEITO PELA MICROSOFT P0RRA...
// E FOI FEITO PRA RODAR NO WINDOWS KCT!
Sim.
Duas coisas pro cara q fez a comparação:
1 - Se atualiza antes de comparar alguma coisa... se fosse assim, vo comparar Java Tiger com VB 1.0... e dizer q VB eh horrivel (e continua sendo...)
2 - Nao coloque diferencas q dependem da plataforma onde rodam (sistema operacional)
bah.... tudo bem, vamos rir um pouco das bobagens como "Switch com strings!!!" ou do "Forech: loop para varrer arrays e coleções (isso nao vem do perl?)", mas parem de ser revoltz..... C# é legal.... e nao me venha dizer que versoes betas atuais vão bater agora o que o c# ja fazia a mais de 3 anos...
bah.... tudo bem, vamos rir um pouco das bobagens como "Switch com strings!!!" ou do "Forech: loop para varrer arrays e coleções (isso nao vem do perl?)", mas parem de ser revoltz..... C# é legal.... e nao me venha dizer que versoes betas atuais vão bater agora o que o c# ja fazia a mais de 3 anos...
isso é bairrismo.... tipo linux vs windows....
diga isso pro cara q escreveu o artigo, nao eu... afinal, todos os artigos de comparações .NET e Java q vi ateh hoje, partiram do lado .NET...
nao sou eu q tem q aprender alguma coisa aki, na boa...
e dizer isso sobre versoes betas... qualeh... soh to dizendo q ele nao pode falar q Java (ou seja, JAVA, e nao JAVA 1.alguma_versao) nao suporta funcionalidade X... se ele quer comparar, compare versoes tb...
ahhh... vo comparar carro agora... nossa... meu gol eh muiiiiito melhor q seu fusca... pq nao compara com o new beattle?? eh disso q to falando... quer comparar, compara, mas seja honesto, diga a versao e a data!... esse artigo tah sendo mantido faz mais de 1 ano, senao 2... soh q nele nao informa versao, data, nada... diz apenas "Java"... vsf!
bah.... tudo bem, vamos rir um pouco das bobagens como "Switch com strings!!!" ou do "Forech: loop para varrer arrays e coleções (isso nao vem do perl?)", mas parem de ser revoltz..... C# é legal.... e nao me venha dizer que versoes betas atuais vão bater agora o que o c# ja fazia a mais de 3 anos...
isso é bairrismo.... tipo linux vs windows....
Quantos anos tem o C#? A quantos anos estão desenvolvendo ele?
Esse artigo já é meio velho, foi publicado no www.portaldaprogramacao.com.br e uma réplica a ele rolou na lista do SouJava. Leiam e tirem suas conclusões:
Eu achei muito engracada a lista de "vantagens" do C#
sobre o Java. Torcidas organizadas aa parte, vamos e-
xaminar algumas delas:
1 - "Compilado para código nativo
Java: Raramente. O Java é quase sempre interpretado."
(Nosso amigo autor do artigo certamente nunca ouviu
falar em JIT.)
"C#: Sempre compilado para código nativo. A compilação
pode ser feita na instalação ou na primeira execução
do programa."
Ou seja: perde-se a portabilidade do binario ao e-
xecutar a 1a. vez. Isso eh "vantagem" ? Ok.
2 - "Todos os tipos derivados de ancestral comum"
"Java: Não."
Excelente! Se eu quiser um boolean apenas, ocupo um
byte da memoria, e nao o espaco de um objeto intei-
ro, apenas para guardar um estado logico! Sem contar
que eh um objeto a menos para o garbage collector
tratar...
"C#: Sim, todos os tipos são derivados de object."
Duh... Novamente nao entendi a "vantagem". Mas vamos
adiante...
3 - "'Boxing' e 'Unboxing' - conversão de tipos por
valor para tipos por referência"
"Java: Não. Exige conversão manual."
"C#: Sim."
Ei, estamos falando de uma linguagem fortemente tipa-
da. Nao de Visual Basic. Conversao automatica signi-
fica execucao mais lenta, porque a toda hora o runtime
tem que ficar checando tipos de dados. Tipagem forte
significa checagem sendo feita apenas em tempo de com-
pilacao, nao de execucao - logo, o codigo roda mais
rapido! Cade a "vantagem", que eu ainda nao vi ? Ok,
vamos ser pacientes, devem estar todas no final...
4 - "Structs"
"Java: Não."
"C#: Sim."
Essa eu confesso que nao entendi: ele estah se refe-
rindo a estruturas do C ? Mas vem cah, se Java eh uma
linguagem TOTALMENTE ORIENTADA A OBJETO, que sentido
faz suportar estruturas de dados C-like ?
5 - "Enum"
"Java: Não."
"C#: Sim."
Ok, aqui dou o braco a torcer: eu ateh que gostaria
de ter tipos enumerados em Java. Com eles, dah para
escrever um codigo mais claro e legivel do que ficar
fazendo coisas do tipo:
public final static int MINHA_CONSTANTE_1 = 1;
public final static int MINHA_CONSTANTE_2 = 2;
Mas nada que me tire o sono ou me faca correr deses-
perado para o C#. Vamos adiante.
6 - "Passagem de parâmetros por referência"
"Java: Não."
"C#: Sim, de duas maneiras: ref para parâmetros de
entrada e saída e out para parâmetro apenas de saída."
Sinceramente ? Prefiro assim. Porque ? Bom, para
qual plataforma voces acham que eh mais facil surgir
uma falha de seguranca explorando justamente acessos
ilegais aa areas de memoria ?
7 - "Propriedades"
"Java: Não. Podem ser simuladas com métodos Get/Set,
com alguma dificuldade."
"C#: Sim, diretamente. A criação de "componentes"
é bastante facilitada."
Componentes visuais. Mas o conceito de componente
vai alem de uma GUI com iconezinhos para arrastar
num formulario. Um EJB eh um componente; uma servlet,
um portlet, e por aih vai. Todos com propriedades e
metodos, passiveis de customizacao. A unica diferen-
ca eh que no Java nao se usa uma GUI (ateh existe su-
porte a programar desta maneira em algumas ferramen-
tas, como o Visual Age for Java, mas nunca usei - e
sinceramente, nao me fez falta).
Eu gostaria de saber se ele saberia escrever uma
aplicacao em C# sem a GUI...
8 - "Eventos e Delegates"
"Java: Não, categoricamente (veja link abaixo)."
"C#: Sim. Um "delegate" é um "ponteiro de função
orientado a objetos", permitindo a associação de
um evento de uma classe ao código de outra de
maneira conceitualmente simples e poderosa."
Novamente: isso eh plenamente possivel de ser feito
em Java. Apenas, nao eh visual (selecionar um even-
to num object inspector, e selecionar um metodo pronto
ou escrever um novo).
9 - "Atributos"
"Java: Não."
"C#: Sim, permitindo "etiquetar" o código com
características que são interrogadas em tempo
de execução através de "reflection"."
Vide acima.
10 - "Ponteiros"
"Java: Não suportado diretamente, apenas indiretamente
através de "referências"."
"C#: A princípio suporta referências, mas os ponteiros
podem ser usados em código "inseguro" por questões
de performance ou compatibilidade com DLLs."
Alguem mais estah sentindo cheiro de falhas de se-
guranca e codigo amarrado aa plataforma Windows ?
11 - "Sobrecarga de operadores"
"Java: Não."
"C#: Sim."
Se com "sobrecarga de operadores" ele estah falando
de sobrecarga de metodos, nosso amigo estah por fo-
ra, mesmo...
12 - "Operadores de conversão"
"Java: Não."
"C#: Sim."
Dispensaveis gracas aa forte tipagem da linguagem.
13 - "Operadores de cast"
"Java: Um, sintaxe semelhante ao C/C++."
"C#: Dois, um semelhante ao C/C++ e o outro "as".
Um retorna null e outro dispara exception em casso
de erro de conversão."
Ou seja, seu codigo pode compilar e ainda sim estar
errado. Eh por isso que a tipagem forte do Java eh
melhor. Ele realmente acha isso "vantagem" ?
14 - "Inteiros sem sinal"
"Java: Não."
"C#: Sim."
Realmente, nao existem inteiros sem sinal no Java.
Tambem nao existem no Pascal, Visual Basic e um
monte de outras linguagens. Na verdade, soh existem
inteiros unsigned no C e C++, pelo que Lembro. E
ainda assim o mundo nao acabou.
15 - "Tipo numérico pouco sujeito a erros de representação
e arredondamento"
"Java: Não."
"C#: Sim, o tipo decimal pode ser usado em softwares
que não toleram facilmente erros de arredondamento,
como programas de contabilidade"
java.text.NumberFormat
java.util.Currency
Simples e preciso.
16 - "Forech: loop para varrer arrays e coleções"
"Java: Não."
"C#: Sim."
17 - "Campo readonly"
"Java: Não."
"C#: Sim."
Simples: nao implemente o metodo set do
atributo. Duh...
17 - "Documentação integrada em XML"
"Java: Não."
"C#: Sim, permitindo que o programador escreva
facilmente a documentação enquanto programa.
Este documentação pode depois ser extraída do
fonte ou usada no próprio ambiente de desenvolvimento."
Ele jah ouviu falar de JavaDoc ?
18 - "Switch com strings"
"Java: Não."
"C#: Sim, facilitando o desenvolvimento."
E diminuindo a performance. Internamente, o switch
comparando strings eh construido de forma diferen-
te (e mais lenta) do que usando um literal (int,
char ou coisa que o valha). Resta saber o que eh
melhor: ter uma vez o conforto de usar um string
para controlar um processo, ou escrever um codigo
que gera um opcode menor e execute mais rapido to-
das as vezes.
19 - "Controle sobre "estouro de faixa" numérica"
"Java: Não."
"C#: Sim. As palavras reservadas checked e unchecked
permitem mudar o que o programa faz quando há um
"estouro de faixa numérica": o checked dispara uma
exception; o unchecked não."
Ou seja, eh um bypass do mecanismo de tratamento
de excecao. Para quem jah estah acostumado a lidar
com try - catch, eh um superfluo. E quem nao estah,
eventualmente vai ter que se acostumar, porque to-
dos os outros tipos de erro geram excecoes, e nao
tem como desliga-las todas.
20 - "Funções com número variável de parâmetros"
"Java: Não."
"C#: Sim, de forma "tipada", com a palavra reservada
params."
Oh... Tem razao: eu nao consigo escrever codigo dubio
e pouco legivel facilmente com Java. Que droga.
21 - "Formas do método Main"
"Java: Uma."
"C#: Quatro. O main pode aceitar um array de strings
ou nada; pode retornar inteiro ou nada."
Este eh o segundo ponto em que eu realmente acho que
o Java peca: o metodo Main() nao faz qualquer retor-
no ao sistema operacional sobre o status final da e-
xecucao. Isso pode ser util no caso de execucao a
partir de shell scripts no Unix.
22 - "Goto"
"Java: Não."
"C#: Sim, com a restrição de que não pode entrar em
um bloco."
Java nao tem GOTO! Java nao eh BASIC! Vamos todos
dizer: AMEM!
Qualquer curso de programacao serio jah aboliu o
GOTO faz alguns anos. Seja em qual linguagem for.
Eh altamente prejudicial para a legibilidade do
codigo e modularizacao. Ateh em Cobol se proibe o
uso de GOTO hoje em dia, e vem nosso amigo anunciar
isso como "vantagem"... Soh se for para o Java.
23 - "Arquivo "executável" independente do namespace"
"Um "package" Java obrigatoriamente está associado a
um único arquivo ".class"."
"Não existe relação direta entre o "namespace" e a
DLL que o implementa, dando mais flexibilidade ao
desenvolvedor na hora de quebrar seus projetos em
pedaços menores."
E ajudando a manter o caos na hora de organizar o
codigo...
E francamente, de onde saiu esse "um package estah
obrigatoriamente associado a um unico arquivo .class ?"
24 - "Especificadores de acesso"
"Quatro."
"Cinco. O internal, adicional, especifica acesso
apenas no mesmo "assembly" (mesma DLL, a grosso modo)."
Java eh independente de plataforma. Eh a sua principal
caracteristica. Eu acho otimo que seja assim.
25 - "Diretivas de compilação condicional (#ifdef etc)"
"Java: Não."
"C#: Sim."
Diretiva de compilacao para codigo binario que executa
sem modificacao em qualquer plataforma ?
26 - "Destrutores"
"Java: Não, mas o método Finalize pode ser usado."
"C#: Sim."
Quando nao se tem um bom garbage colletor...
27 - "Padronização por algum organismo internacional"
"Java: Não. Duas submissões da Sun foram posteriormente
retiradas."
Java eh usado largamente pela industria de software,
de telefonia movel, meios academicos e cientificos.
A sonda Sojourney rodava Java. Eh uma linguagem que
se consagrou como um padrao de fato. Alguem aih sabe
o que eh ECMA, por acaso ?
28 - "Chama APIs do Windows e DLLs"
"Java: Não. Mesmo o suporte "nativo" de alguns compiladores
é extremamente limitado pela falta de ponteiros na linguagem."
"C#: Sim."
Vamos todos dizer, irmaos: AMEM por isso!
29 - "Chama objetos COM/COM+"
"Java: Não."
"C#: Sim."
30 - "Cria objetos COM/COM+"
"Java: Não."
"C#: Sim."
Quem precisa de COM (M$) quando tem CORBA (open source) ?
"Existem alguns pontos importantes por trás dos tópicos acima:
* O C# implementa características interessantes do C++ que foram
removidas no Java, como passagem de parâmetros por referência, enum,
struct, sobrecarga de operadores, operadores de conversão e
compilação condicional;"
Tudo foi retirado com um proposito: tornar a linguagem
universal e totalmente portavel. Nao foi por outro mo-
tivo.
"* O C# tem vários recursos que melhoram a performance, como uso
de "tipos por valor" (structs e enums) em situações simples onde o
uso de uma classe seria muito "caro" e suporte direto a ponteiros;"
E tem varias "vantagens" que podem jogar a performance no
chao, como a tipagem fraca (pior de todos, heranca maldi-
ta do BASIC que a Microsoft ateh hoje insiste em manter
nas suas linguagens, criando maus habitos de programacao)
e os switches usando strings.
"* Suporte direto a componentes, através de a propriedades e
eventos;"
Java eh *todo componentes* - apenas nao sao visuais.
"* A unificação do sistema de tipos (tudo é derivado de object) e
a conversão de valores para referências através de "boxing" são
recursos que, ao mesmo tempo simplificam a programação, como também
permitem melhores abstrações;"
E jogam contra a performance.
"* Boa integração com código anterior escrito para Windows:"
Mantendo voce atrelado aa plataforma Windows, nao por acaso.
"suporte a ponteiros, chamar DLLs, chamar objetos COM e criar
objetos COM. Não é necessário abandonar o C# para usar alguma
facilidade não contemplada pela biblioteca de classes;"
Eh o trade-off que se faz por ficar atado ao Windows. Talvez
para alguns isso seja aceitavel, mas nao para todos.
No resumo deste testamento, fica a seguinte impressao: C#
promete "facilitar a vida" do programador - mas soh do pro-
gramador "desenhista de formularios"; aquele que realmente
sabe programar, que conhece os pros e contras de cada tec-
nologia, sabem que no geral, Java estah ganhando e facil,
pelo menos no aspecto tecnico. Infelizmente, este canto de
sereia da Microsoft seduz muita gente boa - e principalmente,
muita gente que toma decisoes dentro de empresas. Cabe aa
nos, que conhecemos a ferramenta que usamos e seu potencial,
nos esforcarmos para que a verdade sempre se sobreponha ao
marketing. Vamos trabalhar nesse sentido, sem radicalismos
exagerados, sempre procurando embasar nossas opinioes em
fatos e nao em emocao (o que eh muito dificil, eu sei bem).
Isso nao eh torcida por time de futebol, eh nosso ganha-
pao. Tambem nao eh religiao (pelo menos para mim), portanto
respeitar diferencas de opiniao faz parte. Apenas, nao
permitir que este tipo de material se torne "verdade"
por conta de nosso silencio e omissao.
Na boa !! Onde será que o pessoal de .NET quer chegar com esse tipo de comparação ????
Concordo com o miojo que comparar Java versão X com VB versão X, não leva a lugar algum.
O que os defensores de .NET não enxergam é todo o encanto por trás da Tecnologia Java.
Fazer comparações de código é fácil, agora quero ver a Microsoft assumir a realidade das grande empresas brasileiras.
Vamos dar um exemplo:
** 89% dos bancos de dados das grande empresas financeiras estão em Mainframes. (Será que lá roda SQL Server ???? )
** Os leitores aqui podem ter certeza que sua Conta Corrente roda em um ambiente Mainframe S/390 e aplicações em COBOL acessando ou Banco de Dados DB2, ou IMS ou Adabas ( Será que a Microsoft tem um ODBC pra eles ?? )
** Será que a CLR do .NET roda em Unix, S/390, Linux, MVS, zSeries ,como a JVM do Java ??? ** Será que com .NET é possivel escalar um sistema em ambiente Windows para um Ambiente Unix apenas configurando alguns arquivos XML ???
Vamos ser honestos !! Quem tá no mercado sabe do que estou falando !!
Passamos semanas a fio, compilando, projetando, propondo e principalmente integrando aplicações legadas a um ambiente J2EE, que pode ser montado em alta ou baixa plataforma, em Websphere ou BEA, com DB2 ou Oracle.
Vendemos a nossos amigos, clientes e parceiros uma tecnologia padrão, que possa agradar a Gregos e Troianos !!
Por isso, com todo respeito ao pessoal do .NET, fazer "Cadastro de Clientes" em .NET com C#, VB, etc eu faço com o pé nas costas.
Eu quero ver é voces do .NET fazerem tudo o que nós pessoal do Java fazemos: Compartilhar, Reutilizar, Aprimorar, Integrar, tudo isso em qualquer ambiente.
Todos os tipos derivados de ancestral comum
JAVA: Não. C#: Sim, todos os tipos são derivados de object.
Desde quando não...
alguem já ouviu falar em java.lang.Object ?
De todos os itens daquela velha comparação do Maurão, talvez este seja o único que contém alguma afirmação verdadeira (mas que não afeta em nada a vida do programador). Nem todos os tipos de dados são herdeiros de java.lang.Object (ou será que int, float, char, boolean,... se tornaram no Tiger?). Ok, podem argumentar que os mecanismos de autoboxing do .NOT, somados q aliases (int->System.Int32, por exemplo) podem mascarar o sistema de tipos do notYET como sendo um só, mas este tipo de discussão costuma levar a um só lugar: nenhum. _________________JavaFree.org
Todos os tipos derivados de ancestral comum
JAVA: Não. C#: Sim, todos os tipos são derivados de object.
Desde quando não...
alguem já ouviu falar em java.lang.Object ?
De todos os itens daquela velha comparação do Maurão, talvez este seja o único que contém alguma afirmação verdadeira (mas que não afeta em nada a vida do programador). Nem todos os tipos de dados são herdeiros de java.lang.Object (ou será que int, float, char, boolean,... se tornaram no Tiger?). Ok, podem argumentar que os mecanismos de autoboxing do .NOT, somados q aliases (int->System.Int32, por exemplo) podem mascarar o sistema de tipos do notYET como sendo um só, mas este tipo de discussão costuma levar a um só lugar: nenhum.
Exatamente, como já dito em 2 posts anteriores...
1) tipos primitivos são bons SIM! e ainda posso escolher entre eles ou objetos em memoria (apesar do gasto)
2) no meu post sobre "APENAS JAVA" ou "APENAS .NET"
Na nova Java Magazine o Osvaldo Doederlein comenta que Java e .Net é uma competição saudável. Um copia e melhora as coisas do outro. Isso faz com que as implementações das novas versões sejam mais rápidas tanto no Java quanto no .net, é aquela velha história, ninguém quer ficar para traz.
Toda comparação sem imparcialidade é absurda. As discussões não podem partir para o lado de que para desenvolver em Java não é preciso desembolsar nenhum dolar ou real, pois em C# também não é preciso e isto a Microsoft sempre enfatiza nas palestras que ela ministra. Infelizmente o autor do "artigo" foi infeliz na composição e nas comparações, mostrando que não tem muito conhecimento dos dois mundos . Alguém aqui já leu a revista MSDN Magazine ? . A revista é da mesma editora da revista Java Magazine, com um detalhes que os autores escrevem textos que iludem o leitor, sem contar nos erros grotescos de conceitos como OO e etc. Quanto a Borland ter mudado o Delphi 8 para .Net, foi de certa maneira uma atitude correta, por que a empresa lançaria uma ferramenta de desenvolvimento para Windows, gerando código win32 ? Seria remar contra a correnteza. Além do mais a Borland já mostrou ser uma empresa que sabe o que faz.
Alessandro _________________"Aquele que faz uma pergunta é um tolo por cinco minutos; aquele que não faz permanece tolo para sempre"[Provérbio Chinês]
Extension Points
Algumas das limitações REAIS que são mostradas nesse artigo já foram implementadas na versão Tiger 1.5 (que está realmente MUITO boa).
Entretanto, a maioria das "limitações" citadas (como "Java não tem structs", por exemplo) podem ser traduzidas por nós como "Putz! GRAÇAS AOS DEUSES que NÃO TEM!!!". Pra mim, a falta dessas traquizongas sintáticas não são limitações: São features! Uma linguagem que pretenda seguir o paradigma O.O. não precisa dessas porcarias.
As facilidades sintáticas incluídas na 1.5 foram cuidadosamente embasadas para evitar abusos, mas mesmo assim ainda confesso que tenho medo do que vão fazer com elas por aí... Foi a mesma coisa com classes internas no passado do Java: logo depois da liberação houve um surto de códigos ilegíveis por aí até o pessoal se acostumar com a maneira saudável de usar o recurso. Temo que isso também ocorra com os enums e generics.
É sim: eu trabalho com uma linguagem "limitada". Eu GOSTO que ela seja assim.
Algumas das limitações REAIS que são mostradas nesse artigo já foram implementadas na versão Tiger 1.5 (que está realmente MUITO boa).
Entretanto, a maioria das "limitações" citadas (como "Java não tem structs", por exemplo) podem ser traduzidas por nós como "Putz! GRAÇAS AOS DEUSES que NÃO TEM!!!". Pra mim, a falta dessas traquizongas sintáticas não são limitações: São features! Uma linguagem que pretenda seguir o paradigma O.O. não precisa dessas porcarias.
[]s
È por estas e outras traquizongas, que eu sempre digo: tudo que a MicroSoft tem é um grande Gambiarra, principalmente o .net. _________________"Pessoas inteligentes falam sobre idéias;
pessoas comuns falam sobre coisas;
pessoa mesquinhas falam sobre pessoas."
(autor desconhecido)
Propriedades
Não. Podem ser simuladas com métodos Get/Set, com alguma dificuldade.
// Primeiro: q dificuldade eh essa q ele chama? Ctrl+C Ctrl+V? Nossa..
// Segundo: metadados versao Tiger, ou simplesmente, deixa public o field da classe...
// refresh your mind! DumbAss!
Sim, diretamente. A criação de ?componentes? é bastante facilitada.
Simulado com alguma dificuldade é um pouco demais. Eu não conheço muito bem e propriedades, mas eu acho get e set uma mão na roda para impor restrições a valores. Ora, se eu tiver um atributo numerico que não pode ser negativo, faço um set assim:
Como é que properties resolveriam isso?! Alguem que conheça de C# pode responder?!
miojo
Inteiros sem sinal
Não.
Sim.
// Alguem sabe o q significa isso?
Significam tipos sem sinal mesmo. É como se fosse o modulo do numero. Ou seja, num tipo sem sinal vc nunca vai ter um valor negativo, apenas o valor absoluto do numero. Isso existe em C mas eu não lembro de ter usado e tambem não lembro de ter precisado desde que comecei a programar em Java.
miojo
Documentação integrada em XML
Não.
// Desenvolva C# sem o Visual Studio .NET... quero ver se vc ainda vai ter essa funcionalidade...pato
Sim, permitindo que o programador escreva facilmente a documentação enquanto programa. Este documentação pode depois ser extraída do fonte ou usada no próprio ambiente de desenvolvimento.
Isso depende muito do gosto do freguês. Não chega a ser uma vantagem para convencer um desenvolvedor. Se bem que talvez convença aquele seu chefe louco por siglas.
miojo
Padronização por algum organismo internacional
Não. Duas submissões da Sun foram posteriormente retiradas.
// Pagando eh facil neh filhao... Sim. Submetido e aceito pelo ECMA (http://www.ecma.ch).
Bom, acho que aqui entra o JCP e tambem o respaldo de grandes empresas que apostam no Java. No mais acho que o cara não sabe nem Java nem C#. Nem sei porque a gente tá discutindo um artigo nesse nivel (uops... isso não é um ataque pessoal ao autor, mas ao artigo sim).
Significam tipos sem sinal mesmo. É como se fosse o modulo do numero. Ou seja, num tipo sem sinal vc nunca vai ter um valor negativo, apenas o valor absoluto do numero. Isso existe em C mas eu não lembro de ter usado e tambem não lembro de ter precisado desde que comecei a programar em Java.
A grande utilidade dos "unsigned" int é que voce tem aquela faixa de valores para o int...
até 32765 (se nao me engano) positivo, e 32766 negativo ..... quando (em C) se utlilizava esse tipo de variavel, voce poderia caminhar de 0 até 65 mil e poco (a soma dos 2 valores)...
Tive que usar uma vez para calcular a fase da lua (quem já fez, sabe o CAOS que são os dias julianos, e tal...)
até 32765 (se nao me engano) positivo, e 32766 negativo ..... quando (em C) se utlilizava esse tipo de variavel, voce poderia caminhar de 0 até 65 mil e poco (a soma dos 2 valores)...
Bah... ainda assim tipos unsigned não são necessarios em Java. Ora, se for pelo intervalo de valores usa um long e pronto. Ah... aposto que vc consegue implementar as fases da Lua sem tipos não sinalizados.
rodrigocansianPosts:1283
Vocês acreditam nisso????