Plataforma Java x Plataforma .net

sergiotaborda wrote:instanceof T é absurdo porque se T é genérico vc não deveria estar tentando saber que tipo ele é.

Não é absurdo, porque T representa um tipo. Nesse caso, deveria ser possível testa-lo. Type erasure vem com limitações e nega-las é agir com ignorância.

Não poder testa-lo é só uma dessas limitações. Da mesma forma, construir um T não é absurdo porque T pode ser construído.

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.

Ainda não há solução para se construir T, ou se testar se um determinado objeto é do tipo de T, sem apelar para a reflection. E reflexão, apesar de remover a limitação, costuma a ser insegura e só verificada em runtime.

Você também não pode testar se uma lista é instanceof List<String> ou instanceof List<Int>. Afinal, para o Java, ambas as listas representam exatamente o mesmo tipo. Você não pode testar dentro de seu código que tipo tem T.

Todas são limitações. São limitações terríveis? Não. Mas podem te incomodar, dependendo do que você esteja fazendo.

sergiotaborda wrote:
Sim. generics servem apenas para assinar fortemente. Só.
Se não ha limitações impostas pela diferença de implementação, este ponto não é portanto relevante à discussão.

Não concordo que seja irrelevante. Não está sendo comparado somente o que as linguagens são capazes, mas como. Se for comparar só o que podem fazer, então, assembly será tão bom quanto Java.

Isso é um missconception comum. char , embora o nome, é um numero. O que acontece é que existem os literais de char que o java mapeia pela tabela UTF-16. São os literais, não o tipo, que representam caracteres. vc pode escrever char c = 3 sem problemas
e pode fazer operações ariméticas sem problemas (bom, como os mesmo problemas que com os outros tipos numericos diferentes de int)
char pode representar o que vc quiser. Acontece apenas que o java lhe dá essa canja de poder usar para representar caracteres (em um certo encoding). Mas isso não é de longe nem de perto limitativo.

Imprima um char. O que aparece? Um número? Por que o Java faz a conversão implícita?

O tipo char representa um caracter, codificado na forma de um número. Ele pode ser convertido para uma representação numérica, mas ele não é um número. A definição de char, dada pela sun, é:

Sun wrote:char: The char data type is a single 16-bit Unicode character. It has a minimum value of '\u0000' (or 0) and a maximum value of '\uffff' (or 65,535 inclusive).

Trata-lo como um número é só uma forma de simplificar diversas operações, mas é, na prática, uma violação do conceito do tipo char em si. É lidar com a sua forma bruta, o que não deveria ser feito. É como tratar o String como um array de números, ou dizer que o um int é formado por 4 bytes de -127 até 128. Tudo isso é verdade, mas não é o que o tipo foi criado para representar.

Ele foi criado para tratar caracteres. A "canja" que o Java dá é justamente ao contrário: permitir que ele seja tratado como um número.

Se deveria haver um classe, então escreva-a. Essa coisa de esperar que a plataforma lhe dê tudo não é razão.
Se deveria haver um tipo diferente, já argumentei.

É razão sim, já que estamos comparando duas plataformas. Por mim, isso é um recurso muito básico, e qualquer API de classes que se propusesse estar na "borda" entre duas aplicações deveria tratar esse detalhe. Eu já escrevi essa classe, como provavelmente milhares de programadores que já precisaram fazer isso, em operações de I/O por aí.

Aliás, isso já foi solicitado para a Sun também.

C# suporta o tipo unsigned, e não tem esses problemas. O Java não trata o tipo primitivo unsigned long e, se você precisar dele, terá que recorrer a operações matemáticas lentas, na classe BigInteger. Específico? Talvez, mas uma limitação do mesmo jeito.

Finalmente, é fácil usar o argumento de "implemente você". Nesse caso, eu deveria dizer que o LINQ não pode ser levado em conta, pq poderia ser implementado em Java? Acho que não... é um recurso importante, que está na API padrão da plataforma .net.

