Java é totalmente Orientado a Objetos?

Sim, existem os tipos primitivos, que não são objetos.

é verdade sim

int por exemplo não é um objeto, é um tipo primitivo.

e consequentemente você não vai conseguir fazer 1.toString()

(todo objeto herda de Object, e Object possui um método toString() que devolve a representação desse objeto em forma de texto)

Boa tarde!

Técnicamente é verdade…

Java não é totalmente orientado a objetos devido aos primitivos (byte, short, char, int, long, float, double) não serem objetos e não terem métodos.

A partir do Java 5, é desencorajado o uso de primitivos. Devemos usar as classes Wrapers deles (Byte, Short, Character, Integer, Long, Float e Double).

Abraço,

Visite o Blog do Perereca: http://www.blogdoperereca.blogspot.com

De onde você tirou essa informação? Que eu saiba você ainda precisa muito dos tipos primitivos. Imagine uma coisa como esta aqui:

for (Integer i = 0; i.compareTo (Integer.valueOf (10)) < 0; ++i) {
}

Isso é muito estranho. Melhor usar isto aqui:

for (int i = 0; i < 10; ++i) {
}

thingol, eu sei que você está cansado de saber disso… mas acho que se esqueceu… existe um recurso interno no Java 5+ que chama AutoBoxing, que foi implementado justamente para desencorajar o uso de primitivos em Java. Você pode fazer simplesmente assim:

1. for (Integer i = 0; i < 10; ++i) {  
   2. }

e pronto.

Abraço,

Visite o Blog do Perereca: http://www.blogdoperereca.blogspot.com

class Autob {
    public static void main(String[] args) {
        for (Integer i = 0; i < 10; ++i) {
            System.out.println (i);
        }
    }
}

Realmente isso é meio sinistro - parece um pouco com C# … O código que o compilador gerou é equivalente a:

class Autob {
    public static void main(String[] args) {
        for (Integer i = Integer.valueOf (0); i.intValue() < 10; i = Integer.valueOf (i.intValue() + 1)) {
            System.out.println (i);
        }
    }
}

que realmente parece um pouco ineficiente.

Onde ta escrito que uma linguagem totalmente orientada a objetos nao pode ter tipos primitivos?

thingol:

class Autob { public static void main(String[] args) { for (Integer i = 0; i < 10; ++i) { System.out.println (i); } } }

Realmente isso é meio sinistro - parece um pouco com C# … O código que o compilador gerou é equivalente a:

class Autob {
    public static void main(String[] args) {
        for (Integer i = Integer.valueOf (0); i.intValue() < 10; i = Integer.valueOf (i.intValue() + 1)) {
            System.out.println (i);
        }
    }
}

que realmente parece um pouco ineficiente.

Baseado em quê você diz que este códifo é ineficiente?

Bom, o uso de tipos “wrappers” é otimizado pela JVM se você estiver trabalhando em modo “server” (parâmetro “-server” para invocar o java).
É que a JVM usa dois truques: transformar um “wrapper” em um objeto alocado no stack e não no heap em determinadas condições, e usar um tratamento especial para wrappers quando a JVM descobre que o objeto não pode assumir o valor “null”, muitas vezes evitando até sua criação. Nesse caso o wrapper é tratado como o tipo primitivo correspondente.

Então não é tão ineficiente assim; só acho um pouco desajeitado.

Experimenta rodar ele milhões de vezes para sentir o quanto ele demora comparado a usar somente tipos primitivos.

Nem de longe que usar tipos primitivos é desencorajado, a performance deles ainda é muito maior que usar objetos puros. Aliás esse é o motivo por que Java não OO puro.

public class PerformanceInteiros
{

   public static void main(String[] args)
   {
      long t1 = System.nanoTime();

      int j = 0;

      for (int i = 0; i < 10000000; i++)
      {
         j++;
      }

      long t2 = System.nanoTime();

      Integer b = 0;

      for (Integer i = 0; i < 10000000; i++)
      {
         b++;
      }

      System.out.println("Soma primitivos: " + (t2-t1) + " nanosegundos" );
      System.out.println("Soma objetos: " + (System.nanoTime() - t2)  + " nanosegundos" );
   }
}

Soma primitivos: 7294921 nanosegundos
Soma objetos: 361801570 nanosegundos

49 vezes mais lento que usar primitivos puros.

Java é O.O sim … mas já vi mto programadores programar da forma estruturallllll kkkkkkkkkkkkkkkk…

Pessoal, blz>

Bruno Laturner, você tem razão. Nos provou que os primitivos são mais eficientes, e claro que são. E contra fatos não há argumentos.

