Coisas que odeio em Java

Olá,

Acho que uma das coisas que mais enche a paciencia é mexer com data (sem user JODA).

[]´s

ViniGodoy:

Nem tudo é perfeito, o Java infelizmente não foge a essa regra. Segue abaixo a minha lista de coisas que não gosto na linguagem. Você tem também suas “mágoas”? Dê sua opinião!

1. O comando wait(0) espera para sempre, ao invés de não esperar. Isso torna códigos que façam wait baseados em algum cálculo um inferno, já que sempre temos que testar se o resultado é zero;
   

Concordo, todos SOs definem que esperar por zero retorna imediatamente, ou faz pooling no caso de aquisição de recursos.

Ainda bem, caso contrario seria uma primitiva inutil. Todos SOs definem que toda espera está sujeita a cancelamento, isso é um mecanismo muito importante para construir sistemas confiaveis. Mas que é um saco, isto é.

Assim tipos escalares definidos pelo usuário.

Java não tem suporte a algo como o curses, logo qualquer coisa envolvendo console é um parto - pior que limpar é descobrir a dimensão.

Hmm, pelo contrário, em todos sistemas unix, esse é o comportamento se você usar recv() ou read() em um socket. http://www.opengroup.org/onlinepubs/007908799/xns/recv.html. Com windows é a mesma coisa, ou seja, retornar a quantidade lida não só é o comportamento normal, como também a forma correta de operar.

Java não deveria ter switch, deveria ter pattern matching.

Ainda bem, imagine quando se precisar fechar um stream sem escrever o conteúdo do buffer dele?

ViniGodoy:

8. Existem coisas que simplesmente deveriam estar no Swing e não estão. Por exemplo, setLength() no JTextField, a classe JTreeTable, etc. Ok, o Swing é bem feito e isso é implementável, mas coisas tão úteis assim deveriam vir na biblioteca padrão. A utilidade dessas coisas é comprovada até por artigos da própria Sun, que ensinam a implementar tais funcionalidades;

9. A API está começando a ficar “gorda”, já que em nome da compatibilidade classes muito antigas não são eliminadas. Infelizmente, não creio que haja uma solução para esse problema, a não ser talvez criar duas distribuições java (uma com as classes do passado, outra sem, para ser usada em projetos novos).

Quanto ao Swing, não posso comentar, não uso. Quanto a remover todo junk, bom, isso seria perfeitamente possivel se os arquivos .class carregassem informação de dependencia junto.

Para esperar indefinidamente, o valor deveria ser -1 em vez de 0. Realmente foi mal escolhido.

Acho que foi uma decisão de implementação porque eles não conseguiram um "wait" que funcionasse direito em todos os sistemas operacionais suportados.

É por isso que o C# tem tipos signed e unsigned. Uma coisa que me enche o saco é o tipo "byte" ser signed e o tipo "char" ser unsigned, em Java - ambos deveriam ser unsigned. O operador "&gt&gt&gt" é uma forma patética de remendar essa deficiência. Até em Modula-3 (uma linguagem criada pelo Niklaus Wirth, criador do Pascal, AKA Delphi) existe o tipo "CARDINAL" que é o nosso velho e conhecido unsigned.

Isso é herança acadêmica - veja a descrição da classe java.util.Date; ela não tem as coisas mais elementares que são necessárias com datas.

Isso, como foi dito acima, é comum para todas as linguagens que têm suporte a sockets.

O C# fez isso, mesmo sacrificando um pouco a compatibilidade (ao nível de "bugs"?) com o C/C++.
Ainda acho que a atribuição deveria ser ":=" e a comparação "=", tal como no Pascal (mas sem repetir os erros dele, como a precedência de operadores que é esquisita).

Hum…

De fato o Swing é um pouco esquizofrênico - muitas coisas úteis não existem, ou não funcionam direito.

9. A API está começando a ficar "gorda", já que em nome da compatibilidade classes muito antigas não são eliminadas. Infelizmente, não creio que haja uma solução para esse problema, a não ser talvez criar duas distribuições java (uma com as classes do passado, outra sem, para ser usada em projetos novos).

ViniGodoy:

9. A API está começando a ficar “gorda”, já que em nome da compatibilidade classes muito antigas não são eliminadas. Infelizmente, não creio que haja uma solução para esse problema, a não ser talvez criar duas distribuições java (uma com as classes do passado, outra sem, para ser usada em projetos novos).

Acho que uma possível solução para isso seria manter a compatibilidade com 2 ou no máximo 3 versões anteriores, passando disse seria removido! Mas o impacto que isso traria não sei dizer!

ASOBrasil

Tem muito software aqui feito em Java 1.3, se por exemplo ficássemos atrelados a compatibilidade de 2 ou 3 versões, apartir do Java6, teríamos que migrar toneladas de código.

A proposta de uma versão que continue compatível com as mais antigas e uma compatível com o somente a versão atual seria legal.

Até!

Concordo plenamente!!

Uma coisa que existe em Pascal, Ada e mais algumas linguagens é o tipo “range”. Por exemplo, você pode ter algo como:

type Card : 1..52;

e isso já faz um “bounds checking” em tempo de compilação e execução. Ele é complementar aos “enums”.
Isso poderia existir em Java, até para definir arrays de forma mais decente. Acho horrível essa herança do C++. Por que é que não posso ter algo como:

type Card = 1..52;
boolean[Card] naipe  = new boolean [Card];

e os elementos vão de naipe[1] a naipe[52], sem desperdiçar elementos (o offset é inserido pelo compilador, em vez de sê-lo pelo programador. )

Thingol,

Concordo que a API do Windows é obesa… mas isso não tira o mérito do que eu falei, pois a API do Java está começando a engordar.

Se eles não fizerem uma limpa nunca, cedo ou tarde o java também ficará cheio de lixo.

ViniGodoy:

Nem tudo é perfeito, o Java infelizmente não foge a essa regra. Segue abaixo a minha lista de coisas que não gosto na linguagem. Você tem também suas “mágoas”? Dê sua opinião!

1. O comando wait(0) espera para sempre, ao invés de não esperar. Isso torna códigos que façam wait baseados em algum cálculo um inferno, já que sempre temos que testar se o resultado é zero;

2. O wait está sujeito a spurious wakeups;

Porque raios vc faz um wait baseado num calculo ??

use char. char é unsigned

limpar o console !? vejo que vc faz muits programas de console…
nesse caso melhor usar swing e mandar escreve num component e depois apagá-lo. Afinal qual é a diferença entre o console um textarea ?

para saber onde roda File startupFolder = new File("."); em standalone
application.getRalPath("/"); em web

é que podem não existir n bytes para ler…

Vc não quer fall through ? use if/else if
Depois de remover o break, removam também os genérics … afinal podemos codificar tão bem ou melhor sem isso.

Aqui eu concordo. Acontece que JTreeTable é um caso particular que mostra o poder do Swing. Esse acoplamento não é possível em nenhum outra tecnologia

Ela está ficando gorda porque os programadores não usam as classes que deveriam, não mudam o código quando algo fica deprecated. E é por causa deles que API é gorda.

Difícil pegar o diretório corrente da aplicação?? Apenas use assim:

String sDir = System.getProperty(“user.dir”);

Não testei mais pelo que me lembro das variáveis properties do sistema é assim.

Não vejo nada de errado com o break

Concordo no sentido de que o core do Java está ficando inutilmente gordo, mas não sei se seria a solução criar distribuições diferentes, talvez sim, ou não.

Vero! Mas talvez com o SwingFramework que será lançado na versão 7, fique o swing algo mais prático.

Uma coisa que acho chata de se trabalhar no Java como rodrigo gomes mesmo disse, é trabalhar com Java, para que há tantas classes para se trabalhar com datas? Acho ruim de fato. Existem até frameworks 0.o disso para java.

String sDir = System.getProperty(“user.dir”);

Isso não retorna o diretório da aplicação. Isso retorna o diretório corrente em que o usuário se encontra.

O que quero dizer é, em C++ é muito fácil pegar o diretório onde o .exe está gravado. Independente de qual caminho você esteja rodando o código, ou de qual seja o caminho da pasta “my docs” de seu usuário. Ok, ok, a desculpa oficial do java é: “Mas o .jar pode estar em qualquer lugar, até em um BD, ou num applet…” Mas a falta desse recurso torna aplicações com plugins gravados no diretório da aplicação (tais como o Eclipse) só resolvíveis com algum tipo de xunxo (será que é para isso que o Eclipse tem um .exe?).

Outra coisa, o problema não está no break do switch, mas no fato do switch fazer fall through. Ou seja, se você esquecer o break, ele cairá na próxima condição do switch, como se a avaliação da condição fosse verdadeira.

E isso certamente é comprovadamente propenso a erros.

No caso dos breaks eu também concordo, porém ja estou acostumado a acrescentar em cada case: um break;

case 1:
// cmds
break;

case 2:
// cmds
break;

Fazer o que né?

Rapaz, o caso do break eu tenho que discordar, depois que eu comecei a usar switches com enumns já tive vários casos de fallthrough.