Usando o argumento de "implemente você", você simplesmente abre mão de comparar as APIs padrão, já que, por definição, tudo o que está lá poderia ser implementado na linguagem.

aliás java explicitamente não tem unsigned por causa do critério de segurança (pela mesma razão que não tem ponteiros e destrutores e outras coisas assim.... afinal java não é da familia C)

Desculpa para boi dormir. Tipos com sinal não são inseguros. Se quer segurança, você teria que ter formas de definir ranges de maneira geral.

Mas se fosse impossível ter acesso a esses recursos , coisas como o JMonkey seriam impossíveis. O ponto é que a plataforma Java sim pode ter acessos nativos do nivel que vc quiser não impossibilitando nenhum projeto ou obrigando a escolher outra plataforma.

Esses recursos são implementados através de C, não de Java. Fora que é um processo lento, difícil e extremamente sujeito a erros. Um driver JNI se torna uma implementação complexa e insegura.

Em C#, o código fica limpo, elegante e facilmente integrado. O que acaba gerando um número de bindings maior e menos sujeito a erros. Não se pode negar que é uma vantagem sobre o Java. Isso é, se você não considerar que o programador é idiota, e que só pq esse recurso é mais fácil por lá, eles vão sair usando a torto e a direta. Aliás, o recurso é fácil, mas continua não sendo trivial, e na prática, não está sendo usado indiscriminadamente pela comunidade C#.

as diferenças sintáticas e semânticas das linguagens são detalhes , firulas. O que interessa para um arquiteto é a capacidade de responder às qualidades esperadas. E isso é a plataforma como um todo que oferece. Indo, até, além das fronteiras dos SDKs ...

Nem sempre, muitas diferenças sintáticas podem evitar erros, ou tornar o código consideravelmente mais legível. Admito que elas podem ser evitadas, mas uma linguagem poderia só ter o comando "while" por exemplo, e não ter for nem for each. Mas não se pode negar que ficou mais fácil e agradável programar em Java depois do for..each e, de quebra, essa instrução evitou alguns erros comuns.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

ViniGodoy wrote:

sergiotaborda wrote:instanceof T é absurdo porque se T é genérico vc não deveria estar tentando saber que tipo ele é.

Não é absurdo, porque T representa um tipo. Nesse caso, deveria ser possível testa-lo. Type erasure vem com limitações e nega-las é agir com ignorância.

Não poder testa-lo é só uma dessas limitações. Da mesma forma, construir um T não é absurdo porque T pode ser construído.

Na prática esses recursos que vc identifica não impedem a criação de aplicações de um certo tipo.
O seu argumento virou então que em .NET , com C# (atenção ao detalhe de comparar as linguagens, porque em VB não ha signed byte.. e o argumento ao contrário)... algumas aplicações podem ser feitas mais depressa.

Que tipo de aplicações são essas que podem ser desenvolvidas mais depressa ?
Até agora duas areas : perto do hardware e protocolos , e windows forms

Ok. Java realmente não é para hardware e protocolos - embora como vimos não é impossivel - já que uma coisa que pode fazer com .NET é DLL - que é algo mais de intra - e forms são para todos os OS por default o que significa que certas regras tem que ser seguidas.

Otimo. Vc faz esse tipo de coisa muito rapidamente (segundo vc mais depressa e com menos problemas que se fosse em java). Ok.
Agora vc quer utilizar essa vantagem para competir com o cara que, como eu, usaria java, mesmo sendo mais "lento".
Vc vende o seu sistema para empresas que usam a plataforma windows. E eu vendo para quem usa a plataforma windows e as outras.

Vc acha que é o trade-off de velocidade/facilidade por portabilidade compensa ?
Ok, cada caso é um caso, mas a menos que haja exemplos concretos de estudos que foram feitos para uma aplicação X e se provou que .NET teria maior ROI a longo prazo é difícil entender como Y porcento do mercado é maior que Y+Z do mercado.

Os meus pontos, que ainda não refutaram são:

