Question

Je suis curieux de savoir ce que les autres programmeurs de Java considèrent comme leur partie préférée du langage, pourquoi ils se sentent ainsi et pourquoi d’autres programmeurs devraient également vouloir en connaître parfaitement le langage. Je recherche des raisons telles que la simplicité, la performance, etc. Merci.

Était-ce utile?

La solution

Mon API Java préférée est Collections Framework . Je me trouve à l'utiliser tout le temps au lieu de lancer mes propres implémentations, ce qui est très agréable et simple à utiliser. Il se compose de plusieurs utile et des implémentations interchangeables de structures de données et d'algorithmes hautes performances, ainsi que plusieurs méthodes pratiques pour envelopper des fonctionnalités supplémentaires.

Un tutoriel de Josh Bloch est disponible à l'adresse suivante: http: // java.sun.com/docs/books/tutorial/collections/index.html

Autres conseils

Ma partie préférée de l'API est définitivement java.lang . Il a cette classe appelée String , ce qui vous permet de manipuler facilement des tableaux de caractères. Tout programmeur soucieux d’écrire du bon code Java devrait le vérifier.

java.util.concurrent est critique dans ma vie. Nous faisons beaucoup de programmation multicœur et l'idée d'essayer de mettre en œuvre toutes nos tâches en utilisant des threads bruts à l'ancienne me fait mal au cœur.

Le pool de structures de données spécialisées qu’il fournit est un bon exemple de ce que le paquet de concurrence nous facilite vraiment dans la vie. Mon favori personnel est le CopyOnWriteArrayList . . Nous en utilisons beaucoup dans des situations où la tâche d'affichage lit un cache de données pour mettre à jour l'écran, tandis qu'une autre tâche prend des informations du réseau pour mettre à jour le cache. Normalement, il s'agirait d'une invitation aux collisions, ConcurrentModificationExceptions et des horreurs similaires. À l'aide de CopyOnWriteArrayList, la tâche d'écriture crée une nouvelle copie des données si elle doit en ajouter, garantissant ainsi que le lecteur disposera toujours d'un ensemble de données valide (bien que potentiellement obsolète) à afficher.

Comme le dit le javadoc,

  

Ceci est généralement trop coûteux, mais peut   être plus efficace que les alternatives   lorsque les opérations de traversée énormément   plus nombreux que les mutations, et est utile   quand tu ne peux pas ou ne veux pas   synchroniser les traversées, mais doivent   empêcher l'interférence entre concurrents   discussions.

Java élimine des classes entières de bogues que je présenterais normalement pour résoudre ce problème, me permettant ainsi de me concentrer sur les problèmes réels que je dois résoudre.

Définitivement le Framework de collections. Il est utilisé à tout moment, que vous utilisiez Java côté serveur ou côté client, graphique ou non. C'est facile à utiliser. La plupart des classes de structure de données ont à la fois une version générique et une version générique (il est préférable d'utiliser la seconde, mais il existe un code hérité qui utilise fortement la première), mais elles sont pratiquement identiques en termes d'API, autres que les paramètres de classe. Dans .NET, les deux versions peuvent avoir des noms / API différents, ce qui peut être très déroutant. J'aime aussi la façon dont Java Collections Framework utilise des algorithmes comme méthodes statiques (par exemple, Collections.sort (collectionVar)) plutôt que comme des méthodes d'instance. Dans .NET, ils utilisent des méthodes d'instance et pour une raison quelconque, toutes les structures de données ne possèdent pas un tri ... Collections Framework est également très riche et vous pouvez trouver des structures de données simples et spécialisées (par exemple, LinkedHashMap qui préserve l'ordre d'insertion).

Un inconvénient que j’ai entendu, c’est que la structure ne fonctionne pas bien et que certaines personnes écrivent la leur. Je ne peux pas le vérifier car je ne traite pas de choses critiques en termes de performances.

javax.naming

http: //java.sun .com / javase / 6 / docs / api / javax / naming / package-summary.html

Java est une excellente technologie d’intégration de systèmes en raison de sa portabilité et JNDI résume bien la complexité d’obtenir le premier contact avec un système distant.

Réflexion. java.lang .reflect et certains dans java .lang (principalement Class et ClassLoader).

Streams. Les flux en Java sont beaucoup plus faciles à comprendre et à implémenter que leurs homologues en C ++ (opinion) et il est généralement facile de voir, en fonction des noms des flux fournis avec l'API, ce qu'un flux va faire pour vous.

Je suis un grand fan de JPA dans Java EE . . Cela a réduit la quantité de travail que je devais faire pour les grandes applications (qui utiliseraient des EJB) et les petites applications.

JAAS, l’API de sécurité, est à proximité. Voici le lien pour JAAS Java SE. : http://java.sun.com/javase/technologies/security/

Jusqu'à présent, le paquet API java.util.regex est mon préféré, car il m’a empêché de réinventer la roue à maintes reprises lorsqu’il s’agit de rechercher et d’utiliser des morceaux de chaînes à des fins diverses.

java.util est très utile. Pourquoi?

  • Collections. Beaucoup d'entre eux!
  • Classes de date et heure
  • Scanner de texte
  • Utilitaire d'injection de dépendances (depuis Java 6)
  • Un fil de discussion
  • Nombres aléatoires
  • Le modèle d'observateur est présent
  • propriétés Java

java.util.jar - Aide au chargement de fichiers .jar dans un chargeur de classes pour mes plugins d’application! Je l'aime.

java.util.regex

Il y a d'autres paquets sans lesquels je ne peux pas vivre, mais le paquet regex doit se situer dans la partie supérieure des "plus importants ajouts à java". - définitivement avec les collections.

Je suis d’accord avec le commentaire de Reflection. de loin la partie la plus utile / puissante de l’API Java

En repensant à l'époque de Java, l'API la plus amusante à utiliser était java.util.concurrent , tout simplement parce qu’il fournit des blocs de construction bien pensés et faciles à utiliser pour le traitement en parallèle.

InheritableThreadLocal jusqu'au bout !!! Tellement de possibilités d’écrire du code obfusqué et la bobine de corde pour se pendre ne semble jamais manquer.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top