Por que o Java é considerado mais portátil que outras linguagens como C ++?

O que difere entre "escrever um JRE específico para cada plataforma" para desenvolvedores Java e "escrever um compilador C ++ para cada plataforma" para C ++?

Java é compilado uma vez executado em qualquer lugar. C ++ é escrever uma vez compilar em qualquer lugar.

"escrever um JRE específico para cada plataforma" não é algo que você faz sempre. Portar o JRE para uma nova plataforma é algo que você precisa fazer apenas uma vez. Essa tarefa geralmente é realizada pelos mantenedores / desenvolvedores principais do programa e / ou da plataforma. Muitos fatores podem entrar em jogo ao decidir quem e como o JRE seria portado. Entre outras coisas, depende do licenciado sob o qual foi publicado (ouvi dizer que Java é Open Source, então acho que alguém poderia fazê-lo). Anedota engraçada, Steve Jobs fez muita coisa por não querer cuidar da portabilidade do Java no Mac , cerca de um ano atrás.

O ponto não é como ou quem move o JRE, mas o fato de que, uma vez portado, todo aplicativo Java agora deve, teoricamente, ser executado facilmente na nova máquina. Nesse sentido, o JRE forma uma camada de abstração, ocultando completamente a máquina, permitindo fácil portabilidade.

No entanto, a realidade nem sempre é bonita assim. Não vou ao ponto de chamar a portabilidade um "mito", mas é verdade que não é tão perfeito. Por exemplo, o Java possui um pacote chamado JNIque permite o envio de chamadas nativas, ignorando o JRE, impedindo a perfeita portabilidade perfeita, o que os fãs de Java gostam de chamar de "Escrever uma vez executado em qualquer lugar".

Como mencionado nos comentários, a abordagem do C ++ para portabilidade é diferente. Por um lado, é uma linguagem compilada e esses binários são quase sempre específicos da plataforma. Portanto, os executáveis ​​do c ++ nunca serão portáveis ​​(ao contrário do Java). Por outro lado, portar o compilador às vezes pode ser suficiente. A comunidade descobriu que, ao transportar o compilador e algumas bibliotecas principais do idioma, os códigos-fonte (e não os binários) podem ser portáveis.

No entanto, o C ++ é amplamente utilizado em sistemas críticos como compiladores, kernels, sistemas em tempo real, sistemas embarcados, ... Há um aspecto de "nível baixo" do C ++ que não pode ser esquecido quando se fala em portabilidade.

Não é apenas a linguagem - são as bibliotecas.

Java e C ++ fornecem bibliotecas de plataforma cruzada. Java fornece um conjunto mais rico.

A diferença é que o Java será executado em qualquer plataforma sem recompilar. Ter um compilador C ++ para cada plataforma não é o mesmo.

Todas as respostas que começam com "A diferença é ...", ou qualquer coisa muito semelhante, estão basicamente erradas (desculpe, mas a vida é assim). Na verdade, existem duas diferenças separadas entre os dois.

Uma (já mencionada muito) é que um programa Java compilado pode (ou pelo menos deve) ser executado em qualquer implementação em conformidade do Java; portanto, mesmo após a compilação, você ainda pode mover um programa Java de uma plataforma para outra sem precisar compilar novamente . C ++ (pelo menos normalmente) requer recompilação para cada plataforma de destino.

A outra é que o Java (pelo menos tenta) garantir que todo o Java corretamente escrito seja portátil. Pelo menos em teoria, você não deve conseguir escrever nenhum código que não seja portátil.

O C ++ permite que você faça várias coisas que não são portáteis. O padrão C ++ contém "avisos" sobre muitas coisas que não são portáveis ​​(por exemplo, informando que você obterá um comportamento definido de implementação ou um comportamento indefinido), mas não necessariamente tenta impedi-lo de fazê-lo. . Apenas por exemplo, se você deseja escrever um sistema operacional para hardware que usa um barramento PCI, provavelmente precisará ler / gravar a memória de configuração PCI. Obviamente, isso não será portátil para sistemas sem um barramento PCI, mas se você estiver escrevendo um sistema operacional para hardware com um barramento PCI, é praticamente necessário. O C ++ permite, mesmo que obviamente não seja portátil.

Você entendeu mal as instalações. Os programas Java são muito portáteis, porque a JVM fornece um comportamento padrão garantido para ser o mesmo. Os programas C ++ têm um ambiente menos padronizado mais próximo do hardware real, portanto, o programa precisa ser capaz de lidar com os vários detalhes específicos da plataforma - como tamanho de um int, alinhamento de palavras, etc, etc.

A própria JVM não é muito portátil. É uma tarefa hercúlea portar uma JVM de alto desempenho para outra plataforma ou arquitetura de CPU.

A diferença é que os programas Java (não é um acrônimo) podem ser distribuídos de uma forma que pode ser executada em qualquer computador com uma JVM instalada, mas o C ++ é normalmente distribuído como código-fonte, o que é muito hostil para o usuário ou como um grupo. de binários diferentes para plataformas diferentes.