- detalhes da linguagem são detalhes. Não impedem nada ou tornam nada mais possível que antes. No máximo dão velocidade (RAD) mas não são impedimentos.
- a velocidade obtida por esses meios não compensa a longo prazo, pelo que, mesmo sendo mais RAD não é automáticamente uma boa escolha devido ao OS lock-in já que uma aplicação java nunca ficará obsuleta. Nunca terá que ser re-escrita quando a versão mudar. E isso, mesmo considerando apenas o windows (.NET vs java no windows apenas) ainda é uma vantagem estrondosa que mata qualquer uma vantagem de velocidade.

Ok, agora, se vc faz software de vida curta, sim. Ai vale a pena usar o .NET. Aplicações que são escritas para durar um ano ou dois.
Mas, na boa, fazer aplicações assim é se aproveitar dos clientes. Pois uma das qualidades dos sistemas é a longividade. se tem data para morrer, de que serviu o investimento ? O ROI para a empresa que faz o software é alto e o cliente que se f...
Não é um tipo de politica profissional que eu entendo nem pratico e tlv por isso não use o .NET... eu entendo que mercadologicamente falando existam pessoas usando dessa forma, não os censuro, mas não me venham dizer que .NET é melhor que Java. Ele é para um nicho. java é para qualquer coisa.

dito assim parece meu megalomano, mas o problema não é do java, e sim do uso do java (e até do .NET, ruby, etc) que é a falta de investimento em Plataformas de Aplicação (que o java não é)

Se vc tem uma plataforma de aplicação para o seu ramo de negocios vc consegue ser um Time to market mais pequeno ainda que fazendo drag-and-drop.

Não só mais depressa, mas também com mais segurança.

Quando você tem recursos na linguagem que te permitem codificar com mais tranquilidade, você ganha em produtividade e poupa em manutenção. O que, no final das contas, te reduz custos. IDEs, por exemplo, só geram um ganho estético no código. Você poderia abrir mão de code completion e sintax coloring, mas você faria isso?

Nós questionamos o RAD pq, em excesso, ela é restritiva e pode gerar um código ruim. Mas RAD bem feito é mais produtivo e lucrativo do que uma aplicação sem RAD. Não é a toa que o matisse e o visual editor são populares. Eu usei o VE por anos, e era certamente muito mais produtivo com ele, do que se quisesse escrever todas as classes do Swing no braço.

Vender para clientes em mais plataformas é relevante? Bem, depende muito do que você esteja vendendo. Uma aplicação desktop, por exemplo, tem como clientes um mercado dominado em mais de 95% pelo Windows. Será que compensaria usar uma linguagem mais difícil, se estamos falando em 5% de um público provável? É como você falou, é muito difícil medir esse recurso ou aquele pelo retorno sobre investimento, porque o retorno vai variar de acordo com cada caso, cada empresa, e cada nicho de mercado. Pq retorno não envolve só informática, mas questões administrativas também.

sergiotaborda wrote:eu entendo que mercadologicamente falando existam pessoas usando dessa forma, não os censuro, mas não me venham dizer que .NET é melhor que Java. Ele é para um nicho. java é para qualquer coisa.

Mercadologicamente falando*, Java tambem eh para um nicho bem estabelecido: aplicacoes comerciais de medio a grande porte rodando num servidor Unix-like. Funciona pra outras coisas? Sim, claro. Assim como .NET, que pertence a um nicho similar.

Tem ferramenta RAD, features ruins e programadores extremamente ruins nas duas plataformas quase que na mesma medida.

* R$ 40 pra quem fizer uma camiseta com isso!

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

ViniGodoy wrote:Não só mais depressa, mas também com mais segurança.

Nós questionamos o RAD pq, em excesso, ela é restritiva e pode gerar um código ruim. Mas RAD bem feito é mais produtivo e lucrativo do que uma aplicação sem RAD. Não é a toa que o matisse e o visual editor são populares. Eu usei o VE por anos, e era certamente muito mais produtivo com ele, do que se quisesse escrever todas as classes do Swing no braço.

