Coisas que odeio em Java

Assuntos Gerais
#21

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.

[quote=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.[/quote]

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.

#22

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.

#23

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.

[quote]

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.

#24

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…
…:smiley:

#25

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.

#26

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 …

#27

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.

#28

Olá,

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

]['s

#29

Bom…

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

E porque nao usar?

]['s

#30

[quote=fabgp2001] Olá,

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

]['s[/quote]

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

#31

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?

#32

DropDownButton não seria um combobox?

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

#33

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. :wink: 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.

#34

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. :smiley:

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/

[quote=Lich King][quote=tingol]
Ainda acho que a atribuição deveria ser “:=” e a comparação “=”, tal como no Pascal
[/quote]
por q?[/quote]

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.

#35

[quote=fabgp2001] System.out.println(getClass().getClassLoader().getResource(".")); [/quote]

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

Você teria mais alguma sugestão?

#36

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.

#37

[quote=ViniGodoy][quote=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?
[/quote]
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.[/quote]

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.

#38

[quote=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.[/quote]

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

#39

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

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.

[quote]
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.[/quote]

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.

#40

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