O que ia resolver mesmo o problema é um switch com pattern matching, esse sim não precisaria de fallthrought.

Olá

Além da falta de inteiros de 64 bits, o que sempre senti falta no Java foi facilidade de acessar dispositivo periféricos. Não fosse por isto, Java teria sido realmente VB killer.

Pensando a posteriori, teria sido muito melhor que a Sun tivesse investido em facilidade de uso de periféricos TODO o tempo que gastou com J2EE (menos servlets e JMS).

[]s
Luca

Luca:

Olá

Além da falta de inteiros de 64 bits, o que sempre senti falta no Java foi facilidade de acessar dispositivo periféricos. Não fosse por isto, Java teria sido realmente VB killer.

O que vc está chamando de periférico ali ?
Com qual periférico vc não consegue comunicar usando java ?

Luca:

Olá

Além da falta de inteiros de 64 bits, o que sempre senti falta no Java foi facilidade de acessar dispositivo periféricos. Não fosse por isto, Java teria sido realmente VB killer.

Pensando a posteriori, teria sido muito melhor que a Sun tivesse investido em facilidade de uso de periféricos TODO o tempo que gastou com J2EE (menos servlets e JMS).

[]s
Luca

elomarns:

Luca:

Olá

Além da falta de inteiros de 64 bits, o que sempre senti falta no Java foi facilidade de acessar dispositivo periféricos. Não fosse por isto, Java teria sido realmente VB killer.

Pensando a posteriori, teria sido muito melhor que a Sun tivesse investido em facilidade de uso de periféricos TODO o tempo que gastou com J2EE (menos servlets e JMS).

[]s
Luca

Talvez eu esteja falando besteira, bem provável aliás, mas se eu não me engano, o long, que é um tipo inteiro, tem 64 bits.

Exactamente.
byte = 8 bits
short = 16 bits
int = 32 bits
long = 64 bits

Eu também concordo com a criação de uma máquina virtual mais limpa, sem nenhuma classe/método depreciado (nem é só pela performance, mas também pela limpeza e padronização).

A questão dos periféricos é interessante. Realmente, joysticks e alguns tipos de hardware não tem suporte em java puro. Até mesmo o uso pino-a-pino das portas serial e paralela não tem uma solução satisfatória em java puro.

Sempre tem que recair no JNI, ou para a biblioteca de alguém que usou o JNI para você. E isso sempre gera o stress de ter alguma dll anexada, ou monstrinhos para gravar no java/bin…

Também já sofri com isso.

Simples, você pode estar fazendo um wait baseado num timeout máximo. E gostaria que esse wait aguardasse somente até o restante do tempo.

Esse timeout tem de ser calculado, até porque o wait está sujeito a spurious wakeups como eu mesmo ressaltei.

Certo, char é unsigned. Mas é uma resposta simplista. O C te enviará inteiros e longs. O char também não é um tipo numérico, o que dificulta um pouco a impressão dele, por exemplo. Tanto que essa não é sugestão dos livros de rede. Eles sugerem ler num tipo maior, por exemplo, se o C enviar um int, ler o dado num long.

Entretanto, tanto a sua solução, quanto a dos livros, são workarounds. Você certamente terá que fazer código para driblar o problema do que seria necessário se os tipos simplesmente estivessem ali.
E o que não gosto é ter de recorrer a um workaround.

Não, não faço muitas aplicações no console. Esse foi apenas um exemplo. E essa é uma pergunta clássica de alunos que estão aprendendo java… Agora, mesmo o unix tem diversas aplicações que são estritamente controladas por console e não vejo porque usar o swing quando estiver fazendo uma aplicação que será um deamon ou coisa do gênero.

A sua solução também não retorna o local onde a aplicação está gravada, e sim o diretório onde o usuário iniciou a aplicação. São coisas diferentes. Tente implementar uma aplicação como o eclipse, que possui plugins em uma pasta específica, cada uma com seu arquivo manifest, e você saberá do que estou falando. Você simplesmente não tem como descobrir onde a pasta dos plugins está para ler os manifests e instancia-los com reflexão. A não ser recorrendo a um executável externo ou a perguntar para o usuário durante a primeira inicialização. Novamente, workarounds.

Nesse caso, eu gostaria de espera-los. É muito comum numa aplicação TCP existe um protocolo bem definido e controlado entre o cliente e o servidor. Você sabe exatamente quantos bytes virão, ou terá um campo length() em algum canto do procolo que te informará isso.

Quedas abruptas da conexão são controladas pelo TCP e deveriam ser notificadas através de exceção. Embora talvez não seja padrão no TCP (como o louds disse), não deixaria de ser um método interessante.

O que raios os generics tem a ver com o fall through? Fall through é propenso a erros e simplesmente não deveria estar lá. O próprio Joshua Bloch admite isso no Effective Java. Os generics, pelo contrário, não só evitam erros de casting como tornam a programação mais agradável. Não existe uma vantagem concreta em ter fall though em switchs, embora existam diversas desvantagens.

Acho que o caminho dessa discussão não deve ser tentar ridicularizar o argumento, como você fez ao falar dos Generics. Além de uma falta de respeito, não ajuda nada a defender o seu ponto de vista…

Sim, concordo. O swing é poderoso. Mas já deu uma olhada, por exemplo, na descrição do requisito que gerou o sorting no java 6? Dizia exatamente:
“Yes, I know it can be done on top of Swing (and that only
shows that Swing has been very well designed), but it is such
a common feature that IMO it should be a part of Swing.”
Confira você mesmo!
http://forum.java.sun.com/thread.jspa?threadID=788227&messageID=4478867

É com essa opinião que eu concordo. O swing é o máximo. Certamente é o mais flexível framework que eu já vi… mas certas coisas já deveriam estar lá, e não estão. Você pode dar uma espiadela na busca do GUJ e ver pessoas procurando por TreeTables, DropDownButtons e LookUpComboBoxes.

sergiotaborda:

Ela está ficando gorda porque os programadores não usam as classes que deveriam, não mudam o código quando algo fica deprecated. E é por causa deles que API é gorda.

Essa foi uma frase injusta. Existem programadores descuidados, mas a razão não é essa. É porque existem sistemas legados e as empresas não podem ficar simplesmente investindo em modifica-los, especialmente quando esses funcionam bem. Pense, se você fosse dono de uma empresa (não a Sun, logicamente), tivesse um grande sistema feito a alguns anos atrás em java 1.3 por excelentes programadores, você investiria seu dinheiro para modificar um sistema que funciona bem, correria o risco de inserir erros nesse sistema, só por que a versão do Java mudou? A resposta é não. Quando o assunto é dinheiro, somos muito conservadores.

Se a API não ficar gorda a tendência é que as novas versões de java não sejam adotadas, não que alguém vá pagar pela modificação.

Veja, sem o código deprecated você não poderia migrar uma aplicação aos poucos.

A idéia desse tópico era deixar o “xiitismo” de lado e reconhecer que a linguagem que gostamos muito (sim, estou no GUJ pq adoro java) também tem seus problemas.

Todo o codigo deprecated poderia ser extraído pra um jar separado, ai quem precisa adiciona isso ao classhpath, pronto.

Além de tudo, poderia diminuir o tamanho padrão do runtime, o que facilita a adoção do plugin java nos browsers ou a distribuição do runtime junto com uma aplicação standalone.

Gostaria de um exemplo da necessidade disso. Está-me a parecer uma coisa demasiado especifica ( e que provavelmente pode ter outro tipo de implemenação) contudo, vc pode criar seu proprio método wait e usuá-lo dentro do método vc coloca essas logicas que vc não gosta.

mas é claro que são. Vc está tentando usar C++ com java , o que vc esperava ? A questão é que a falta de unsinged no java não afecta o java, por isso não é um problema no java. O problema é que C usa unsigned, o problema é do C. Quando vc vai tentar misturar os dois , como o C tem problemas, eles aparecem na integração. Agora , char é unsigned e é um numero sim. Faça ‘a’ + 1 e verá que o o java faz a conta.

Se não gosta de workarrounds não use C com java.

Caro, deamons não têm interface e não escrevem para o console, escrevem para um arquivo de log. portanto, esse não é um exemplo da necessidade de um comando para limpar a tela…
Mas , mesmo que fosse, mais um vez seria o exeplo de como não fazer um demon e por isso, vc cai em problemas, que se vc fizer direito não existem.

Sendo que o usuário so pode lança a aplicação de onde ela existe , dá no mesmo.

Eu já fiz isso, e funciona. Não é um workarround.

A API já faz isso por vc. Se o array não tem mais bytes é pq não chegaram mais.

Ambos existem para simplificar a vida do programador.
o falal througth é necessário pq minimiza a escrita de código e aumenta a rapidez. Se vc acha que é inutil é pq vc nunca usou. Se vc acha perigoso … bem … threads tb é perigoso e não vejo ninguem se quixar que java tem threads e não deveria ter pq é perigoso… se vc programa bem, fall throught nunca é um problema. Se vc programa mal, ai sim, mas ai vc aprender a programar melhor. Não é um problema da linguagem.