Uma das razões pelas quais o Java é considerado portátil é que ele possui regras específicas sobre como as expressões aritméticas devem ser avaliadas e proíbe as implementações de avaliá-las de qualquer outra maneira, mesmo que avaliá-las da maneira exigida exigiria código mais lento do que avaliá-las de maneira mais precisa moda.

Por exemplo, dado

long thing1(int x) {
  return (x+1)-1L;
}
double thing2(int x, float y) {
  return x/y;
}

Os valores de thing1(2147483647)e thing2(1123456700,11234567.0f)devem ser -2147483649L e 99.9999923706054688, respectivamente, mesmo que os valores aritmeticamente corretos sejam 2147483647L e 100.0, e mesmo que em algumas plataformas o código para gerar resultados numericamente incorretos seja mais lento que o código para gerar o correto os resultados (em algumas plataformas de 64 bits, forçar o comportamento de quebra automática após (x + 1) exigiriam uma instrução extra, e na plataforma 8x87, forçar o valor de 1123456700 a ser arredondado para floatexigir uma instrução extra em comparação com o simples carregamento diretamente a um registro de precisão estendida).

A quantidade de trabalho para as ferramentas de suporte é realmente semelhante, a diferença está em outro lugar. Depois que um programa C ++ for compilado para uma plataforma, você precisará compilá-lo novamente se quiser usá-lo em uma plataforma diferente. No entanto, quando um programa java é compilado, você pode movê-lo para qualquer outra plataforma com um ambiente de tempo de execução sem precisar recompilar.

Respondendo ao título "Portabilidade é um mito?", Em vez de "Qual é melhor em portabilidade, Java ou C ++", direi que a portabilidade parcial é possível, mas a portabilidade total é um mito.

Algo que eu insisto em escrever, e se aplica a essa pergunta, é que os desenvolvedores não estão mais trabalhando apenas com linguagens de programação, mas com estruturas de programação completas.

E essas estruturas incluem bibliotecas, bancos de dados, interfaces gráficas.

Qual linguagem de programação ou qual estrutura de programação é mais portátil?

Bem, depende, qual é o seu aplicativo. está tentando alcançar.

O problema é que você não escreve o JRE, você escreve o código Java que é executado em qualquer JRE. "Você" não escrever o código C ++ que pode exigir mudanças por você antes que ele irá compilar em outra plataforma.

Muitas pessoas esquecem ou não levam em conta a realidade do Java quando dizem que "é 100% portátil" ou frases como essa.

Praticamente todas as principais empresas de software / corporações tinham pelo menos uma implementação caseira de Java com um JRE associado no passado recente e algumas ainda o mantêm, Microsoft, IBM e Apple, por exemplo, tinham sua própria versão do Java refletindo seus próprias idéias e pensamentos sobre onde a indústria e essa linguagem devem ir.

Como é isso para "portátil"? Um JRE em qualquer lugar que você virar.

E isso sem considerar o que a Sun / Oracle estava fazendo.

Um exemplo de por que o código Java não está muito longe de C e C ++ em termos de portabilidade são as GUIs e os servidores gráficos, a Apple teve uma implementação não-padrão da estrutura da GUI para seu próprio JRE, como conseqüência, havia muitas dores de cabeça e trabalho duplo para quem quisesse criar / portar uma GUI usando Java para máquinas Apple e eles foram basicamente forçados a lidar com o Quartz (como é isso em termos de "alavancagem" e linguagens de alto nível?).

Às vezes, mesmo as palavras usadas mais comuns não refletem realmente o significado que as pessoas normalmente lhes dão, para mim o termo "portabilidade" no mundo Java é mais como "perspectiva" no senso comum; em termos comerciais e financeiros, há uma perspectiva melhor para você se você adotar o Java em vez de outras linguagens (pelo menos no momento em que o Java nasceu), porque você já tem muito trabalho feito de um lado (você obtém um JRE em qualquer coisa que pode ser considerado um "computador") e é provável que sua base de código seja portátil, pois você precisa de menos recursos para portar seu programa, é isso, se esse recurso é dinheiro, tempo ou mão de obra não importa, é menor limiar em comparação com outras tecnologias e é para isso que serve o Java, está diminuindo esse limiar.

É claro que isso é verdade se você aceitar as instalações do Java, o que significa uma máquina virtual com coleta de lixo, o que significa que ela consome mais recursos se comparada às linguagens nativas, se você realmente deseja extrair o máximo da CPU ou do farm de servidores I não pense que você pode adotar o Java, a menos que tenha poucos recursos ou a sua empresa seja muito pequena.

Ainda tenho que encontrar um único aplicativo Java não trivial que contenha apenas 1 versão para cada linha de código ou funcionalidade (também conhecida como nenhuma plataforma específica) e é 100% portátil entre os principais JREs.