É exactamente isso que eu quero dizer quando digo que falta investimento numa plataforma de aplicação.
Eu adoro swing, mas nunca escrevi uma aplicação swing no braço ou usei um drag-and-drop. Eu tinha uma plataforma que criava as telas para mim , a definição da tela era em xml ou codigo e o plumbing de eventos era automatizado pela plataforma.
Fazer a tela aparecer era sem trabalho porque por default a plataforma lia as propriedades e adicionda os campos. apenas se precisasse alterar o layout ou costumizar algum evento que precisava alterar o default.

É tão RAD ou mais que drag and drop mas tem um custo de desenvolver a plataforma. contudo, se paga rápidamente e tanto mais rápidamente quanto mais aplicações vc faz. Se vc não ter este tipo de trabalho ,vc pode usar frameworks por que fazem algo semelhante (thinlet por exemplo) , mas por muitos frameworks que vc aglutine sempre precisa haver um jeito desacoplado de os usar.

O problema com a 'lentidão" do java é a falta de compreensão de como se usam as API ( não o uso tecnico, mas o proposito delas)
O .NET supre uma parte dessa plataforma de aplicação, pela mao da MS, que ftaz algumas coisas prontas.Mas prontas do ponto de vista da MS que nem sempre é que precisamos.

Java é feito para ser uma plataforma virtual e por isso ele é generico e extensivel e as api são mais limpas e mais discutidas.
é tb por isso que existem milhentos frameworks em cima. estes frameworks são partes de uma plataforma de aplicação (componentes) que devem ser unidos com outros para produzir alguma coisa. É aqui, no mushup , que os desenvolvedores java em geral falham. Porque eles não compreendem a diferença.
em NEt com mais coisas já prontas ha menos procura pela costumização, expansão , etc... e .NET ela própria vira a sua plataforma de aplicação. Mas ela foi engendrada para isso, logo funciona. Até um certo nivel. Quando vc quiser expandir do jeito que se faz no java vc encontra limites impostos pelas apis, a documentação, etc... o ambiente como um todo.

Não concordo que java é apenas para servidores unix porque isso seria dizer que java é só JEE. O que é falso.
A maioria das aplicações são web, mas não EE e utilizam apenas os recursos do SE. Além disso temos os applets que volta e meia são solução para muita coisa no lado cliente.

ViniGodoy wrote:
Vender para clientes em mais plataformas é relevante? Bem, depende muito do que você esteja vendendo. Uma aplicação desktop, por exemplo, tem como clientes um mercado dominado em mais de 95% pelo Windows. Será que compensaria usar uma linguagem mais difícil, se estamos falando em 5% de um público provável? É como você falou, é muito difícil medir esse recurso ou aquele pelo retorno sobre investimento, porque o retorno vai variar de acordo com cada caso, cada empresa, e cada nicho de mercado. Pq retorno não envolve só informática, mas questões administrativas também.

Vyni, perai também né. Vamos com calma. A linguagem é um pouco mais difícil levando em considerações suas argumentações. Talvez menos que os 5% que vc está levando em consideração como publico alvo. Dependeria do tipo de aplicação claro, mas para a maioria dos casos seria uma margem muito pequena. Conheço 3 hipermercados, fora algumas lojas do varejo (incluindo multinacionais) que optaram por linux no PDV e bancada para diminuir custos. Nesse caso o .NET rodou por não ser multiplataforma e ser mais caro que o conjunto Linux + java, segundo eles. O varejo é muito chato com dinheiro. E acredite, o volume de maquinas é muito grande se somados. Sinceramente, eu não acho que o Windows ainda domine 95% do mercado corporativo, esse número deve ser menor, mas isso é achismo mesmo.

GUJ Master Membro desde: 04/06/2007 17:47:24 Mensagens: 1030 Offline

ViniGodoy wrote:Não só mais depressa, mas também com mais segurança.

