Responda essa

Eu vou mover isto para “off-topic”. De qualquer maneira, me dê um tempo que respondo.

EDIT - aham, não deu tempo, moveram de “Notícias” para “Java Básico”.

hahaha…eu abri em off-topis…colocaram em noticias e agora foi pra java básico… “ow loko meu”

Pensei em colocar em “Desafios”, mas não tinha esta seção… rsrsrs…

Faltou vc dizer que armazena em milesegundos desde 1970 ou EPOCH.

Long = 64 bits = 18446744073709551616

Só os positivos = 9223372036854775808 (divide por 2 aproximadamente)

Um ano ~ 365 x 24 x 60 x 60 x 1000 ~ [telefone removido] ms

9223372036854775808 / [telefone removido] ~ 292471208 anos

1970 + 292471208 = 292,473,178

Por volta do ano 292 milhões vai dar pau…

boaaaaaaaa…eu não saberia fazer essa conta…então vou crer na sua palavra…

Sun Aug 17 04:12:55 GMT-03:[telefone removido]

System.out.println(new Date(Long.MAX_VALUE));

[]'s
Homero

Acho que a espécie humana vai estar extinta nessa data.

O Java diz que vai ter problemas a partir do ano 292.278.994 depois de Cristo, ou seja, daqui a 292 milhões de anos. Como os insetos apareceram só há 400 milhões de anos atrás, e os dinossauros há 230 milhões de anos atrás, então provavelmente não estaremos por aqui quando começar a dar problemas.

import java.util.Date;
class TesteDate {
    public static void main(String[] args) {
        Date dt = new Date (0x7FFFFFFFFFFFFFFFL);
        System.out.println (dt);
    }
}

Saída:

Sun Aug 17 04:12:55 BRT 292278994

Ou com sorte teremos uma API de data melhorzinha nessa epoca, caso continuemos por aqui =)

[]'s
Homero

caraca e muito tempo hein…

precisava de uma API mais preparada…eu não conheço nada q ultrapasse esse valor…mas alguns cálculos de astronomia fazem isso fácil…

Homero Damico:

Ou com sorte teremos uma API de data melhorzinha nessa epoca, caso continuemos por aqui =)

O Mister__M (Michael Nascimento Santos) está trabalhando para pôr uma API decente (a tal da Joda Time) já no Java 7. Espere e verá.

thingol:

Homero Damico:

Ou com sorte teremos uma API de data melhorzinha nessa epoca, caso continuemos por aqui =)

O Mister__M (Michael Nascimento Santos) está trabalhando para pôr uma API decente (a tal da Joda Time) já no Java 7. Espere e verá.

Show.

Só a 10 tipos de pessoas no mundo. Os que entendem computação e os que não entendem.

thingol:

Homero Damico:

Ou com sorte teremos uma API de data melhorzinha nessa epoca, caso continuemos por aqui =)

O Mister__M (Michael Nascimento Santos) está trabalhando para pôr uma API decente (a tal da Joda Time) já no Java 7. Espere e verá.

To acompanhando a JSR =)
Usei Joda tb, for fun, pra ter um preview.
Mas vai ser um javax.date ou algo assim.
Não vai substituir a api atual, só complementar.
Até trocarem isso definitivamente vai tempo, SE acontecer.

[]'s
Homero

saoj:

Só a 10 tipos de pessoas no mundo. Os que entendem computação e os que não entendem.

e os outros 8 tipos ?!?!?!?1

Giulliano:

saoj:

Só a 10 tipos de pessoas no mundo. Os que entendem computação e os que não entendem.

e os outros 8 tipos ?!?!?!?1

saoj 1 x 0 Giulliano

Giuliano, você não entendeu a piada, já que o número está em binário, não em decimal.

Veja esta camiseta.

Curiosidade interessante essa da data =)

Giulliano:

saoj:

Só a 10 tipos de pessoas no mundo. Os que entendem computação e os que não entendem.

e os outros 8 tipos ?!?!?!?1

Preste atenção na base do número…

10 em binário é igual a dois em decimal!!!

Homero Damico:

Giulliano:

saoj:

Só a 10 tipos de pessoas no mundo. Os que entendem computação e os que não entendem.

e os outros 8 tipos ?!?!?!?1

saoj 1 x 0 Giulliano

Eu também bolei na primeira vez que vi essa frase. Para entender números binários não tem muito mistério. Basta decorar o seguinte:

