En passant Java Gold SE 8

introduction

Cette fois, j'ai pris le Java SE 8 Programmer II (Gold) un certain jour de novembre et je l'ai réussi.

Il y a diverses expériences de réussite dans ce Qiita, et j'ai moi-même pensé à passer l'examen d'or vers le mois de mai, donc je ne pense pas que j'ai pu étudier efficacement en guise de compliment.

Cependant, je sens que j'ai pu approfondir le processus et les idées de l'opération au fil du temps. En fait, ce n'était pas un score parfait, mais j'ai pu suivre le processus et résoudre le problème en mâchant.

Ce fut une bonne expérience de pouvoir assimiler la collection de problèmes comme mes propres connaissances sans compter sur les nuages sombres lors de l'obtention de la qualification.

Dans cet article, je vais suivre ce que j'ai trouvé intéressant quelle que soit la fréquence.

Stream Pipeline

L'API Stream est inévitable lors de l'examen Gold, mais elle dispose d'un mécanisme qui rend le déroulement des opérations apparemment trompeur. Cependant, une fois que vous l'aurez compris, je pense que ce sera utile pour les problèmes liés à Stream.

Un exemple est présenté ci-dessous.

example.java

public class example{
  public static void main(String[] args){
    Stream<String> fruit = Stream.of("banana", "grape", "orange","apple");
      .filter(s -> s.length() > 5)
      .peek(System.out::print)
      .map(String::toUpperCase)
      .peek(System.out::print);
    long l = fruit.count();
  }
}

Etant donné que le décompte des opérations de terminaison est montré, l'opération intermédiaire définie dans fruit est exécutée avec un retard. Alors, comment chaque élément du Stream est-il traité?

Au début de l'apprentissage, j'ai imaginé le flux suivant.

Autrement dit, je pensais que tous les éléments seraient vérifiés pour chaque opération intermédiaire. Si cela est correct, la sortie doit être «bananaorangeBANANA ORANGE». À première vue, cela semble correct.

Cependant, en réalité, c'était différent, ** les éléments définis dans Stream.of ont été manipulés un par un jusqu'à la fin, puis l'élément suivant a été déplacé vers **. En d'autres termes, l'ordre d'exécution de peek est ② → ④ → ⑦ → ⑨, donc la sortie est bananaBANANA orange ORANGE.

Vous n'avez peut-être pas besoin d'en être conscient lorsque vous utilisez réellement Stream, mais une fois que vous comprenez le déroulement de l'ordre d'opération, vous pouvez le démêler sans bouger même si l'apparence change un peu. Il convient de noter que s'il n'y a pas de décompte d'opérations de fin, rien n'est sorti car Stream n'est qu'une opération intermédiaire. Il est souvent demandé que l'opération de terminaison soit correctement décrite. (Je pense qu'il y avait beaucoup d'enchevêtrements facultatifs)

multi-catch et try-with-resources

Il y a quelques questions dans les domaines des exceptions et des assertions, mais je ne veux pas les manquer car elles sont plus faciles à retenir que les autres éléments. C'est un endroit (je pense) qui ne peut être évité même dans la pratique, donc je pense que c'est un domaine où l'apprentissage peut certainement être utilisé.

Premièrement, la multi-capture introduite dans SE7. Il s'agit d'une syntaxe qui vous permet de décrire collectivement le traitement des exceptions en le séparant par "|". Il y a deux points à noter ici.

** 1. Les exceptions dans la relation d'héritage (polymorphe) ne peuvent pas être répertoriées ensemble ** Par exemple, écrire ʻIOException et ʻException ensemble entraînera une erreur de compilation.

** 2. Une variable ** Même s'il existe de nombreuses exceptions à répertorier ensemble, il n'y a qu'une seule variable à la fin. Si vous en écrivez plusieurs, une erreur de compilation se produira.

catch(IOException e1 | InterruptedException e2){} //Erreur de compilation

De plus, s'il existe plusieurs clauses catch, il n'est pas possible d'écrire une exception de sous-classe après une exception de superclasse (car elle est interceptée au début et ne peut pas être inspectée).

Ensuite, il s'agit également d'une instruction try-with-resource introduite dans SE7. Il s'agit d'une syntaxe qui fournit un mécanisme qui peut fermer automatiquement ce qui était décrit dans la clause finally (par exemple, FileReader) avant SE 6.

Le mécanisme est appliqué en définissant la ressource dans la parenthèse arrière de try, comme indiqué ci-dessous.

try(FileReader fr = new FileReader("sample1.txt");
  FileWriter fw = new FileWriter("sample2.txt")){
  //Ressources de lecture et d'écriture
}catch(IOException e){
  //Gestion des exceptions
}

Ici, ** l'ordre de fermeture est l'inverse de l'ordre défini **. De plus, si la ressource n'implémente pas ʻAutoClosable ou Closable, comme lorsque la ressource est définie indépendamment, une erreur de compilation se produira. Les classes couramment utilisées dans les E / S peuvent être exécutées sans problème car elles implémentent ʻAutoClosable.

ForkJoinPool

ForkJoinPool définit trois types de méthodes d'exécution. Parmi ceux-ci, uniquement invoquer synchronise le traitement.

De plus, dans le cas de l'asynchrone, la méthode d'exécution change en fonction de la valeur de retour. Il est résumé ci-dessous.

En regardant la méthode que vous utilisez, si elle est invoquée, le résultat sera unique, sinon il ne sera pas défini.

Scrollable ResultSet

ResultSet dans JDBC vous permet de définir un mécanisme qui vous permet de déplacer le curseur librement.

//Définition de l'instruction pour l'utilisation d'un ResultSet déroulant
Statement createStatement(int resultType, int resultSetConcurrency) throws SQLException

• Il existe des pilotes qui ne peuvent pas être défilés par défaut et des pilotes qui peuvent être défilés. Certains éléments ne peuvent pas être non défilables et seront ignorés si la constante ne peut pas défiler. (Pas une erreur de compilation)

Les constantes qui peuvent être définies pour les premier et deuxième arguments sont définies dans l'interface ResultSet.

--Premier argument --TYPE_FORWARD_ONLY: avancer uniquement --TYPE_SCROLL_INSENSITIVE: Défilement, DB non reflété --TYPE_SCROLL_SENSITIVE: Scrollable, DB reflétée --Deuxième argument --CONCUR_READ_ONLY: ne peut pas être mis à jour ResultSet --CONCUR_UPDATABLE: ensemble de résultats pouvant être mis à jour

Deux sont nécessaires lors de la prise d'arguments, donc en écrire un seul entraînera une erreur de compilation.

Dans le cas d'un ResultSet modifiable, si la clé primaire est définie dans la table cible, chaque opération d'insertion, de mise à jour et de suppression est possible, mais la méthode ** ʻinsertRow / ʻupdateRow / deleteRow doit être appelée. S'il n'est pas réellement reflété dans le DB **.

en conclusion

Comparé à Silver, je pense que Gold devait avoir une mémorisation et une compréhension approfondies. C'était souvent trop et déprimant. Cependant, comme c'est bon à mon rythme, je pense que c'est une qualification qui peut être suffisamment acquise si on prend le temps de travailler dessus. Les frais d'examen sont un goulot d'étranglement ... </ font>