mesmo com netbeans, todas classes visuais eu escrevo na mão, toda estruturação do gridbag, componentes, etc etc.
Por que isso?
O dia que você fizer algum refactor em um ambiente mais complexo, com milhoes de linhas, com aqueles forms nojetos por trás, talvez irá entender.
Até onde usei, não lembro das licenças matar a empresa que desenvolve em .Net. Aliás, em Java, pode ser gratuito algumas coisas, mas vai pedir suporte e você verá que são os profissionais mais caros.
Se for pra desktop, o NetBeans faz praticamente a mesma coisa. Em Web, o VS.Net 2008 não é diferente dos visuais do Eclipse, apenas que ele tem uns componentes que se conectam ao banco de dados através deles. Embora possamos “desmembrar” o componente feito, se precisar de total flexibilidade no design, tem que colocar a mão no código mesmo. Isso não é ganho de tempo, mesmo porque, se tiver que personalizar mesmo, vai ter que ser na unha mesmo.
Alguns alegam que desenvolver em .Net é mais produtivo, mas não é bem assim. Se for para desenvolver do modo macarrônico que muitos dos que vi por ai, vindos do VB, realmente, será. Fácil de fazer e duro de manter.
Mas usando padrões, isso com C#, não conheço VB.Net, é trocar 6 por meia dúzia, dá na mesma em termos de tempo de desenvolvimento. ASP.Net é como JSF praticamente, só que mais flexível. Se misturarmos JSF com Facelets, fica igual.
Produtivo na Web eu diria Asp.Net MVC, que é outro conceito e ai sim, há um ganho de produtividade.
Enfim, são esses tipos de conversas que um evento como esse não deve ter, porque tem muito javeiro que se diz conhecedor de .Net e de .Net em java, mas a realidade é que poucos conhecem mesmo os dois lados.
PS: Não vou falar de portabilidade, pois nisso o Java é melhor, já que o projeto Mono sempre está com dois passos atrás e precisa mudar componentes que no SO Windows usam do sistema operacional.
[quote=sergiotaborda][quote=xdraculax]
Heroi é quem ainda faz isso. Em java não se definem coordenadas de coisa nenhuma. Embora isso possa ser feito se necessário,
em java a composição de componentes visuais é portável também. Não entre OS, mas entre diferentes tamnhos de desktop e resolução…
Em java não se usa arrasta e solta porque não é necessário. A vantagem do WYSIWYG é apenas para design mode, para ficar experimentando como fica a tela. Mas na real, o design é feito por alguem antes da implmentação. Não ha experimentalismo.
Vc encaixa o codigo e voilá. Vc pode criar componentes usando for , while, if, etc… com um pouco mais de trabalho pode gerar a partir de xml ,etc…
Mas ai está uma diferença entre as plataformas : o posicionamento dos componentes na tela. Java permite explicito e dinamico. .NET é sempre explicito. Vão me dizer que fazer sempre no design mode é vantagem ?
[/quote]
Sim sei que existem gerenciadores de layout.
Mas como eu disse no começo, faria para aplicações Windows Desktop.
Mas voltando ao assunto do tópico, tomara que seja legal.
Ver o que ambas as plataformas oferecem pode ser interessante do ponto de vista da arquitetura; pra que venhamos a tomar decisões embasadas em fatos, e nem em “achismos”.
To doido que venha pra minha cidade.
Bom primeiro gostaria de avisar que esse post é minha opnião. Não que vale alguma coisa, mas é uma maneira de receber notificações sobre as postagens, já que achei as postagem interessantes e quero acompanhar.
Eu acho que o Browser é uma aplicação cliente e de certa forma Desktop. Talvez algum guru consiga fazer um browser que rode dentro de um browser na web. Sei la vai saber né. No celular ainda não tem, mas o futuro ta logo aí. Vamos ver se o Google faz um.
Para mim C, VB6 e Delphi estão mortos. Não porque ninguém quer usar mais, mas porque não evoluem.
Não posso opinar sobre .Net até fazer o curso que estou planejando. O mercado está pedindo por algum motivo. Mas posso por exemplo comparar o VB6 ao Swing. Desenvolver no VB6 é muito mais produtivo que no Swing. Não da nem para comparar. E o principal motivo é o espaguete como dito acima. No VB não tem esse negócio de Pattern não, é tudo ali, juntinho no código. Aí tem gente que vai dizer que da pra fazer diferente. Claro que dá, mas perde produtividade. E a manutenção? Para isso sem duvida o Swing é melhor, uma vez que você já aprende a fazer de forma mais organizada, tem conceitos diferentes, é realmente orientado a Objeto e etc, mas produtividade… Agora uma coisa que me deixou muito feliz quando migrei de VB para java foi me livrar daquelas porcarias de DLL. O inferno que era aquilo. Só que minha alegria durou pouco. Assim que fui apresentado ao Tomcat e ao JBoss e comecei a usar a commons lib da apache, eu percebi que linguagem só muda o nome, no fim das contas é tudo igual.
[quote=mvargens]Bom primeiro gostaria de avisar que esse post é minha opnião. Não que vale alguma coisa, mas é uma maneira de receber notificações sobre as postagens, já que achei as postagem interessantes e quero acompanhar.
Eu acho que o Browser é uma aplicação cliente e de certa forma Desktop. Talvez algum guru consiga fazer um browser que rode dentro de um browser na web. Sei la vai saber né. No celular ainda não tem, mas o futuro ta logo aí. Vamos ver se o Google faz um.
Para mim C, VB6 e Delphi estão mortos. Não porque ninguém quer usar mais, mas porque não evoluem.
Bom, é muito forte dizer que estão mortos e não evoluem, quem não evolui é ameba que tem na mão ferramentas boas e não sabe o que fazer com elas, na verdade a maioria nem programador é, são usuários de libs/frameworks, coisa mastigada que ajuda a agilizar o aplicativo final, C/C++ ficou com o estigma de ser difícil e de deixar o developer seguir caminhos errados. Esta linguagem é padrão de industria para infra estrutura, será que o Java foi feito em Java puro? O Linux foi feito em Java? Pasmem, faz poucos anos que a JVM ganhou velocidade para ser tratado como algo sério a adotar.
Não posso opinar sobre .Net até fazer o curso que estou planejando. O mercado está pedindo por algum motivo. Mas posso por exemplo comparar o VB6 ao Swing. Desenvolver no VB6 é muito mais produtivo que no Swing. Não da nem para comparar. E o principal motivo é o espaguete como dito acima. No VB não tem esse negócio de Pattern não, é tudo ali, juntinho no código. Aí tem gente que vai dizer que da pra fazer diferente. Claro que dá, mas perde produtividade. E a manutenção? Para isso sem duvida o Swing é melhor, uma vez que você já aprende a fazer de forma mais organizada, tem conceitos diferentes, é realmente orientado a Objeto e etc, mas produtividade… Agora uma coisa que me deixou muito feliz quando migrei de VB para java foi me livrar daquelas porcarias de DLL. O inferno que era aquilo. Só que minha alegria durou pouco. Assim que fui apresentado ao Tomcat e ao JBoss e comecei a usar a commons lib da apache, eu percebi que linguagem só muda o nome, no fim das contas é tudo igual.[/quote]
Tudo é jogada de marketing, vai na conversa dos outros quem quer, mas o certo que aqui é falar de Java, C/C++ deve ser falado com o pessoal que move a industria de software, estão em outro nível.
Eu tenho trabalhado com o .Net, e me irritado muito. Os componentes as vezes não se comportam da forma esperada e, quando vc procura num fórum da MS a solução, surpresa, a própria MS recomenda uma gambiarra. Ok, ainda tenho muito o que aprender, e posso estar sofrendo só por ainda estar escalando a curva de aprendizado, portanto, considerem que estou só resmungando por enquanto.
O C#, por si só, é uma linguagem excelente. É tão fácil quanto o Java, tem alguns recursos de programação muito interessantes, como sobrecarga de operadores ou ter implementado de generics da forma certa. A API também é legal, e conta com o poderoso LINQ.
Eu não recomendo a ninguém o VB6. E olha que trabalhei muitos anos com a linguagem. Aquele lixo deveria ser publicado como exemplo do que não se deve fazer. Eu posso citar diversos pontos negativíssimos da linguagem, como o famoso “On error resume next”, ou como as variáveis serem Variant por padrão, funções serem public, ou declarações enganosas como essa:
Onde a variável y é inteira, mas a variável x foi implicitamente declarada como Variant. Fora coisas irritantes como “se vc referenciar um objeto dentro de um form, o VB o torna automaticamente visível”.
Usei Java Swing por mais de 5 anos, usando como ambiente visual o VEP. Muito bom, era tão rápido quanto desenvolver em Delphi ou VB. Só para constar trabalhei por 2 anos com C++ Builder e 2 anos em Delphi.
Uma coisa que gosto do Java é que as APIs da Sun, de maneira geral, são bem puristas. Encontramos quase nenhuma gambiarra, as coisas funcionam exatamente como o esperado. Tudo é muito simples e intuitivo. As interfaces são bem projetadas, o que permite desenvolver código bem flexível com muita facilidade. Tenho esses mesmos elogios para a VCL da Borland.
A MS tem o bom e velho problema de ser proprietária, e de não estar lá muito aí para compatibilidade. Passei infernos para mover do VB4 para o 5, do 5 para o 6, e não há conversão do 6 para o .net (a ferramenta para conversão automática funciona bem para aplicações do tipo “Hello world”). Alguns colegas que estão a mais tempo no C# reclamam a mesma coisa sobre o .net framework.
Uma coisa que sinto-me à vontade no Java é com fazer com tranquilidade os updates de versão. Meu código 1.4 roda perfeitamente no Java 1.6.
Tenho experiência com C++. Trabalhei vários anos com ele, desenvolvi jogos na linguagem. É uma linguagem excelente e a maioria que reclama dela, ainda está trabalhando com o C++ de 1980. Nunca sequer ouviram falar das coisas “novas”, como RAII, Smart pointers ou da boost. Mas realmente, é uma linguagem mais difícil que o Java, e eu não recomendaria fazer aplicações web com ela, por exemplo. Mas, se for fazer uma aplicação desktop, e tiver que integrar um pouquinho mais com o SO, é uma excelente opção. No Java, vc não tem acesso ao SO, até pela própria proposta da plataforma. Ou seja, nada de interagir com direct3d, direct sound, controles, drivers de DVD, portas USB, scanners, webcams, etc…, etc…, etc… Mesmo que você use um binding, você sempre estará um passo atrás, e sempre correrá o risco daquele binding demorar muito, ou nunca ser atualizado. É diferente de recém comprar a última placa da NVDIA, baixar o SDK no site e já sair usando.
Fora que, se você um dia pretende entrar no mercado profissional de games, programar para qualquer console, terá que aprender C++. Para quem acha que as aplicações desktop estão fora de moda, considerem a indústria de video-games, só para terem certeza do quanto estão errados. Quem fala isso também desconsidera a maior parte das aplicações da indústria, que tem requisitos de tempo real, que não podem ser cobertos pelo Java e que estão muito longe de sequer se aproximar da web. E também desconsidera boa parte da área de pesquisa tecnológica. Todas áreas bem remuneradas e com grande abertura de contratações anualmente.
[quote=cawink]mesmo com netbeans, todas classes visuais eu escrevo na mão, toda estruturação do gridbag, componentes, etc etc.
Por que isso?
O dia que você fizer algum refactor em um ambiente mais complexo, com milhoes de linhas, com aqueles forms nojetos por trás, talvez irá entender.
[/quote]
bom, o codigo só é nojento porque alguem o fez assim. Não é culpa da ferramenta ou da linguagem ou da plataforma.
Se vc estruturar seu codigo orientado a objetos vc não terá esse tipo de problemas. Ok, eu entendo que muito poucos sabem que têm que construir camadas acima do swing, mas isso não é culpa do swing e sim dessas pessoas que não aprenderam direito ( mais uma vez o problema de aprender sozinho em vez de aprender com quem sabe)
O .NET é orientado a RAD. Reparem que essa coisa de amarrar componentes gráficos ao banco é amadorismo. Cadê a separação em camadas ? O fato da plataforma ter este tipo de objeto - que não se encontram no java padrão - já leva as pessoas no caminho errado. Bons programadores OO , aliás, bons programadores sem mais, nunca fariam isto. Então o problema, sim é, como alguem disse ,rad vs não rad. .NET e todas as ferramentas da microsoft sempre foram RAD. mas RAD significa que é rápido de fazer, não de manter. Para ter um baixo custo de manutenção é preciso ter certas coisas como separação de camadas. E é possivel. Ainda mais facil com ports de algums layer-helpers como o NHibernate.
O netbeans é uma plataforma que suporta rad que sofre o mesmo problema que todas as ferramentas rad. No mundo java tem existem ferramentas rad,mas existe o bom e velho bloco de notas. Isso não é uma questão de ser programador duro de matar,mas que demostra que a plataforma é independente de ferramentas. Alguem usa .NET sem o VS ? aliás, tem como ?
Como o Viny comentou o .NET tem várias gambiarras e vários problemas de implementação e várias limitações porque é suportado pelo windows sobretudo na parte gráfica do windowsforms. O que o windows não pode fazer, o .NET não pode fazer.
Eu acho que este tipo de evento não serve para mais nada senão utilizar o nome do java para suportar o .NET. Se o nome do evento fosse : A Plataforma .NET nem metade das pessoas estaria lá.
como alguem já disse ,tb, essa historia de ficar indo e vindo nas duas plataformas é para quem não sabe programar direito ou, o que eu acho que é mais realista , não têm uma plataforma de aplicação e nem sabem o que é isso. ai tentam utilizar as plataformas .NET e java como plataforma de aplicação e vai tudo pró buraco… é uma pena que a mentalidade e prática dos desenvolvedores ainda seja desse nivel.
Trabalhei 10 anos desenvolvendo software na área de automação industrial, com Delphi, C, C++ e digo com toda certeza que aplicações Desktop estão muito longe de ter um final.
Existem aplicações que necessitam de um poder fogo que fogem da capacidade do java ou .net.
Quero ver alguém fazer um software em microcontrolador com 16K de memória interna em Java.
Vocês devem estar achando que não existe soluções em hardaware com tão pouca memória ? Mas podem te certeza que existe, e fazem miséria.
Hoje em dia utilizo o Java para fazer aplicações na área de gerência de projetos. O java tem ferramentas fantasticas e poderosas para essa finalidade, além de ser uma linguagem muito boa, de fácil compreensão e altamente profissional.
Logo, toda linguagem tem seu propósito para alguma solução ou ambiente.
A RAD do Asp.net (apesar de alguns problemas) é bastante elegante também. Existe separação de camadas, você liga o Table a DataViews (que são como os TableModels). Esses enxergam suas classes de negócio. Mais ou menos como o Swing faz.
Eu trabalhei em apenas um projeto .NET com Windows Forms e gostei bastante, achei simples, as coisas podem ser bem divididas como disse o Vini, o Visual Studio, apesar de eu ainda preferir o eclipse, é bastante intuitivo.
Agora eu tenho uma duvida sobre .NET. Vale a pena investir nele para grandes aplicacoes web sabendo que o que o vai manter de pé no fim das contas é o Windows Server? Ou estou falando besteira?
Na verdade foi uma pergunta generica. O fato de ter que rodar no Windows Server ja nao traz uma certa desvantagem?
No Java, os generics são um recurso de pré-compilação. No C#, são um recurso da linguagem.
Deixa eu dar um exemplo trivial. Em C# é possível criar um método genérico, para a construção de qualquer classe T que tenha um construtor default:
[code]public static T construtor<T>() : where T() {
return new T();
}
…
String x = construtor();
[/code]
Claro que esse exemplo, por si sí, não tem utilidade nenhuma, mas no Java não poder instanciar objetos do tipo genérico as vezes é um grande incomodo.
Outras coisas que são possíveis é testar que tipo tem T dentro de um método.
No caso dos generics, foi o preço que pagamos em Java por ter compatibilidade.
Outro tópico java x .net, ninguém merece!
[quote=sergiotaborda][quote=thiagomont]Só vou dizer uma coisa: a linguagem a ser escolhida não depende apenas de gostos do implementador ou de modismos, mas principalmente da característica da aplicação a ser desenvolvida.
[/quote]
O ponto é que esse argumento é pura charlatanice. Que características são essas que fazem a diferença ? O que é possivel em um que não é no outro que justifique a escolha ? E não estamos falando só das linguagens e sim das plataformas como um todo. Das soluções como um todo.[/quote]
Primeiro ponto. Cuidado com suas palavras.
Segundo ponto: se a preocupação maior é a plataforma, então se o requisito impedir o uso de certa linguagem, o que fará? Devemos preocupar ocm o requisito, com o que o cliente quer!
Já tive casos de desenvolver aplicativos em que o cliente precisava que rodasse em linux (devido utilização de um servidor já existente) então não julgue um argumento sem antes ter a humildade de saber os motivos. Outros casos o cliente nos obrigou a usar uma linguagem ou um banco determinado (mesmo a equipe de desenvolvimento não concordando por ter um custo mais alto) e desenvolvemos com o que eles queriam (claro com tudo devidamente documentado que a decisão de plataforma foram deles).
Terceiro ponto: toda linguagem tem características que podem impedir o uso sim. Ah não? Usa cobol puro na Web então. Assembler web?. Ou quem sabe usar delphi para dispositivos móveis? Em .NET? Sim, podem existir limitações. Tenta usar .NET em um 486…vai lá!!! Como falei tudo depende dos seus requisitos, sejam eles funcionais ou não funcionais!
ts ts ts . . . incrível como as pessoas são tão simplistas.
Devido o baixo nível de algumas pessoas (disse algumas!!! a maioria está tendo uma discussão saudável) abandonarei este tópico.
[quote=thiagomont][quote=sergiotaborda][quote=thiagomont]Só vou dizer uma coisa: a linguagem a ser escolhida não depende apenas de gostos do implementador ou de modismos, mas principalmente da característica da aplicação a ser desenvolvida.
[/quote]
O ponto é que esse argumento é pura charlatanice. Que características são essas que fazem a diferença ? O que é possivel em um que não é no outro que justifique a escolha ? E não estamos falando só das linguagens e sim das plataformas como um todo. Das soluções como um todo.[/quote]
Segundo ponto: se a preocupação maior é a plataforma, então se o requisito impedir o uso de certa linguagem, o que fará? Devemos preocupar ocm o requisito, com o que o cliente quer!
Já tive casos de desenvolver aplicativos em que o cliente precisava que rodasse em linux (devido utilização de um servidor já existente) então não julgue um argumento sem antes ter a humildade de saber os motivos. Outros casos o cliente nos obrigou a usar uma linguagem ou um banco determinado (mesmo a equipe de desenvolvimento não concordando por ter um custo mais alto) e desenvolvemos com o que eles queriam (claro com tudo devidamente documentado que a decisão de plataforma foram deles).
[/quote]
Nada disso tem a haver com o assunto.
O assunto é : dizem que .NET é melhor para certos fins que java e java para outros. Que a “linguagem” tem caracteristicas que permitem fazer software que a outra não tem e portanto é impeditivo usar a que não tem.
O pergunta é muito simples: enumere essas caracteristicas e fins que justificam esse tipo de frase.
Enumere as do .NET e do Java (que são as que estão em discussão)
Não basta dizer que existe, demonstre dando exemplos.
Só para completar, quando o cliente exige uma tecnologia como requisito então, obviamente não ha escolha nenhuma a ser feita
e portanto não ha necessidade de trade-off e por conseguinte não é preciso conhecer as diferenças entre as plataformas. Nesse cenário, conhecer as plataformas é totalmente irrelevante. Assim como é irrelevante para a conversa deste tópico.
Se vc está tentando decidir entre .NET e Java assume-se que vc pode escolher.
Uma característica do .net, que pode pesar muito é que ele tem boa integração com código nativo. Se sua aplicação exige esse tipo de coisa, mas você também não quer se degladiar com a complexidade do C++ 100% do tempo, será muito mais fácil faze-la em C# do que em Java.
O JNI torna isso possível, mas acredito que ele tenha sido intencionalmente feito complexo justamente para que evitemos o seu uso.
[quote=ViniGodoy]Uma característica do .net, que pode pesar muito é que ele tem boa integração com código nativo. Se sua aplicação exige esse tipo de coisa, mas você também não quer se degladiar com a complexidade do C++ 100% do tempo, será muito mais fácil faze-la em C# do que em Java.
O JNI torna isso possível, mas acredito que ele tenha sido intencionalmente feito complexo justamente para que evitemos o seu uso.[/quote]
O problema da JNI é que se não for usada corretamente, pode facilmente tornar a sua aplicação não portável.
O JNI - espante-se - serve para tornar a sua aplicação portável pois permite que uma feature seja implementada de forma dependente,mas usada de forma independente (aliás é o principio da propria JVM).
O JNA é um passo à frente em que vc integra com componentes nativos em vez de codigo nativo e isso é muito ,muito, melhor.
Sim, se eu precisar de algo nativo do windows tlv usaria .NET. O talvez é porque se está no windows, provavelmente está acessivel pelos DLL do windows diretamente sem passar pelo .NET. Ou seja, mesmo nesse caso o .NET seria opcional. Aliás não vejo algo nativo ao .NET já que o .NET é montado em cima do windows.
Outra forma de resolver, hoje comum, é usar um agente. Ou seja, um programa em outra linguagem que faz um único serviço para a aplicação mae escrita em java. O protocolo pode ser complexo ou um simples o quanto necessário.
O que vou dizer aqui é referente às linguagens, e não á plataforma, e com base na experiência que venho tendo.
C# é uma linguagem muito boa, senão, a melhor que já usei(é um gosto pessoal), pelos seguintes motivos:
*Como o vini citou, generics em c# funciona perfeitamente;
*C# permite sobrecarga de operadores.
*C# tem ampla integração com o hardware(isso não tem nada haver com portabilidade)
*C# é ECMA;
*C# me permite operações com ponteiros, ou coleta de lixo automática(Poder de escolha)
*C# possui delegates;
*C# possui structs, o que o torna ótimo para desenvolvimento de protocolos de comunicação. (structs são alocadas na pilha, então posso transferir uma struct inteira pela rede. Com uma clesse, isso não é possivel).
*C# possui reflection
*C# possui ponteiros seguros como c++ (IntPtr), e várias classes que permitem gerenciar esse tipo de dado com facilidade(Marshal)
*C# possui tipos unsigned(não sinalizados), que também são importantes no quesito desenvolvimento de protocolos de comunicação entre plataformas.
Ao meu ver, java peca apenas e, algumas restrições que a linguagem impõe:
*Ausência de uma boa integração com hardware e multimedia;
*Gerenciamento de ponteiros;
*Suporte a tipos não sinalizados (unsigned);
No mais, as melhores ferramentas são java(A maioria opensource e gratuita).
Apenas enumerar diferença também não adianta. Será que é tão dificil entender o objetivo da coisa.
O objetivo é enumerar “vantagem” ou “desvantagens”…
[quote=juliocbq]O que vou dizer aqui é referente às linguagens, e não á plataforma, e com base na experiência que venho tendo.
C# é uma linguagem muito boa, senão, a melhor que já usei(é um gosto pessoal), pelos seguintes motivos:
*Como o vini citou, generics em c# funciona perfeitamente;
*C# permite sobrecarga de operadores.
[/quote]
Em java simplesmente não ha necessidade de instanceOf T e t.newInstance() porque em java generics é um tipo de assinatura forte e não um mecanismo de template como na familia C. Independentemente disso, não ha aplicação que seja impedida por essa diferença. O mesmo com a sobrecarga. Que uso vc fez disso que não , não podendo fazer em java o impediria de usar java ?
Essa não entendi…
hardly an argument… java é JCP , e dai ?
E isso é bom ? O que vc consegui fazer com isso que não consegue com java ? (memory leak ? lol)
Ponteiros seguros, inseguros, com CG , sem CG … parece que o problema foi agradar a gregos e troianos…
O que isso lhe permite fazer que é impossivel em java e impeditivo de fazer as aplicações ?
Em java eventos são tratados como simples chamadas. Não ha necessidade de delegates “escondidos”.
Tudo bem que delegates não serve só para isso , mas então… o que a falta deles impossibilita na prática?
Tudo bem que classes não ficam no stack ( em java real time algumas ficam… ) mas quanto a rede não ha diferença. RMI serve exactamente para isso.
bom, isso não é diferença. Java tb. Não só isso como bytecode rewrite (veja a classe Proxy do java)
raios partam… java tb tem tipo unsigned. chama-se char.
O que vc quer dizer é que “byte em java não tem a mesma definição que byte em C” ok, e porque deveria ter ?
Afinal bytes podem ser bigendian e small e vc não quer um tipo diferente para cada…
O protocolo de comunicação não ser implementado com “unsigned-byte” muda alguma coisa ? Não. várias bibliotecas existem que trabalham com todos os protocolos binários. Isto tb não é uma razão que impossibilite o uso de java para qualquer aplicação que utilize um protocolo , ou leitura de arquivos binários. Se isso é um grande problema vc pode criar uma API para trabalhar com esses tipos usando wrappers ou convenções sobre o byte do java (que é o que faz a API do google)
A plataforma java é uma plataforma virtual, isto significa que está acima do OS. Não se mistura promiscuamente com o OS
e nunca acessa coisa abaixo do OS. hardware é abaixo do OS.
Não se pode esperar que java tenha integração com hardware (seja lá o que isso signifique) espera-se que ela tenha integração como o OS. Além disso bibliotecas/software que corram no mesmo OS ( como decoders e encoders)
O máximo que pode ser dito é que a integração como OS e essas bibliotecas é fraco (sic) como openGL e directX. Mas esperar comunicação com o hardware é absurdo, isso nunca será feito. Duvido até que o .NET faça.
Tudo bem, entendemos que .NET deve ser usado se vc quer ficar brincando com ponteiros. Essa é a unica diferença relevante que pode trazer alguma vantagem/ desvantagem. Fora isso , é tudo sintax sugar.
Claro que agora eu perguntaria para que raios preciso controlar os ponteiros manualmente e vcs me responderiam que para aplicações de tempo real como jogos. humm… então como é possivel ter servidores e API de jogos em java (como o darkstar, por exemplo) ou mecanismo de desenho como o Java 3D e o jmonkey engine?
Discordo, em Java não existe essa possibilidade, mas a necessidade existe sim. Tanto que uma abordagem comum é contornar isso com reflection.
Em C# os generics também representam assinatura forte, e não templates. Mas não se pode negar que as duas construções poderiam são sintaticamente fortes, mesmo no conceito do generics, e só não são possíveis no java pela implementação escolhida, não por uma limitação do conceito.
Não inviabiliza nada. Mas não deixa de ser um recurso interessante. Pela sua linha de argumentação, poderíamos dizer que generics são inúteis. Afinal, não há nada que não se possa fazer sem eles (pelo menos na forma que foram implementados no Java).
Java possui apenas um único tipo unsigned, que serve para representar caracteres, não números. E isso, para quem programa protocolos com outras aplicações é realmente um pé no saco. Tente interoperar com qualquer linguagem que suporte os unsigned num protocolo binário, que você vai sentir o inferno.
E, note, que esse protocolo pode ter sido criado pelo fabricante de um harware ou do software terceiro, que não estava nem um pouco com a falta do unsigned no Java. Ainda acho que as classes de comunicação do Java tinham que ter, no mínimo, métodos que fizessem a promoção automática dos tipos de dados vindos da rede.
E se afetam, afetam sim. Já tentou ler um unsigned byte? Você tem que lê-lo num short. E tomar cuidado para fazer um & 0xFF para que o primeiro bit não seja interpretado como sinal. Além disso, é muito ruim trabalhar com o tipo unsigned long, muito usado para timestamps.
Pelo menos as classes que estão na “borda” da rede, deveriam garantir uma conversão simples e rápida para tipos comumente usados fora do Java. A classe ByteBuffer incluiu endianess, mas ficou faltando tratar o unsigned, na minha opinião. (Não estou falando em adicionar tipos novos na linguagem, mas simplesmente um método que me permita ler 2 bytes num int, 4 bytes num long, ou 1 byte num short, 8 bytes num BigInteger, e vice-versa, sem que haja interpretação de sinal).
[quote]
Não se pode esperar que java tenha integração com hardware (seja lá o que isso signifique) espera-se que ela tenha integração como o OS. Além disso bibliotecas/software que corram no mesmo OS ( como decoders e encoders)[/quote]
Concordo. Mas isso só significa que é uma limitação “planejada” da linguagem. Mas ainda assim, uma limitação. E isso a torna desinteressante em muitos casos.
APIs como o JMonkey existem pq fazem binding, usando JNI, ou seja, saem do escopo do Java. Não sei detalhes do projeto DarkStar, mas no caso de jogos de rede, a latência é um problema sério, e contorna-se com xunxos gráficos.