Configurando Java de valor curto

114

Estou escrevendo um pequeno código em J2ME. Eu tenho uma aula com um método setTableId(Short tableId). Agora quando tento escrever setTableId(100)dá erro de tempo de compilação. Como posso definir o valor curto sem declarar outra variável curta?

Ao definir o Longvalor posso usar setLongValue(100L)e funciona. Então, o que Lsignifica aqui e qual é o caractere de Shortvalor?

obrigado

java literals primitive-types

— Mubashar
fonte

Lé apenas um sufixo usado para indicar um longliteral.

— missingfaktor

174

Em Java, literais inteiros são do tipo int por padrão. Para alguns outros tipos, você pode sufixo literal com uma letra maiúsculas e minúsculas, como L, D, Fpara especificar um longo, duplo ou float, respectivamente. Observe que é uma prática comum usar letras maiúsculas para melhor legibilidade.

A especificação da linguagem Java não fornece o mesmo açúcar sintático para tipos de byte ou curtos. Em vez disso, você pode declará-lo usando uma conversão explícita:

byte foo = (byte)0;
short bar = (short)0;

Em sua setLongValue(100L)chamada de método, você não precisa necessariamente incluir o Lsufixo porque, neste caso, o literal int é automaticamente ampliado para um longo. Isso é chamado de conversão primitiva de ampliação na Especificação da linguagem Java.

— Lauri
fonte

16

Existem sufixos para outros tipos também: d/ Dfaz a doublee f/ Ffaz um float!

— Joachim Sauer

6

Além disso: literais que cabem no tamanho não precisam ser moldados: seus dois exemplos funcionam sem o molde também.

— Joachim Sauer

Você está certo em ambos. Eu deveria ter sido mais claro que estou falando sobre literais inteiros aqui, não sobre literais de ponto flutuante.

— Lauri

4

@Joachim: Não é necessário elenco apenas para J5 +; J2ME infelizmente ainda está em J4 (um J4 seriamente reduzido).

— Lawrence Dol

2

@JoachimSauer, o que significa "caber no tamanho"? Estou perguntando porque eu tinha que lançar especificamente 0como (short)0obter em torno de um possible lossy conversion from int to shorterro, mesmo que 0 é um curta.

— ryvantage

34

Não existe um byte ou literal curto. Você precisa lançar em curto usando(short)100

— er4z0r
fonte

9

Geralmente, você pode apenas converter a variável para se tornar um short.

Você também pode ter problemas como esse que podem ser confusos. Isso ocorre porque o +operador os promove a umint

Lançar os elementos não vai ajudar:

Você precisa lançar a expressão:

— matt burns
fonte

1

Não se esqueça de que há uma razão para short + short = int. Se a soma de dois curtos for maior do que o valor curto máximo da máquina, lançá-lo em curto produzirá resultados inesperados ou lançará uma exceção, se suportado pela linguagem.

— DGoiko

2

Com essa lógica, adicionar dois ints resultaria em um longo;)

— matt queima

1

E eu procuro isso se minhas somas podem ultrapassar Integer.MAX_VALUE. Não estou defendendo a decisão de retornar int (que provavelmente está relacionado à forma como o HW realmente realiza as somas), estou apenas dizendo que as pessoas devem confirmar se o resultado realmente preenche um short antes de colocá-lo lá. Eu encontrei mais bugs limitando capacidade curta do que limitando intern também, provavelmente devido ao tamanho dos números envolvidos.

— Reservadores

1

Eu li meu comentário novamente e não deixei meu ponto claro. A primeira frase é confusa e eu não deveria ter dito isso e apenas deixei o resto, parece que há duas declarações relacionadas. A razão por trás de short + short ser int pode ser lida aqui: docs.oracle.com/javase/specs/ jvms / se8 / html /… , não há operações de soma abreviadamente na JVM. O int do Java é de 32 bits e, quando essas decisões foram feitas, a maioria dos computadores era de 32 bits, então int parecia a melhor ideia, eu acho.

— DGoiko

1

Observe também que, conforme explicado aqui stackoverflow.com/a/27123302/9465588 , a JVM realmente serverse pelo menos 32 bits de seu espaço de memória virtual por campo de classe, portanto, declarar campos curtos não economiza memória. Não sei se o Java mudou isso. Eu tendo a nunca usar valores curtos, a menos que haja uma restrição externa envolvida, como em um DAO

— DGoiko

8

Você pode usar setTableId((short)100). Acho que isso foi alterado no Java 5 para que literais numéricos atribuídos a byte ou curto e dentro do intervalo para o destino sejam automaticamente considerados como o tipo de destino. No entanto, os JVMs J2ME mais recentes são derivados do Java 4.

— Lawrence Dol
fonte

PS: Bem-vindo ao atolado na dor da idade média da codificação para J2ME. Mal posso esperar que os dispositivos portáteis alcancem até 2.000 desktops.

— Lawrence Dol

3

Não existe "J4" (e nenhum "J5". Por favor, não torne o esquema de versão / nomenclatura Java mais confuso do que já é.

— Joachim Sauer

2

@Joachim: Java 1, Java 2, Java 5, Java 6 e Java 7 são bem conhecidos e assim chamados; não é muito difícil extrapolar o que significa Java 3 e Java 4. "Jn" é simplesmente uma abreviatura do óbvio. A adoção da nomenclatura atual (e esperançosamente final) da Sun para todas as versões reduz a confusão.

— Lawrence Dol

2

@Joachim: De acordo com a última palavra da Sun sobre o assunto, o principal "1". do Java "1.x" deve ser tratado como se nunca tivesse existido ao se referir às versões em discussão, e está sendo mantido na versão emitida pelas JVMs apenas para compatibilidade. Assim, Java 2 é a versão que era anteriormente conhecida como 1.2, de onde veio o J2SE originalmente (você notará que ao mesmo tempo a Sun recomendou não usar J2xE, mas sim JavaEE, JavaSE e JavaME). Conclui-se que 1.3 é Java 3, 1.4 é Java 4, 1.5 é Java 5, 1.6 é Java 6 e 1.7 é Java 7. Sério, isso não é tão difícil de raciocinar.

— Lawrence Dol

2

O "1" só foi eliminado no Java 5 e posterior. Java 1.0-1.4 sempre são chamados por esse nome pela Sun. E isso é feito intencionalmente, porque a Sun usou "Java 2" para se referir a Java 1.2 até Java 1.5 / Java 5. É muito confuso, mas inventar novos nomes que a Sun nunca usou não torna isso mais fácil.

— Joachim Sauer