Quando você tem recursos na linguagem que te permitem codificar com mais tranquilidade, você ganha em produtividade e poupa em manutenção. O que, no final das contas, te reduz custos. IDEs, por exemplo, só geram um ganho estético no código. Você poderia abrir mão de code completion e sintax coloring, mas você faria isso?

Nós questionamos o RAD pq, em excesso, ela é restritiva e pode gerar um código ruim. Mas RAD bem feito é mais produtivo e lucrativo do que uma aplicação sem RAD. Não é a toa que o matisse e o visual editor são populares. Eu usei o VE por anos, e era certamente muito mais produtivo com ele, do que se quisesse escrever todas as classes do Swing no braço.

Vender para clientes em mais plataformas é relevante? Bem, depende muito do que você esteja vendendo. Uma aplicação desktop, por exemplo, tem como clientes um mercado dominado em mais de 95% pelo Windows. Será que compensaria usar uma linguagem mais difícil, se estamos falando em 5% de um público provável? É como você falou, é muito difícil medir esse recurso ou aquele pelo retorno sobre investimento, porque o retorno vai variar de acordo com cada caso, cada empresa, e cada nicho de mercado. Pq retorno não envolve só informática, mas questões administrativas também.

Adoro tudo que é Unix-like. Mas tenho que reconhecer, a briga com a Microsoft já está perdida no Desktop faz tempo. Poderiamos até dizer que o Mac OS daria para brigar de frente com o Windows se o danado não tivesse tudo enlatado em uma máquina de beleza radiante e bem cara para a tecnologia usada em termos de hardware.
Nestas horas, infelizmente, fazer um sistema desktop em .Net é mais vantagem. Não adianta a pessoa alegar licença do Windows porque, é barato quando se compra com PC novo. Mais barato ainda em quantidade. Ainda que, a pessoa prefira o Linux, o Mono para desktop também é muito bom.
Logo, concordo contigo em dizer que retorno envolvendo também questões administrativas são levadas em consideração. E produtividade também.

GUJ Master Membro desde: 04/06/2007 17:47:24 Mensagens: 1030 Offline

mvargens wrote:

ViniGodoy wrote:
Vender para clientes em mais plataformas é relevante? Bem, depende muito do que você esteja vendendo. Uma aplicação desktop, por exemplo, tem como clientes um mercado dominado em mais de 95% pelo Windows. Será que compensaria usar uma linguagem mais difícil, se estamos falando em 5% de um público provável? É como você falou, é muito difícil medir esse recurso ou aquele pelo retorno sobre investimento, porque o retorno vai variar de acordo com cada caso, cada empresa, e cada nicho de mercado. Pq retorno não envolve só informática, mas questões administrativas também.

Vyni, perai também né. Vamos com calma. A linguagem é um pouco mais difícil levando em considerações suas argumentações. Talvez menos que os 5% que vc está levando em consideração como publico alvo. Dependeria do tipo de aplicação claro, mas para a maioria dos casos seria uma margem muito pequena. Conheço 3 hipermercados, fora algumas lojas do varejo (incluindo multinacionais) que optaram por linux no PDV e bancada para diminuir custos. Nesse caso o .NET rodou por não ser multiplataforma e ser mais caro que o conjunto Linux + java, segundo eles. O varejo é muito chato com dinheiro. E acredite, o volume de maquinas é muito grande se somados. Sinceramente, eu não acho que o Windows ainda domine 95% do mercado corporativo, esse número deve ser menor, mas isso é achismo mesmo.

Conheço algumas empresas que estão usando Linux. Mas lamento, muitos não são Java na tela que usam. Fora que, se for usar terminal, até Mono serve e ainda pode ser mais vantagem para acessar componentes das máquinas PDV.
[EDIT]
Procurem pelo Daruma, muito usado em PDVs.
[/EDIT]

djemacao wrote:Conheço algumas empresas que estão usando Linux. Mas lamento, muitos não são Java na tela que usam. Fora que, se for usar terminal, até Mono serve e ainda pode ser mais vantagem para acessar componentes das máquinas PDV.