Então chegamos a conclusão que pra esse caso de loop é melhor usarmos primitivos... algo que não poderíamos no caso de uma Collection... valeu a discussão, colaboramos muito para o fórum, mesmo este assunto sendo tão polêmico. :-)

Agora que já nos acertamos, que tal se combinássemos de tomar uma cerveja qualquer dia, afinal, somos todos integrantes da comunidade Java e vamos parar de esquentar o clima por bobagens. :-)

E viva o GUJ e a comunidade Java!

Abraço,

Visite o Blog do Perereca: http://www.blogdoperereca.blogspot.com

Bom dia,

Java 5 Tiger introduz Autoboxing para convertir os tipos básicos em  referências automaticamente quando necessário.

No Tigre, a reconversão explícita se tornar obsoleta.

O objectivo, éra simplificar o desenvolvimento objeto, mas não remover os typos primitivos da programação.

Neste caso por exemplo :

List list = new ArrayList();

int myInt = 100;

list.add(myInt);  //  myInt   é  “wrappado” em  Integer  ,   no jdk1.3  erro compilação  java.lang.ClassCastException

No caso do for(…) não faz sentido utilizar o wrapper Integer …

Não sei se java é totalmente Orientado a Objetos . Mas eu sei que a muitas classes. Mas não sei se uma classe é um objeto ???

Abraços !

Na verdade não existem conceitos padrões que definem se uma linguagem é ou não orientada a objetos, o simples fato de usar somente objetos não prova que a linguagem seja totalmente OO, como o caso do Ruby, e o Java segue a msma definição, como não podia ser diferente… se fosse comparar o Java com outras linguagens OO, o primeiro ainda seria menos OO que o restando, pois ainda permite programação estruturada… como foi citado por JxtaNode autoboxing foi apenas para facilitar a conversão de tipos primitivos para tipos wrappers…

Experimenta rodar ele milhões de vezes para sentir o quanto ele demora comparado a usar somente tipos primitivos.

Nem de longe que usar tipos primitivos é desencorajado, a performance deles ainda é muito maior que usar objetos puros. Aliás esse é o motivo por que Java não OO puro.

Quando foi a ultima vez que voce precisou rodar um codigo milhoes de vezes?

Agora um for de 1 a 10 é ineficiente porque usa objetos ao inves de tipo primitivos? Bom, entao fica o aviso: CRIANÇAS, NÃO FAÇAM ISSO EM CASA!

Dependendo do tipo de aplicação utilizar um for muitas vezes é comum. Se você for considerar uns algoritmos de alta complexidade (com estruturas de repetição dentro de outras) isso não é tão absurdo.

Mas mesmo em outras aplicações, particularmente, eu acho estranho utilizar um Wrapper pra um primitivo dentro de um for. Não melhora a legibilidade, não melhora o desempenho e em grande parte das vezes vc não precisa de nada desse wrapper no contexto do teu for.

Abraço!

Leia este post do Bracha (um dos autores da especificação da linguagem Java):

Acho que ele encerra o assunto.

O legal de algumas linguagens como Ruby por exemplo é que se você digitar 1. … (então temos métodos para o 1) pois ele é um objeto, mas tirando os tipos primitivos no java, a linguagem é sim OO e preciamos pensar OO se quisermos resultados nela.

1.compareTo(1)

Seria isso??? E qual o resultado (se existir esse método, claro)?? Que troço doido…rrsrssrr

T+

Não precisa mencionar o Ruby. O C# já é assim:

using System;

class Teste {
    public static void Main (string[] args) {
        Console.WriteLine (1.ToString()); // 1 é uma constante do tipo int, ou uma struct do tipo System.Int32
    }
}

mochuara:

Quando foi a ultima vez que voce precisou rodar um codigo milhoes de vezes?

Agora um for de 1 a 10 é ineficiente porque usa objetos ao inves de tipo primitivos? Bom, entao fica o aviso: CRIANÇAS, NÃO FAÇAM ISSO EM CASA!

Tem razão, não há um ganho tão grande na realidade assim ao passar de objetos para primitivos. Ganhos existem na arquitetura, na escolha de algoritmos certos pra cada caso, fazendo a coisa certa.

Um bom uso pra isso são em sistemas com recursos restritos, como nos sistemas embarcados que tem pouco processamento e memória, ou mesmo em serviços de computação distribuída que tenham cotas, Google AppEngine é um.

No tópico do AppEngine pra Java o pcalçado citou que uma aplicação dele numa linguagem de JVM (Clojure?) estourou o tempo de CPU do mês inteiro em poucas horas.