Razão pela qual a SUN as protege deixando a API gorda.
Se vc gosta desse tipo de protecção, não tem como se queixar que a API é gorda (aliás vc quer incluir JTreTable a fins , o que a deixaria ainda mais gorda)
Se vc não gosta desse tipo de protecção , como eu, gostaria de ver o que é deprecated simplesmente desaparecer.
Se as empresesas não podem usar a versão com os deprecated retirados, não mudem de jvm

E não é xitismo, é que as coisas que foram ditas que sao odiáveis em java, ou não são odiáveis o unão são problemas do java.

bom como iniciante, o que nao gostei logo de cara foi os tipos primitivos alguns ter sofrido alteracao ao de costume de outras linguaguens. =, ==, :=.
e também um ponto que vejo… eh os pre-requisitos de hardware… a maquina para rodar uma aplicacao java… que venha memoria!! consome uma memoria incrivel…
…

Bom, quem me dera poder sempre escolher com que servidor eu iria me conectar. Não fui eu quem programou o servidor. No nosso caso, não teria nem cabimento alterar a linguagem do cliente, nem reprogramar o servidor.

Acho que você não pegou o espírito da coisa. Isso era um exemplo. E não foi o único que dei. Veja como controlar o tamanho do texto de um textfield! Você tem que recorrer a interface document, escrever um monte de código, quando na maioria das aplicações ele simplesmente tem um setLength().

O usuário pode, mas nem sempre o faz. E usando o new File(".") fica a seu cargo explicar para ele porque quando ele mudou o atalho (ou a aplicação de lugar) tudo parou de funcionar. Perguntar para o usuário é um workaround. Algo que você está fazendo só pq não tem um meio automático…

E como você fez para achar o caminho dos plugins? Funciona sempre, mesmo que o usuário troque o diretório da aplicação? Se funcionar, por favor, me passe o código, gostaria muito de ver isso rodando sem workarounds.

Por favor, não seja contraditório. Ou a função retorna antes dos n, ou ela espera para você que eles cheguem… as duas coisas ao mesmo tempo, garanto que ela não faz.

Nesse caso, talvez fosse melhor voltamos com os ponteiros e as instruções direto em assembly (como o comando asm, do C), não acha? Muita coisa foi retirada do Java por ser propensa a erros. Como dizia num artigo que li sobre porque Java é melhor que C, “talvez não para você, que é um programador dedicado e cuidadoso, mas será propenso a erros para seus colegas descuidados e preguiçosos.”

Performance? Pelo amor de deus, coisas como essa nunca serão um gargalo de performance.

Facilitar para o programador? Acho questionável. É propenso a erros e é muito fácil você passar batido por um switch que não tem break quando está analisando um código com fall through. Usar fall through é considerado uma prática tão ruim que o eclipse tem até um warning para isso.

Eu gostaria de ter o suporte ao código antigo, mas em novos projetos, não ter toda a gordura. Não migrar de JVM está fora de cogitação. Afinal, existem benefícios de performance e segurança em fazer a migração.

E também gostaria da possibilidade de migrar meu código aos poucos, como é possivel na versão “com gordura”.

Quanto aos componentes novos, acho que colocar mais recursos na API não é engorda-la. O que engorda é deixar coisas lá que não devem ser usadas, nunca.

Mas foi vc que escolheu java … se sabia que o servidor era C pq não usou C tb ?
Agora vc vai responder que prefere java por uma serie de razões… bom, então isso so leva a concluir que C é mais odiável que java. E isso so reforça a minha afirmação que o java não precisa ter unsigned. aliás unsigned é uma aberração da natureza. o C só tem isso pq ele gosta de dar liberdade total para o programador fazer as cagadas que quiser.
Quando vc programava em C ou C++ vc ouvioa falar em desing patterns ?
Isso so significa que C nunca foi preocupado com fazer a coisa certa, apenas com fazer a coisa funcionar.

O exemplo do textfield é igualmente inutil. Não é suposto um textfield ter limite. MAS bolas java é OO se vc quer ter um setLength, crie um! Isso seria um probema se não fosse possivel solucioná-lo facilmente.
Mas esse problema advem de uma cultura no brasil de super protecionismo. Em java isso não é mais ncessário. Existe uma coisa chamada validação. Se o cara escreveu mais do que devia o problema é dele. simplesmete não aceite. (isso é o que vc faz em web) Agora, se vc gosta de ser user friendly, então tudo bem, seja, faça como eu e adicione essas funcionalidades por conta. Afinal com OO vc so tem que fazer isso uma vez. ( e na web use javascript, mas lembre-se que o javascript pode ser desabiliado)

Ora como, da mesma forma que o eclipse. Existe uma estrutura de pastas
os plugins estão numa delas. com file(".") obtém a raiz e a partir dai é facil.

Acho. Quem não gosta de switch deve usar C ou assembly mesmo.
Eu programava em VB e tinha uma coisa chamada select case. Era muito util e não tinha fall. Quando aprendi java achei um saco o switch. Achei que nunca o iria usar. Afinal so pode usar com costantes etc… mas depois que usei as primeira vezes vi que faz todo o sentido e era o select case que estava errado. Se a SUN dicidir adicionar um sintax sugar para switch com string tudo bem , o groovy tem isso. Mas retirar o switch é um tiro no pé.
Mas como eu disse antes, se não gosta de switch , use if / else if que não tem como errar.
Eu tb não gostava, agora acho uma aberração ouvir vc dizer que não gosta … como os tempos mundam …

Comparar um campo de texto em um formulário a uma aplicação console mostra que alguém precisa ser apresentado ao |. Uma janela gráfica não substitui um pipeline.

Olá,