Tudo bem, mas preferir .Net a java por causa da MS é uma coisa, agora preferir o Mono ao java por causa da MS é outra. Não faz muito sentido ja que mono não é .Net e Ms não da suporte no Mono.
É uma pena essas empresas não usarem java, estão perdendo muito dependo do que estiverem usando, mas enfim, não é widows também, o que torna meu achismo mais coerente. De qualquer forma eu achei a estratégia dessas empresas interessante.

GUJ Master Membro desde: 04/06/2007 17:47:24 Mensagens: 1030 Offline

mvargens wrote:

djemacao wrote:Conheço algumas empresas que estão usando Linux. Mas lamento, muitos não são Java na tela que usam. Fora que, se for usar terminal, até Mono serve e ainda pode ser mais vantagem para acessar componentes das máquinas PDV.

Tudo bem, mas preferir .Net a java por causa da MS é uma coisa, agora preferir o Mono ao java por causa da MS é outra. Não faz muito sentido ja que mono não é .Net e Ms não da suporte no Mono.
É uma pena essas empresas não usarem java, estão perdendo muito dependo do que estiverem usando, mas enfim, não é widows também, o que torna meu achismo mais coerente. De qualquer forma eu achei a estratégia dessas empresas interessante.

Questões talvez mercadológicas ou de desenvolvimento, quem sabe? Mas acredito, pessoalmente, que foi mais fácil migrar as DLLs do .Net (que podem ter sido até feitas usando C#, quem sabe) para o Mono em PDVs da Daruma a ter de construir uma biblioteca nativa e acessível por Java (claro, o custo disso não deveria ser nada barato).

This message was edited 1 time. Last update was at 21/10/2009 13:29:38

sergiotaborda wrote:repare no método

public <T> T newInstance(){ }

Mesmo que não houvesse erasure não é possivel saber quem é T porque se trata de um método puramente co-variante.
Para este método ter acesso a algum T real o T precisa ser definido na classe

Sérgio, há uma outra opção. Você pode explicitar o tipo de T ao chamar o método:

Assim o compilador não precisa do T definido em outro lugar para inferir o tipo.

Mais detalhes em http://cabritin.wordpress.com/2009/10/06/passagem-explicita-de-tipos-para-metodos-genericos-em-java/

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

tnaires wrote:

sergiotaborda wrote:repare no método

public <T> T newInstance(){ }

Mesmo que não houvesse erasure não é possivel saber quem é T porque se trata de um método puramente co-variante.
Para este método ter acesso a algum T real o T precisa ser definido na classe

Sérgio, há uma outra opção. Você pode explicitar o tipo de T ao chamar o método:
Classe.<Tipo>newInstance();

Eu não me estava a referir ao método newInstance de Class. Foi um exemplo de um método qualquer... foi mal usar esse nome,
mas decorre da citação da conversa.

GUJ Expert Membro desde: 13/11/2008 12:10:18 Mensagens: 3928 Offline

O fato da lentidão do java não se deve a nenhum programador medíocre. O swing torna uma aplicação java lenta, e não por sua arquitetura, mas por ser totalmente portável. O winforms do .net é um mapeamento em cima do artefato responsável pela gerência de janelas do windows. Rodando em linux, ele passa usar gtk#.

Ao meu ver, acho swing uma das coisas mais interessantes do java, por ser totalmente portável.
Se for fazer benchmark, a jvm é mais rápida que dotNet. O ponto forte do .net na minha opinião é a linguagem c# e suporte a multimedia no win, como directx.
Fora isso java campeão, sem dúvida.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

juliocbq wrote:O fato da lentidão do java não se deve a nenhum programador medíocre. O swing torna uma aplicação java lenta, e não por sua arquitetura, mas por ser totalmente portável.

A conversa sobre a "lentidão do java" é sobre a "lentidão para desenvolver em java" , o chamado time-to-market. Ninguem falou da lentidão de executar. Por favor leiam os textos com calma.

E mesmo a lentidão de execução é coisa do passado. (aliás eu nunca vi o swing ser lento)

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

.

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