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?
[quote=ViniGodoy][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. 
Você teria mais alguma sugestão?[/quote]
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
[quote=ViniGodoy]
Sérgio, falou você dizer uma coisa… quais são as coisas que você odeia/não gosta no Java? [/quote]
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…
[quote=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…[/quote]
Como assim o usuário não gosta? Por q vc acha ele esquisito?
Pra validação em swing tem tb o InputVerifier, q valida quando o componenete perde foco.
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:
[quote=ZehOliveira]Acho que alguém já respondeu aí, mas a coisa mais odiável em Java é a manipulação de datas.
:evil:[/quote]
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…
[quote=ZehOliveira]Acho que alguém já respondeu aí, mas a coisa mais odiável em Java é a manipulação de datas.
:evil:[/quote]
pode dar um exemplo?
Não odeio, mas Java realmente poderia:
- Oferecer uma maneira de lidar com periféricos, como já disseram
- Ter mais integração com o sistema operacional (sim, sim, eu sei que tem todo esse esquema de wora e por aí vai)
- 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. 
[quote=sergiotaborda]Motivos especiais:
Separação de Responsabilidade.
Internacionalização.
[/quote]
E o que isso tem a ver com criar coisas complicadas?
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+