Eu queria saber como o cara instala uma aplicacao grafica substituindo um console num servidor sem ambiente grafico instalado.

]['s

Bom…

System.out.println(getClass().getClassLoader().getResource("."));

E porque nao usar?

]['s

fabgp2001:

Olá,

Eu queria saber como o cara instala uma aplicacao grafica substituindo um console num servidor sem ambiente grafico instalado.

]['s

Nesse caso limpar a tela tb não será muito imporante , será ?

como assim limpar o console?? quem limpa o console é um comando do S.O…
Pra q vc quer pegar o diretório corrente da aplicação?

não vejo problema nenhum com break e switch

já ouviu falar em MaskFormattter?
o q seria uma JTreeTable??

por q?

DropDownButton não seria um combobox?

Quanto ao LookUpComoboBox…acho q quem pede isso ainda não conhece java direito…

Em primeiro lugar, o servidor C que comunicamos não é o único servidor que existe. E como eu também falei, a linguagem do cliente não estava sob discussão.

Não programo sozinho e sim numa companhia com anos de história e dezenas de sistemas, muitos deles implementados em hardware, usando C. E a interoperabilidade com esses sistemas também é necessária.

O lado do cliente, entretanto, deve ser multi-plataforma. Temos estações Windows e Linux executando os sistemas, portanto, como eu já havia afirmado, nunca foi pensado usar algo diferente de Java. Os problemas que tivemos fazendo uma aplicação “portável” em C++ eram muito maiores do que com o Java. A linguagem resolveu muitos dos nossos problemas e é preferível recorrer aos workarounds do que programar em C. Entretanto, isso não faz eu gostar do fato de Java não ter unsigned, especialmente quando trabalhando com aplicações desse tipo.

Mas até certo ponto concordo com você. Se olhar da perspectiva do Java e do futuro, é melhor mesmo que os unsigned fiquem de fora. Esse é uma coisa que odeio, mas aceito. Por isso que eu ressaltei que a raiva só vem “quando estou interagindo com aplicações C/C++”.

Sim, eu gosto muito de ser User Friendly. Aliás, o jeito “web” de se fazer não é o melhor, tanto que cada vez mais as interfaces web aproximam-se do desktop. É uma tendência indiscutível.

Não sei quanto a você, mas meu usuário é o meu cliente, o cara que usa o meu sistema, que precisa dele e paga para que ele funcione. Quanto mais amigável meu sistema for, melhor para mim, pior para o concorrente.

Amigabilidade é um dos requisitos importantes de um sistema, como outro qualquer.

Como eu disse, o swing é flexível, é OO, é tudo de bom. Mas coisas óbvias como essa já deviam estar lá. E é lógico que na empresa temos classes com funcionalidades assim, que já foram extendidas ou tem um helper associado.

Agora, isso não é desculpa. Definir o tamanho do texto é algo tão óbvio, tão usual que aposto que pelo menos 90% dos usuários tem classes extendidas dessa forma. Outras APIs que o digam: os componentes similares em praticamente qualquer outra linguagem tem esse feature. Como você diz que “não é suposto” um JTextField não ter algo assim? O troço é tão comum que tem um tutorial no GUJ só para responder a pergunta de como se implementa algo assim!

Ok, embora não seja a mesma coisa, embora não funcione em todos os casos como o C++ funcionaria… você ainda insiste em dizer que essa é a solução. Tudo bem, funciona para você, não vou mais discutir esse assunto.

Eu não gosto de switch e também não recorro a ifs tão frequentemente. Depois de patterns como State e Strategy eles quase não são necessários. Aliás, não é uma das refatorações do catálogo do Fowler?
Eu não falei em retirar o switch. Falei em retirar o break e o fall through do switch. Também não falei em syntax suggar, nem em usar ele com Strings, isso foi por sua própria conta.

Pois é, hoje no java você é obrigado a recorrer a um Runtime.exec (ou a um ProcessBuilder) e a um comando do SO se quiser limpar a tela do console. Mas o comando em si não é java puro, não é multi-plataforma e, em suma, seria mais um workaround.

E mais difícil que isso, como ressaltou o louds, é se você quiser descobrir quantas linhas tem o console.

Outras linguagens, como C++, Pascal, etc. tem um comando que limpa a tela. Um comando da linguagem, que vai ser transformado num comando do SO em que a linguagem foi compilada.

O java também podia ter um comando da API e que funcionasse em qualquer plataforma. A VM interpretaria esse comando e limparia o console onde quer que estivesse rodando.

Mas esse é um dos exemplos, obter o diretório onde a aplicação está (quando isso é possível) é outro.

Estou compilando minha própria listinha de coisas extremamente difíceis de se fazer em Java que são triviais em outras linguagens.

Já ouvi falar no MaskFormatter. Mas já usou para valer? É um componente um tanto esquisitinho. Os usuários geralmente não gostam dele, exceto para digitação de campos com máscaras mais complexas como telefones ou CEP…

Você pode dar uma olhada no TreeTable nesta série de artigos:
http://java.sun.com/products/jfc/tsc/articles/treetable1/

Lich King:

tingol:

Ainda acho que a atribuição deveria ser “:=” e a comparação “=”, tal como no Pascal

por q?

Eu também gostaria disso, embora isso já não me incomode tanto assim. Talvez a razão do Thingol seja diferente, mas minha é essa aqui:
Quem está iniciando conhece o operador de = como igualdade e não há na matemática nada como a atribuição.

Então, você pode explicar que := é atribuição e passar a usar = com igualdade. Sem confusão e sem problemas.

Agora, quando você fala que = é atribuição e == é igualdade… vira a mexe vai ter neguinho esquecendo e fazendo if (x = 2)…

Claro é só uma questão de hábito. Mas facilitar para quem está começando não é uma má idéia.

É muito similar a um combo, mas não é um combo. É como o botão seletor de cores do Word, ou o botão de nova mensagem da barra de ferramentas do Outlook. No lugar do valor, existe um botão, que pode ser pressionado. Ok, dá para fazer com Swing, trabalhando renderers, models, e afins. Mas seria uma coisa amplamente usada se simplesmente já estivesse lá.

A combobox que eu me referia é aquela que, embora o usuário escolha um valor, a combo mostra uma tabela, contendo uma lista de valores. Esse é um componente muito prático. Não sei pq vc diz que é para quem não conhece java direito. Novamente volto a repetir, tudo é possível no Swing, mas componentes úteis e comuns em ambientes gráficos como esse já deviam estar lá.

Outro que eu poderia citar é uma combo que desenha um calendário para que o usuário escolha uma data. Existe até para download, mas é algo que qualquer aplicação visual possui hoje em dia, devia ser Swing puro.

Veja o caso do TableSorter, por exemplo. Demorou até o Java 6 para colocarem esse recurso como uma coisa padrão do Swing. Havia artigos que explicavam isso nas versões passadas do Java e todo mundo replicava o código e usava o model da Sun. O mesmo vale para Highlight, que todos implementavam seus renderers. O mesmo vale também para o filter do JFileChooser. Quer mais um exemplo? Demorou até o Java 6 para fazerem um jeito fácil de colocar um botão de fechar em cada tab de um JTabbedPane…

Se existe até um artigo ou exemplo, de amplo uso, que todo mundo baixa e usa, por que já não disponibilizar o negócio direto no Swing? O questionamento é esse e não se o é possível ou não fazer no Swing.

Quase tudo é possível no Swing e certamente tudo é possível em Java.

fabgp2001:

System.out.println(getClass().getClassLoader().getResource("."));

Testei aqui e não funciona se sua aplicação estiver num .jar.
O retorno é vazio.

Você teria mais alguma sugestão?

Que fall-through indesejado é problema, é. Mas pessoalmente resolvo isso setando “‘switch’ case fall-through” como warning ou error no Eclipse.

E dá pra fazer a mesma coisa com atribuição num if.

ViniGodoy:

Lich King:

como assim limpar o console?? quem limpa o console é um comando do S.O…
Pra q vc quer pegar o diretório corrente da aplicação?

Pois é, hoje no java você é obrigado a recorrer a um Runtime.exec (ou a um ProcessBuilder) e a um comando do SO se quiser limpar a tela do console. Mas o comando em si não é java puro, não é multi-plataforma e, em suma, seria mais um workaround.

E mais difícil que isso, como ressaltou o louds, é se você quiser descobrir quantas linhas tem o console.

Outras linguagens, como C++, Pascal, etc. tem um comando que limpa a tela. Um comando da linguagem, que vai ser transformado num comando do SO em que a linguagem foi compilada.

Limpar a tela não é nada.

Se vc esta em um terminal VT100 é só mandar uma sequencia de caracteres escape e pronto, o terminal sera “limpo”. Acontece que, em java, vc pode estar em diversos tipos de terminais e os caracteres escape podem não ser interpretados da forma como vc quer.

Tem uma biblioteca que facilita transportar awt em algo para console, mas faz uso de codigo nativo.

Agora os meus 2 centavos sobre C + Java:

vcs ja pensaram em usar ORB ? se não me engano pode ser defino, na IDL, um tipo de dados sem sinam e isso gerará os stubs e skels apropriados.

ViniGodoy:

String sDir = System.getProperty(“user.dir”);

Isso não retorna o diretório da aplicação. Isso retorna o diretório corrente em que o usuário se encontra.

O que quero dizer é, em C++ é muito fácil pegar o diretório onde o .exe está gravado. Independente de qual caminho você esteja rodando o código, ou de qual seja o caminho da pasta “my docs” de seu usuário. Ok, ok, a desculpa oficial do java é: “Mas o .jar pode estar em qualquer lugar, até em um BD, ou num applet…” Mas a falta desse recurso torna aplicações com plugins gravados no diretório da aplicação (tais como o Eclipse) só resolvíveis com algum tipo de xunxo (será que é para isso que o Eclipse tem um .exe?).

Outra coisa, o problema não está no break do switch, mas no fato do switch fazer fall through. Ou seja, se você esquecer o break, ele cairá na próxima condição do switch, como se a avaliação da condição fosse verdadeira.

E isso certamente é comprovadamente propenso a erros.

Se não me engano, uma das variáveis dessas retorna o dir da aplicação sim, terei que ver isso depois.

Então o titulo deste topico deveria ser “coisas que odeio no C quando interajo com ele usando Java”

Porque o JTextField é o controlador. O modelo que deve ter um forma de validar isso. Como tal vc tem que colocar essa funcinalidade do Document.
Mas um document não tem limite (já imaginou um word com limite de caracteres?) é a aplicação do document, a sua aplicação que quer limitar. E então vc deve criar um document especifico. Que é o que todo o mundo faz. Se vc me disser que poderia existir um Document com essa capacidade, tudo bem. Isso cai no mesmo requisito do JTreeTable. Mas que é uma coisa odiável é dizer demais.

Eu não gosto de switch e também não recorro a ifs tão frequentemente. Depois de patterns como State e Strategy eles quase não são necessários. Aliás, não é uma das refatorações do catálogo do Fowler?
Eu não falei em retirar o switch. Falei em retirar o break e o fall through do switch. Também não falei em syntax suggar, nem em usar ele com Strings, isso foi por sua própria conta.

O poder do switch vem do fall throught , tirando isso o switch vira um if/else if simplificado , ou seja, vira sintax sugar. E nesse caso, adicionar mais sintaz sugar como o uso de String não faz mal nenhum.

Céus, até onde o FUD pode chegar. :shock:

Nah… esse foi o único item que eu coloquei que trata de interoperabilidade. Não ia deixar o título assim só por causa dele…

Sérgio, falou você dizer uma coisa… quais são as coisas que você odeia/não gosta no Java?

ViniGodoy:

fabgp2001:

System.out.println(getClass().getClassLoader().getResource("."));

Testei aqui e não funciona se sua aplicação estiver num .jar.
O retorno é vazio.

Você teria mais alguma sugestão?

Até da para pegar é só informar um nome de resource valido, mas ai tu vai pegar a URL do jar e nao um diretorio especifico.

]['s

ViniGodoy:

Sérgio, falou você dizer uma coisa… quais são as coisas que você odeia/não gosta no Java?

Quando eu souber de alguma vc será o primeiro a saber.

Mas por que uma aplicação em terminal teria q limpar o console???
Dê um exemplo em q seja necessário pegar o diretório em q a app está rodando…

ViniGodoy:

Já ouvi falar no MaskFormatter. Mas já usou para valer? É um componente um tanto esquisitinho. Os usuários geralmente não gostam dele, exceto para digitação de campos com máscaras mais complexas como telefones ou CEP…

hmm…Um combo q mostra seus dados em forma de tabela em vez d uma list, é isso? (Ainda não precisei disso) Pensei q fosse um combo q no seu ActionListener (se não me engano) chamasse um DAO q vc passaria no construtor dele…

Quanto ao “é pra quem não conhece java direito” não me lembro o q eu estava pensando qndo escrevi isso…

Olá

Você está certo. Da minha conexão discada via interrurbano, respondi tão rápido que escrevi besteira. O que eu acho uma limitação obsoleta no Java é não poder endereçar com 64 bits, isto é, usar long como índice de arrays.

[]s
Luca

Se você quiser escrever uma aplicação simples, em console, provavelmente vai gostar de limpar a tela e exibir dados. Alunos de java pedem isso o tempo todo! Mas, veja bem, não era esse o foco do assunto, e sim mostrar como coisas extremamente simples em outras linguagens, como essa, são praticamente impossíveis em java.

Quanto a usar o diretório da alpicação já dei um exemplo. Veja o Eclipse, que possui o diretório “plugins” num subdiretório da aplicação. Nele, o Java consegue buscar os xmls. Isso independe de como o atalho do usuário está configurado.

Outro motivo seria organização. Você poderia ter um diretório de logs convenientemente colocado numa subpasta de sua aplicação. No caso daqui, o profile do usuário é limitado em poucos mb e o local onde a empresa recomenda é numa subpasta de dados no diretório da aplicação.

Enfim, o fato é que em qualquer outra linguagem, essa observação é tão fácil de obter… no C/C++, por exemplo, ela vem no args[0]. Tanto o Delphi quanto o VB tem o mesmo recurso. Mas no Java, essa informação simplesmente não está lá.

Acho que o InputVerifier também não é a melhor maneira de resolver o problema. Para o usuário o ideal é que a aplicação se comporte como em todo lugar: o campo limite os dados em x caracteres, não deixando ele digitar mais. Mas a questão também não é essa. Esse foi um dos exemplos que eu usei para citar coisas que não estão no Swing, que estão em diversas outras bibliotecas de componente, e que tem seu uso comprovado por tutoriais e artigos muitas vezes da própria Sun que ensina a fazer do “jeito difícil”. Ou seja, se é tão comum a ponto de justificar artigos desse tipo, porque não colocar no Swing direto? Ou porque não criar métodos que facilitem o uso ao ponto da trivialidade? Esse é o questionamento.

É isso mesmo. Geralmente a gente vê a utilidade de componentes assim quando os tem a mão.

Acho que alguém já respondeu aí, mas a coisa mais odiável em Java é a manipulação de datas.

:evil:

ZehOliveira:

Acho que alguém já respondeu aí, mas a coisa mais odiável em Java é a manipulação de datas.

:evil:

Pois é. Fico pensando se a JSR 310 passaria se todo mundo ficasse com o comportamento negativo a críticas que se vê neste tópico.

Hã?

Não precisa saber o qual o diretório da aplicação para acessar alguma pasta q esteja no mesmo diretório dela mas fora do jar.
Nunca vi ninguém pedir esse negócio d limpar console em java e tb nunca precisei disso.

o usuário q vc fala é o programador?
Se vc acha q no text field já deve vir pronto esse negócio d limitar caracteres então submeta um JSR sobre isso…

ZehOliveira:

Acho que alguém já respondeu aí, mas a coisa mais odiável em Java é a manipulação de datas.

:evil:

pode dar um exemplo?

Não odeio, mas Java realmente poderia:

1. Oferecer uma maneira de lidar com periféricos, como já disseram
2. Ter mais integração com o sistema operacional (sim, sim, eu sei que tem todo esse esquema de wora e por aí vai)
3. Ter aproveitado o Tiger para oferecer algumas construções mais simples, como por exemplo:

try { // faz algo } catch(FooException, BahException ex) { // tratar exception }
4. Oferecer algumas APIs mais simples e diretas (Date e Calendar são horríveis). Sempre achei que java.util.Collection deveria ter métodos sort para eu escrever código assim:

collection.sort(); collection.sort(new BahComparator());
Ao inves de:

List list = new ArrayList(collection); Collections.sort(list, new BahComparator());
É claro, agora é tarde demais para fazer isso. Uma API para IO mais simples é razoável tambem, afinal, não ter algo como File.readLines é bem ridículo.

valeuz…

Problema: adicione sete dias a um objeto Date e imprimir no formato dd/MM/yyyy.

Solução atual (escrevi direto no forum, mas é por ai):

Date date = new Date();
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
calendar.add(Calendar.DAY_OF_MONTH, 7);
date = calendar.getTime();
SimpleDateFormat format = new SimpleDateFormat("dd/MM/yyyy");
System.out.println(format.format(date));

Algum motivo especial para um problema tão simples exigir tanto código? Que tal assim:

Date date = new Date();
System.out.println(date.plusDays(7).format("dd/MM/yyyy"));

valeuz…

Deixa eu adivinhar: você nunca implementou uma aplicação com interface de linha de comando ou a la curses, certo?

Na realidade o codigo necessário é apenas

Calendar calendar = Calendar.getInstance();
calendar.add(Calendar.DAY_OF_MONTH, 7);
SimpleDateFormat format = new SimpleDateFormat("dd/MM/yyyy");
System.out.println(format.format(calendar.getTime()));

Motivos especiais:
Separação de Responsabilidade.
Internacionalização.

calendar.add(Calendar.DAY_OF_MONTH, 7);

Essa linha é muito feia. :?

Pior que isso só o código desse método.

]['s

Esqueceram de usar setLenient(false) no Calendar, senão vc vai ter datas bizarras como 31/02/2007

Quanto ao java.util.Calendar e outras classes e interfaces mal-designadas:

• Esse é o exemplo de uma classe que quis ser genérica (e tem um monte de coisas mirabolantes), mas que acabou não sendo.
  Por exemplo, Calendar deveria ser flexível suficientemente para poder suportar não só GregorianCalendar como outros calendários.
  O problema é que nunca tinham desenvolvido um calendário alternativo (Budista, Chinês, Hebreu, Árabe, Imperial Japonês etc.) usando Calendar, para ver o que era realmente necessário, e inventaram da cabeça um monte de coisas estranhas que acabaram não sendo necessárias.
  Quando foram tentar fazer isso, não conseguiram durante anos (o Imperial Japonês apareceu no Mustang mas parece que não funciona direito), já que na verdade precisavam de mais coisas que não tinham imaginado que precisavam.
  Agora existe um monte de correções na Calendar, mas ainda ela não é muito adequada para o uso normal.

Na realidade eu queria adicionar dias a um objeto Date, por isso deixei em negrito.

sergiotaborda:

Motivos especiais:
Separação de Responsabilidade.
Internacionalização.

louds, na verdade, vc não consegue criar, com Calendar, uma data 31/02/2007 já que o lenient true usa uma heurística para encontrar a data que isso resulta. No caso, 03/03/2007:

Calendar calendar = Calendar.getInstance();
calendar.set(Calendar.DAY_OF_MONTH, 31);
calendar.set(Calendar.MONTH, Calendar.FEBRUARY);
		
SimpleDateFormat format = new SimpleDateFormat("dd/MM/yyyy");
System.out.println(format.format(calendar.getTime()));

valeuz…

Heuristica até simples por sinal, só usando resto de divisão (operador mod) =)

t+

Se é isso que queria então está errado de duas formas:

1. Date tem todos os get e set deprecated. Não mais devem se alteráveis. Devem ser usados apenas como VO para transporta milisegundos na epoca definida pelo java (em vez de usar long). O objeto mutável para trabalhar com datas é Calendar.
2. Mesmo que os get/set não fossem deprecated existem muitas regras ocultas no calculo correco de datas e tempos ( que ficam dentro de calendar) e portanto alterar Date directamente seria errado.

O ponto aqui é que é errado definir um date para depois o usar num calendar, defina logo o calendar e pronto. O unico uso de Calendar.setTime() é quando vc obtem Date de legados.

Uma vez retirada essas coisas desnecessárias, não é tão complexo assim.

E o que isso tem a ver com criar coisas complicadas?

Isso levaria dias explicando…
Versão resumida: criar objeto neutro em relação ao local é muito difícil. Ainda para mais quando mexe com datas.

Dê uma olhada na API Joda-Time para ver só como é complicado quando vc decide que Calendar não é suficiente. Agora compare com a biblioteca Time and Money para ver como é fácil cometer erros e tornar os objetos não internacionalizáveis.

Hum, não que essa seja a principal discussão do tópico, e acho que mesmo vc sabe que a API poderia - alias, deveria - ser mais simples. Vamos lá, eu trabalho com código legado, de outras APIs e esses códigos usam Date para lidar com datas, não Calendar, Date. Então, em determinado momento, alguma dessas APIs tão legais me retorna um date e preciso somar sete dias e devolver para API gente boa um objeto Date. A partir disso chegamos em algo parecido com o método que mostrei.

sergiotaborda:

Isso levaria dias explicando…
Versão resumida: criar objeto neutro em relação ao local é muito difícil. Ainda para mais quando mexe com datas.

valeuz…

jack_-_ganzha:

O erro não é ter que lidar com conceitos complicados. O erro é expor uma interface complicada para manipular datas. Joda-Time, por exemplo, apesar de lidar com as mesmas complicações, oferece uma interface bem mais humana.

valeuz…

Calendar não foi feito para ser uma interface humana. Da mesma forma que Joda Time não foi. TimeAndMoneyAPI foi e tem um monte de defeitos . Pq ? simplesmente pq o próprio assunto de datas e calendários é muito complexo.
Concerteza acharia maravilhoso fazer intervalo = date1.minus(date2) mas isto está errado pelo próprio conceito de data. Data é um conceito cultural e não um conceito cientifico. a operação “diferença de data” não é unica ela depende do contexto em que está sendo feita.
Exatamente por isso Calendar não define operações de subtração, apenas de soma. É realmente muito complexo e a Calendar faz o trabalho que se propõe a fazer.
O que ela não faz é o trabalho que seus inventores se propuseram -universalidade- nem o que o programador precisa - simplicidade e encapsulamento total de todas as regras. Só que um programador no brasil não calcula diferença de datas da mesma forma que um na china - e lá se vai o encapsulamento.

Concerteza a Date and Time API irá resolver muitos dos dilemas dos programadores, mas os problemas de calcular diferenças continuarão.
veja porque
http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-time.html

Agora, o que isto tem a ver com o tema ? Date e Calendar não são odiáveis. Em VB e Delphi nem existe nada parecido , em C nem pensar.
Date e Calendar demonstram exatamente como o Java é maior que essas lamexices, pq quem não gosta pode sempre fazer melhor! E depois enviar para o JCP tal como vez o pessoal da JT.

Ok, mas acho que é justamente esse o problema que está sendo citado. Deveria ter sido feito de maneira mais humana.

Ok, mas porque GregorianCalendar não define? Eu poderia ter métodos para trabalhar facilmente num calendário gregoriano. Além do que, embora o conceito possa estar errado, infelizmente, as pessoas fazem SIM contas com datas!

Veja o método get do calendário gregoriano. Ele é simplesmente ridículo! Usaram o mesmo método para retornar vários fields. Por que essa decisão? Por que não simplesmente gregorianCalendar.getDay()?

Outro problema aqui é investir numa API que é complexa em 90% dos casos de uso, para facilitar outros 10%. A maior parte do mundo onde interessa exportar um programa ainda usa o calendário gregoriano. Certamente, muitos programadores japoneses, chineses, indus, estão fazendo aplicações usando esse tipo de calendário. Então, para esse caso, a preocupação de uma classe fácil e agradável deveria ter sido levada muito mais em conta.

Isso é uma grande verdade. Mas creio que as superclasses poderiam manter o encapsulamento, enquanto subclasses exportassem o comportamento específico de cada região.

O ideal até é que houvesse uma forma de converter um calendário de uma região para outra. Afinal, o calendário nada mais é do que a representação localizada de um instante no tempo. E esse instante no tempo, é o Date.

Que ironia do destino… Não demorou muito e olha o tópico que apareceu no GUJ:
http://www.guj.com.br/posts/list/0/53947.java#283472

Aliás, aproveita e dá uma olhada também em:
http://www.guj.com.br/posts/list/3515.java
http://www.guj.com.br/posts/list/22287.java
http://www.guj.com.br/posts/list/3051.java
http://www.guj.com.br/posts/list/22900.java

Agora pelo menos você pode dizer que já viu gente pedindo para limpar a tela…

Mas não fazem da mesma forma. Por exemplo, numa empresa de entregas trabalhas com dias uteis para entrega. Num banco calculas juros com meses de 30 dias e anos de 360 dias. Nada disto corresponde com o calendário , é uma regra de negocio.

Porque nem todos os calendários têm 12 meses. Nem todos os meses tem 30 dias.

O dia do mês , do ano , da semana ?

O assunto é muito mais complexo do se imagina à primeira vista.

Não sei se você leu.

Estou falando do GregorianCalendar. Aquele definido pelo papa Gregório, que foi uma correção do calendário Juliano, definido por Julio César tempos antes.

É um calendário solar. Nesse calendário, todo ano tem efetivamente 12 meses. Se você me mostrar um calendário Gregoriano sem 12 meses, certamente você vai estar me mostrando um calendário Gregoriano errado.

Nem a empresa de entregas e nem o banco, usam o calendário gregoriano. Nesse caso, você deveria implementar seu próprio calendário. Ou, fazer programa que adapte a regra de negócio da empresa ao calendário gregoriano (usado pelos clientes), o que seria muito mais fácil se a classe GregorianCalendar fosse mais fácil.

sergiotaborda:

O dia do mês , do ano , da semana ?

O assunto é muito mais complexo do se imagina à primeira vista.

Ok, isso um javadoc resolve facilmente. É o mais comum, ou seja, o do mês. É o que normalmente queremos quando fazemos getDay() num calendário gregoriano. Nada contra ter outros métodos, getWeekDay(), getYearDay(). Mas, na minha opinião, usar constantes para o field não só deixa o código mais rebuscado à toa, como também é menos intuitivo.

Também não tenho nada contra um get mantendo o field para a superclasse. Afinal, sabe-se lá como são divididos os calendários no mundo a fora… Mas a classe GregorianCalendar, que é muito usada, certamente deveria ter métodos mais digeríveis. E aqui não estou falando só de gets, mas métodos para soma/subtração de dias, meses ou anos numa data, e outros métodos que o pessoal já comentou por aqui…

É muito importante que a interface da classe GregorianCalendar seja fácil e agradável de usar. Como ressaltado no javadoc da própria classe:
“provides the standard calendar used by most of the world”

ViniGodoy:

sergiotaborda:

Mas não fazem da mesma forma. Por exemplo, numa empresa de entregas trabalhas com dias uteis para entrega. Num banco calculas juros com meses de 30 dias e anos de 360 dias. Nada disto corresponde com o calendário , é uma regra de negocio.

(…)

Porque nem todos os calendários têm 12 meses. Nem todos os meses tem 30 dias.

Não sei se você leu.

Estou falando do GregorianCalendar. Aquele definido pelo papa Gregório, que foi uma correção do calendário Juliano, definido por Julio César tempos antes.

Mas GregorianCalendar herda de Calendar e Calendar é genérico, então GregorianCalendar não pode não o ser. Pode ter método utilitários como getDay , mas os métodos get(int) não podem ser retirados.

Além disso vc fala como se usasse GregorianCalendar directamente. Isso é um erro comum e perigoso. Vc deveria usar Calendar.getInstance(new Locale(“pt”,“BR”)) , vai que no futuro este método não retorna mais GregorianCalendar e sim uma versão melhorada ou revista como, digamos, GregorianCalendar2. Vc viola o encapsulamento e isso , claro trás os problemas que vc afirmou. Parece que é tudo mais complicado do que deveria ser. Pois, mas tente usar Calendar.getInstance e verá que faz todo o sentido.

É obvio que o GregorianCalendar terá que ter todos os métodos de Calendar. Mas ele não é obrigado a se restringir a eles. Métodos que auxiliassem calendários desse tipo seriam muito bem-vindos na maior parte do mundo, onde o calendário é usado.

A abordagem de Calendar cal = Calendar.getInstance(); tem uma série de problemas:

1. A maior parte dos negócios é dependente do formato do calendário retornado. Nesse caso, seu programa também terá essa dependência. Por exemplo, você fará um algoritmo para calcular dias comerciais pulando finais de semana e feriados. Entretanto, não haverá sábados e domingos caso um calendário muito exótico seja retornado…
2. Trabalhar genericamente com um calendário não só é extremamente complicado, como também não é necessário em uns 90% das aplicações;
3. Se você fixar o local Calendar cal = Calendar.getInstance(“pt”, “BR”), sua aplicação continuará não sendo genérica e, portanto, seria muito mais inteligente utilizar uma classe que te facilitasse a vida.

Se você quer tanto assim separar a implementação da classe final, porque não criar uma interface para o Calendário gregoriano, que seja filha da interface Calendar? Nesse caso, um método Calendar.getGregorianCalendar(Locale loc) faria a mágica.

Ainda sim, mesmo que isso não seja feito, discordo da sua alternativa de dizer que é perigoso trabalhar com GregorianCalendar diretamente por dois motivos:

1. Calendários não mudam todo o dia. É muito mais provável que implementações mais eficientes de GregorianCalendar serão feitas na própria classe GregorianCalendar, não em uma classe separada.

Mesmo que um calendário se alterasse, o sistema dependeria do novo formato e certamente teria que ser alterado de qualquer jeito.

2. É muito melhor contar com uma interface simples e que ajude a programar, que torne erros menos propícios e que tenha sido planejada considerando situações comuns (e possíveis enganos) do uso do calendário mais comum do mundo do abrir mão disso para contar com a promessa de uma “futura, possível, porém muito improvável, implementação mais eficiente em uma classe diferente dessa”.

A generalização é interessante, mas existe um trade-off que não creio que tenha sido corretamente avaliado no caso do GregorianCalendar. Imagine se todas as classes da Collections Framework tivessem como sua interface principal Collection, e apenas Collection? Seria um inferno trabalhar com um list, ou com um set, ou com um map. Muitas implementações mais eficientes também seriam simplesmente abandonadas.

Na minha opinião, o calendar deveria ter seguido um modelo semelhante. Uma interface genérica para quem quer suportar calendários do mundo todo (e esse programador sim, vai sofrer, mas porque as regras do negócio exigem, não porque alguém da Sun quis mostrar o quanto o java é “genérico”), e uma interface mais específica para quem quer apenas se preocupar com o calendário do papa Gregório, com métodos úteis, otimizados e eficientes para operações nesse tipo de calendário (como soma/subtração de dias, obtenção de dias úteis entre duas datas, etc).

rpz tava vendo uma coisa que fiquei com raiva em java é uma classes que tem remove() e outras que tem delete()… po isso me confude toda hora… se a class tem o delete ou o remove… perco maior tempo com isso… e as vezes tenho q consultar a api…

rodrigo_gomes:

Olá,

Acho que uma das coisas que mais enche a paciencia é mexer com data (sem user JODA).

[]´s

Concordo por isso to ajudando a fazer a JSR-310 com o Mister M, dessa vez vai melhorar…

Pessoal, no começo do tópico apareceram várias vezes os termos fall through e workaround. Vcs podem me explicar o que significam?

fall through é quando você tem uma condição do switch sem break. O que o switch faz? Ele "cai para" (fall through) a próxima condição e a executa!!! Exemplo:

int i = 2;

switch (i) { 
      case 1:
           System.out.print("1");
      case 2:
           System.out.print("2");
      case 3:
           System.out.print("3");
      case 4:
           System.out.print("4");
}

Qual é o resultado do programa acima? Resposta, devido ao Fall through é 234, pois faltam os breaks. Breaks são facilmente esquecidos (principalmente no início). Outro problema é que, como não contamos com uma condição sem o break, é muito difícil encontrar um erro devido ao fall through (acho sinceramente que nossa cabeça tende a completar a condição com o break quando estamos analisando o código, especialmente se isso ocorrer em uma só condição).

O termo workaround é quando você não tem uma solução direta para o problema e precisa contorna-lo usando formas indiretas. É praticamente um xunxo, exceto pelo fato de que no workaround você sabe que está fazendo e o porque...

Um exemplo de workaround comum em java é chamar Runtime.exec com o comando cls para limpar a linha do console. O correto seria ter um comando java puro para isso, mas como não existe, recorremos a essa "gambiarra".

O problema é que workarounds são imperfeitos, sujeitos a erro e geralmente são um trabalho adicional.

Veja o exemplo de interoperabilidade com C++. No C, existem tipos unsigned, ou seja, um byte pode ir de 0 até 255. Vamos supor que em java, você precise ler um valor 230 que veio de um byte em C. Não existe um tipo "unsigned byte" no Java, então o workaround para isso é ler o byte e converte-lo para um short:
short valor = (short)sockInputStream.readByte();

E se você precisasse ler um unsigned short? Teria que le-lo para um int. E assim sucessivamente. Mas o workaround deixa de ser prático ao tentar ler um unsigned long.

Veja que para enviar bytes, você também terá que fazer ao contrário. Para enviar um unsigned byte você teria que fazer:
byte byteValue = (byte)(0xFF & shortValue);
sockOutputStream.write(byteValue);

E veja, nesse caso, que trabalho adicional!

Esqueci de perguntar um:

O que significa spurious wakeups? Obrigado por responder minhas dúvidas!

E só pra constar, eu concordo com vc, o break deveria ser removido.

von.juliano:

Esqueci de perguntar um:

O que significa spurious wakeups? Obrigado por responder minhas dúvidas!

E só pra constar, eu concordo com vc, o break deveria ser removido.

O método wait deveria fazer a thread esperar até uma ocorrência do método notify ou notifyAll, mas ela pode, aleatoriamente, deixar de esperar e acordar. O certo então, é chamar o método wait num loop que verifica se a condição para a thread acordar já foi alcançada. Dê uma olhada em http://java.sun.com/javase/6/docs/api/java/lang/Object.html#wait(long)

Então spurious wakeups é quando uma thread que deveria estar esperando “acorda” sozinha?

SWING!!!

É isso mesmo.

O wait pode “acordar” num notify ou no tempo indicado pelo parâmetro, certo? Em partes…

Com o spurious wakeup o wait pode acordar antes disso, sem razão aparente alguma para que isso ocorra… por isso, waits sempre devem estar precedidos por um while, que certifiquem a condição de parada e mantenham o código no wait caso um wakeup desse ocorra.

pcalcado:

Deixa eu adivinhar: você nunca implementou uma aplicação com interface de linha de comando ou a la curses, certo?

deixa eu ver… uma aplicação a la curses apaga a tela e redesenha tudo de novo toda vez q vc muda de janela ou menu, certo?

por q ficar se preocupando com limpar tela em java se já fizeram API’s pra aplicações gráficas em console?

http://www.guj.com.br/posts/list/22579.java#284478

Que tal:

1. Para programar para linux, Unix, HP, em ambientes onde não há um ambiente gráfico (ou o interesse em usa-lo) sem a necessidade de uma grande e complexa API?
2. Para programar em alguns hardwares, onde não tem ambientes gráficos, mas tem um console e onde o uso de APIs externas pode ser desinteressante?
3. Para dar aulas de java, mostrando programas “simples mas limpinhos” para alunos de java que ainda não estão preparado para as complexidades de um ambiente gráfico ou uma API externa?
4. Para que isso seja garantido pela Sun, em todos os ambientes onde seja suportada uma VM. Assim também temos a garantia de que isso será mantido enquanto o Java existir…

E a questão aqui é simplesmente o java ter ou não esse recurso. O tópico que você mostrou é simplesmente uma prova de que tantas pessoas precisam dele que até se dignaram em fazer algumas APIs para isso!

Não seria legal então a Sun, ter uma forma 100% java de fazer isso, sem a necessidade de jar externos, garantida em todas as plataformas onde uma VM é suportada e mantida pela equipe deles?

ViniGodoy, impressão minha ou vc quer q todas as bibliotecas q vc usa estejam no JDK por padrão só pelo fato de vc usá-las?

Então, de acordo com teu raciocício, hibernate deveria vir por padrão no JDK só pra vc não ter q baixar as libs dele?

precisa de clear screen pra mostrar programinhas em java do tipo “informe x pessoas e mostre na tela” ou “informe números até seja informado uma letra e depois mostre só o maior”, por exemplo?..java não é pascal…

O q vc quer dizer com “simples mas limpinhos”?

vc quer todas as API’s do mundo no JDK?

Lich King:

vc quer todas as API’s do mundo no JDK?

Lich King:

ViniGodoy, impressão minha ou vc quer q todas as bibliotecas q vc usa estejam no JDK por padrão só pelo fato de vc usá-las?

Então, de acordo com teu raciocício, hibernate deveria vir por padrão no JDK só pra vc não ter q baixar as libs dele?

Realmente, não seria má idéia… :lol:
Aposto que se a Sun fizesse isso, você defenderia com a mesma vêemencia que vem defendendo o Java… Um framework de persistência mantido pela Sun seria legal, principalmente se ele pudesse coexistir com o Swing de maneira mais transparente que o hibernate.

Ou então, uma especificação… como no caso do JDBC. Seria mesmo muito legal um “Java Object Persistence Specification”. E o que seria do J2EE sem um conjunto de especificações desse tipo?

Ok, você não concorda com a minha afirmação do console? Tudo bem. Entretanto, isso não invalida o argumento no geral. Existem coisas que são simples em outras linguagens, mas são extremamente complexas em Java. Mas, realmente acho que o Java não deveria ficar atrás do C++, do Pascal, do Borland Dephi por causa disso.

Ok, essa foi uma clara tentativa de ridicularizar o meu argumento. Infelizmente, isso não invalida o que eu disse, tampouco defende seu ponto de vista. Você pegou 1 dos 4 itens que eu falei, mostrou programas simples (como se isso fosse um problema), e depois concluiu sem sequer dar um argumento de por que o Java não deveria ser capaz de fazer isso.

Acho que todo mundo no GUJ sabe que “Java não é Pascal”. Mas e daí? Ele também não é C++ mas tem varargs, printf… não é VB/Delphi e tem interface gráfica… Colocar funções de console também não transformará o Java no pascal.

E aliás, por que não ser capaz de fazer programas simples assim, mas que apresentem uma interface agradável (com cores, limpeza de tela, etc)? Não só aumentaria a abrangência da linguagem como também diminuiria sua curva de aprendizado. E para a linguagem no geral, acho que ter uma curva de aprendizado suave é tão importante quanto domina-la no futuro.

Sobre tipos unsigned esqueci de comentar algo.

O Java sempre fez propaganda de ser uma aplicação com amplo suporte a redes, internet, e coisas afins. Por isso senti falta dos tipos unsigned.

Mas, se usarmos o argumento do sergiotaborda (e parte dos meus também) de que isso é focado em um pensamento do futuro e que pode ser propenso a erros, ainda fica um questionamento nesse sentido.

Por que não existe um InputStream/OutputStream para isso? Quero dizer que, se desde o início a linguagem foi planejada para uso em Internet, redes e afins, não seria lógico que houvesse uma classe pelo menos preocupada em se comunicar com os servidores mais comuns do mundo naquela época, feitos em C++?

Se o seu console possui 80 linhas pq não “limpá-lo” utilizando um for de System.out.println("\n") 80 vezes?

Algumas linguagens apesar de terem funções para limpar console suas implementações são basicamente essa. Ou então utilizam alguma função especifica do SO o que seria meio dificil de implementar em Java.

Pode não ser uma solução “elegante” mas funciona.

Alguém por favor me diga como fazer grep, awk, sed, sort e uniq com a saída de um programa feito em Java que não usa o console. Se http://en.wikipedia.org/wiki/Windows_PowerShell]até a Microsoft se rendeu ao shell Java nhão ter um mínimo de suporte à CLI é ridículo.

Gambiarras para limpar o console já são feitas, o ponto é exatamente a falta de um padrão.

Quanto à especificação/biblioteca de persistência, já houveram inúmeros padrões e tentativas, o mais recente é o EJB 3.0 que pode ser integrado à uma aplicação Swing. para Java SE não existe especificação de persistência.

Ontem um colega tava reclamando que para ler um inteiro do teclado precisa fazer um Integer.parseInt, sem contar a maravilha de new StreamReader(new InputStream(new BufferedReader(new InputReaderStream(new CaceteWTF())))) só pra ler uma string…Eu achei estranho e fui procurar um modo fácil de ler um inteiro, pra minha surpresa, o menos pior que eu consegui foi um new Scanner(System.in).nextInt();

E tive que pesquisar na internet, só para ler um inteiro do teclado! Não era mais fácil um System.in.readInt(“digite”)? AH mas tem uma nova classe Console, mas que às vezes retorna null, como pra mim…

pcalcado:

Alguém por favor me diga como fazer grep, awk, sed, sort e uniq com a saída de um programa feito em Java que não usa o console.

Você me fez lembrar de uma coisa interessante: os programas em si também deveriam ser objetos, assim teríamos comunicação transparente entre processos, onde é irrelevante se o programa/objeto é acessado por um usuário ou por outro programa, e se este programa é GUI ou shell (onde isso seria apenas perspectivas de uma mesma coisa)…

Quem sabe daqui a 20 anos surge algo assim…

Aliás, já tentaram fazer comunicação entre dois processos rodando na mesma VM?

O Java não tem qualquer suporte a isso… a não ser que você xunxe, usando RMI, que vai se comunicar por sockets no localhost.

Mas daí é usar um canhão para matar um pato.

ViniGodoy:

Aliás, já tentaram fazer comunicação entre dois processos rodando na mesma VM?

O Java não tem qualquer suporte a isso… a não ser que você xunxe, usando RMI, que vai se comunicar por sockets no localhost.

Mas daí é usar um canhão para matar um pato.

Você só consegue executar uma JVM por processo, logo não é possivel fazer comunicação entre dois processos dentro da mesma VM.

Caso você esteja falando de duas threads na mesma VM, pode usar Pipes, que Java suporta a muito, muito tempo já. Caso seja IPC, sockets são a solução mais indicada para transporte e a aplicação usa o protocolo que desejam sobre.

Java é uma linguagem pobre quando o assunto é programação concorrente, estudem Erlang e terão uma idéia de como poderia ser muito, muito mais facil.

louds:

Você só consegue executar uma JVM por processo, logo não é possivel fazer comunicação entre dois processos dentro da mesma VM.

Caso você esteja falando de duas threads na mesma VM, pode usar Pipes, que Java suporta a muito, muito tempo já. Caso seja IPC, sockets são a solução mais indicada para transporte e a aplicação usa o protocolo que desejam sobre.

Java é uma linguagem pobre quando o assunto é programação concorrente, estudem Erlang e terão uma idéia de como poderia ser muito, muito mais facil.

Não, não estava falando de duas threads, e sim de dois processos mesmo.

Realmente, você está certo. Cada processo java tem sua VM. Me lembro que vi um artigo falando de um projeto onde gostariam que as VMs tivessem uma área compartilhada de memória e pudessem carregar uma vez só classes como String, por exemplo.

Mas, o problema básico é: não existe comunicação entre dois processos java. Pelo menos, não uma maneira direta, sem envolver sockets, compartilhamento de arquivo, etc…

ViniGodoy:

Mas, o problema básico é: não existe comunicação entre dois processos java. Pelo menos, não uma maneira direta, sem envolver sockets, compartilhamento de arquivo, etc…

Não existe maneira portavel de implementar isso. Windows tem named pipes, sistemas posix possuem message queues e unix sockets. Cada um com características bem distintas. No final das contas, é muito melhor e mais facil usar simplesmente sockets, principalmente por tornar simples migrar de comunicação local para remota. Além disso, a diferença de performance entre sockets e primitivas de IPC é mínima.

hummm… eu imaginei que a razão fosse essa.

Filho, como se cria um tópico, tô querendo fazer Um tibia em Java, mas tô com problemas em alguns pequenos detalhes: O jogo tem q possuir a opção on e off- line, chamadas recursivas, além de um ambiente grafico em 5D (não é 3d, nem 4d, é 5!! 5!!!), melhor ainda necessita q haja interações e aliterações do usuário para com o caso em questão. Sem contar q as SDs e Uhs devem ter um efeito vermelho na tela e tb necessita q haja um botão W para q conclua-se a Conjectura projetada. Antes de mais ironias, eu ja comecei a criar esse Game. Possuo a versão 1.0 que tem a opção conglomerada de inteceptar biutres e cefalocordados além de prosocopar os ataques em um unico e concebido golpe de nomenclatura W.
Se alguém conseguir me ajudar, responda

Dublador Walawala:

Filho, como se cria um tópico, tô querendo fazer Um tibia em Java, mas tô com problemas em alguns pequenos detalhes: O jogo tem q possuir a opção on e off- line, chamadas recursivas, além de um ambiente grafico em 5D (não é 3d, nem 4d, é 5!! 5!!!), melhor ainda necessita q haja interações e aliterações do usuário para com o caso em questão. Sem contar q as SDs e Uhs devem ter um efeito vermelho na tela e tb necessita q haja um botão W para q conclua-se a Conjectura projetada. Antes de mais ironias, eu ja comecei a criar esse Game. Possuo a versão 1.0 que tem a opção conglomerada de inteceptar biutres e cefalocordados além de prosocopar os ataques em um unico e concebido golpe de nomenclatura W.
Se alguém conseguir me ajudar, responda

Cara, perdeu a graça já.

Dublador Walawala:

Filho, como se cria um tópico, tô querendo fazer Um tibia em Java, mas tô com problemas em alguns pequenos detalhes: O jogo tem q possuir a opção on e off- line, chamadas recursivas, além de um ambiente grafico em 5D (não é 3d, nem 4d, é 5!! 5!!!), melhor ainda necessita q haja interações e aliterações do usuário para com o caso em questão. Sem contar q as SDs e Uhs devem ter um efeito vermelho na tela e tb necessita q haja um botão W para q conclua-se a Conjectura projetada. Antes de mais ironias, eu ja comecei a criar esse Game. Possuo a versão 1.0 que tem a opção conglomerada de inteceptar biutres e cefalocordados além de prosocopar os ataques em um unico e concebido golpe de nomenclatura W.
Se alguém conseguir me ajudar, responda

hÁ há hà ALGUEM AQUI DORMIU COM O ARI TOLEDO ¬¬

não gosto de getters e setters. Nem conheço mta coisa do ruby, mas só nessa diferença, eu já gostei.

Dublador Walawala:

Filho, como se cria um tópico, tô querendo fazer Um tibia em Java, mas tô com problemas em alguns pequenos detalhes: O jogo tem q possuir a opção on e off- line, chamadas recursivas, além de um ambiente grafico em 5D (não é 3d, nem 4d, é 5!! 5!!!), melhor ainda necessita q haja interações e aliterações do usuário para com o caso em questão. Sem contar q as SDs e Uhs devem ter um efeito vermelho na tela e tb necessita q haja um botão W para q conclua-se a Conjectura projetada. Antes de mais ironias, eu ja comecei a criar esse Game. Possuo a versão 1.0 que tem a opção conglomerada de inteceptar biutres e cefalocordados além de prosocopar os ataques em um unico e concebido golpe de nomenclatura W.
Se alguém conseguir me ajudar, responda

tem louco pra tudo !!

era pra rir

CTRL-Z em um JTextArea

tem que implementar (UndoAction e RedoAction)

ufa!!!

uma coisa que odeio no guj: gente que revive tópicos