n bits = 2 ^ n possibilidades

1 0 1 0 1 0 1 = 2 ^ 6 + 2 ^ 4 + 2 ^ 2 + 2 ^ 0
6 5 4 3 2 1 0

Em Java:

byte = 8 bits
short = 16 bits
int = 32 bits
long = 64 bits
referencia de objeto = 32 bits (se não estou enganado)

Use a calculadora do windows e seja feliz!

Como a maioria dos CPUs são 32-bits, set e get de variáveis do tipo long podem em teoria dar problemas de race condition em Java. Alguém sabe mais detalhes sobre isso?

saoj:

Só a 10 tipos de pessoas no mundo. Os que entendem computação e os que não entendem.

Uma vez eu vi essa frase escrita em um banheiro, abaixo tinha algo escrito assim: “O que você quer dizer com isso? você é burro?” eu acho que ele era um dos 10 tipos que não entende binário…

André Fonseca:

saoj:

Só a 10 tipos de pessoas no mundo. Os que entendem computação e os que não entendem.

Uma vez eu vi essa frase escrita em um banheiro, abaixo tinha algo escrito assim: “O que você quer dizer com isso? você é burro?” eu acho que ele era um dos 10 tipos que não entende binário…

Homero Damico:

Giulliano:

saoj:

Só a 10 tipos de pessoas no mundo. Os que entendem computação e os que não entendem.

e os outros 8 tipos ?!?!?!?1

saoj 1 x 0 Giulliano

Ptz Giulliano não acredito que você caiu nessa velho. Você não é um nerd de verdade?

Engraçado perceber o que 6h por anos faz diferença…

Calculando como saoj desprezando os anos bisextos dá 194.184 anos a mais que o calculo correto com bissexto…

pô…essa piada é péssima hein…hauhauhauahuhaa…

mas valeu a intenção…

Então ela era 01 tipo que não entende binário, porque o outro entende.

Se a variável do tipo long estiver em um endereço que não é múltiplo de 8, o que não costuma ocorrer porque o JIT tenta deixá-la em um endereço múltiplo de 8, isso poderia ocorrer sim, mas o correto é usar java.util.concurrent.AtomicLong se você estiver realmente preocupado com isso. As CPUs modernas, mesmo trabalhando em modo de 32 bits, não costumam recuperar dados da memória em pedaços menores que 64 bits, mesmo que você não perceba isso ao nível da linguagem de máquina.

thingol:

Como a maioria dos CPUs são 32-bits, set e get de variáveis do tipo long podem em teoria dar problemas de race condition em Java. Alguém sabe mais detalhes sobre isso?

Se a variável do tipo long estiver em um endereço que não é múltiplo de 8, o que não costuma ocorrer porque o JIT tenta deixá-la em um endereço múltiplo de 8, isso poderia ocorrer sim, mas o correto é usar java.util.concurrent.AtomicLong se você estiver realmente preocupado com isso. As CPUs modernas, mesmo trabalhando em modo de 32 bits, não costumam recuperar dados da memória em pedaços menores que 64 bits, mesmo que você não perceba isso ao nível da linguagem de máquina.

A especificação do Tiger fala para vc usar volatile sempre que um thread altera e outro lê a variável, caso contrário cada um terá o seu próprio cache de variáveis e um não vai ver a mudança que o outro fez. Se não estou enganado esse cache acontece no registers da CPU, logo se vc tem apenas uma CPU esse problema NUNCA vai acontecer e vc não precisaria usar volatile. Isso porque sempre que entra um novo thread o contexto (cache) é substituído pelo novo contexto do thread que está entrando. Se vc tem duas CPUs e cada thread está rodando numa CPU então vc pode ter problemas sérios, uma vez que vc tem agora 2 caches distintos.

A questão do long é que independente do cache pode haver um context switch no meio de um get ou set, uma vez que é impossível ler 64-bits atomicamente num único tick do clock. Se isso acontece, a JVM garante ou não a integridade da variável? Nunca soube, acredito que sim, mas tb não sei como.

ddduran:

Homero Damico:

Giulliano:

saoj:

Só a 10 tipos de pessoas no mundo. Os que entendem computação e os que não entendem.

e os outros 8 tipos ?!?!?!?1

saoj 1 x 0 Giulliano

Ptz Giulliano não acredito que você caiu nessa velho. Você não é um nerd de verdade? :P

Poxa… tb não acredito… hehehe