Godzil (./3371) :
fseek/ftell n'on jamais ete fait pour ca c'est certain, si le fichier est un stream ca n'a aucun sens par exemple. Si le fichier est un device ca n'a aucune sens aussi .

En effet. Utiliser fseek et ftell pour déterminer la taille d'un fichier est clairement un hack. Ça ouvre le fichier pour rien (et du coup ne fonctionne pas si l'utilisateur n'y a pas accès en lecture). C'est à ça que sert fstat.

fstat pourrais etre standard, mais non c'est con, c'est POSIX, apres le probleme de fstat c'est que sa structure est trop dependant de l'OS, certaines infos ne sont pas pertinentes sous autre chose qu'un UNIX, mais oui une fonction standardisé pour savoir le type de fichier (ficher, stream, device, ...) la taille si c'est un fichier etc... serait plus que la bienvenue.

fstat existe aussi sous Windows. Je vois mal quel autre système non-POSIX tu voudrais viser.

Uther (./3372) :
La bibliothèque standard est correcte mais dans les programmes Java sur lesquels je tombais couramment, il y avait trop souvent des organisations de classe inutilement complexes a vouloir gérer trop de choses. Je ne parle pas des forcément des Factory en particulier. C'était pas vraiment un problème du langage lui même mais une mauvaise habitude généralisée chez les architectes Java qui adorent recourir a des structures complexe pour prouver leur compétences alors qu'une solution simple était tout a fait possible, ce qui lui a donné une réputation de langage verbeux.

Je me souviens pas des détails, ça fait un moment que j'en ai pas refait, mais Spring était pas mal dans le style de multiplier les objets intermédiaires et les interfaces qui ne sont qu'un masque de l'implémentation. Je ne parle même pas des EJB qui étaient un horreur absolue.

Un exemple d'API absolument bordélique à utiliser est Calendar. Heureusement que JSR 310 a apporté une API utilisable pour ça.