An introduction to Java development kit 7
Notice bibliographique
Résumé
In 2011 the Java(tm) Development Kit 7 (or JDK 7) became generally available. JDK 7 is the latest step in the evolution of the Java SE platform. It offers Java developers functionality and performance improvements in several areas including new I/O APIs, concurrency utilities like the Fork/Join framework, new support for dynamically typed languages in the JVM, changes to modularity, and several changes to the language to improve application development. Earlier this year IBM released its own Java Virtual Machine with JDK 7 support for the x86, System P, and System Z platforms. IBM's JDK 7 also brought performance throughput improvements of up to 10% on transactional workloads, as well as significant improvements of up to 15% in startup performance and up to 15% in memory footprint for workloads running with IBM's WebSphere Application Server. The workshop educated participants to the new features on offer in JDK 7 and demonstrated their value to application developers. These features included: • JSR 334 or Project Coin: a collection of small changes to the Java language to improve developer productivity, including Strings in switch statements, better type inferencing for generic instance allocation, and multi-catch for improving exception handling. • JSR 166y which introduced a framework for Fork/Join parallelism • JSR 292 which introduced JVM support for calling dynamic languages • JSR 203 which introduced new I/O APIs for filesystems, socket I/O, and asynchronous I/O • enhancements to class loading implementation • Unicode 6.0 support and Locale enhancements The Java programming language was designed from the start with concurrency in mind. It offers a rich set of features for creating and managing threads of execution and primitives to allow synchronization among objects. While powerful and correct, these synchronization mechanisms do not always have good performance characteristics in the presence of many threads of execution. The workshop touched on some of the Java thread model and concurrency features available in Java prior to JDK 7, and explained the shortcomings of the object- level synchronization mechanisms as they pertain to scalability. The java/util/concurrent package was introduced in Java 5 under JSR-166 and supplemented the thread safety features already built into the Java language and runtime. It provided an alternative that promised to avoid many of the scaling problems inherent with Java's built-in synchronization. In particular, it offered many light-weight mechanisms that provided finer grain synchronization between objects, useful concurrent data structures, a task management and execution framework, and interfaces for locking and creating intelligent synchronizers. When used appropriately, these features allow Java applications to perform efficiently even in the presence of many interacting threads of execution. In JDK 7 the newest enhancement to aid with developing scalable Java programs is the Fork/Join framework. Fork/Join offers a set of utilities designed to make divide and conquer algorithms easy to parallelize. The framework uses a pool of threads which are assigned tasks created on the basis of the work that needs to be done; each task is broken down recursively into smaller tasks which could be executed either by the same thread that created the task or be stolen by some other thread that has no tasks to execute. The work stealing approach is underpinned by a deque data structure, which allows it to be relatively lightweight and consequently scale better. Professor Doug Lea, the main author and architect of the java/util/concurrent package, delivered a presentation that described the challenges involved in developing an efficient and scalable Java concurrency package, what powerful features are available in the java/util/concurrent package, and explored the new Fork/Join framework in JDK 7. The workshop stressed the importance of mastering and leveraging these features within concurrent applications in order to develop efficient, scalable applications that perform well on modern multi-core hardware. The purpose and applicability of each feature was discussed, as well as case studies with code examples where appropriate. JDK 7 introduced several new I/O APIs via JSR 203 (NIO.2): • a filesystem I/O API which allows a user to abstract the notion of a path or filesystem into Java objects belonging to those classes (Path and FileSystem respectively). Operations such as file copying, file change notification, symbolic links, directory traversal, and querying file attributes are handled easily by the API. • a socket channel API with support for multicast operations and improvements to socket management • an asynchronous I/O API for sockets and files Each of these APIs was discussed with relevant examples in this workshop. Another powerful new feature introduced in JDK 7 was the InvokeDynamic support in the JVM. This allows dynamically typed languages like Ruby and Python to be supported more efficiently in the JVM and is an important step in making a Java virtual machine an attractive runtime environment for those languages. For example, the JVM can offer garbage collection and just-in-time compilation benefits that have been developed for Java for years instead of requiring customized runtimes for each dynamic language. The workshop discussed some common use cases and how the new JVM support for InvokeDynamic opens up new possibilities for improved performance that were not possible in earlier releases of the JDK. It is often difficult for a programmer to get an accurate sense of how well their application scales or where the performance problems are. The workshop provided advice on how to measure the scalability of an application and the tell-tale signs that an application is not scaling. The IBM Monitoring and Diagnostics Tools for Java were demonstrated on real applications to show how they can be used to identify performance bottlenecks, contended locks, and other inhibitors to application scalability. Finally, the workshop concluded with a brief look ahead at some of the exciting features proposed for JDK 8.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,001 | 0,001 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,001 |
| Études des sciences et des technologies | 0,001 | 0,000 |
| Communication savante | 0,000 | 0,000 |
| Science ouverte | 0,001 | 0,000 |
| Intégrité de la recherche | 0,000 | 0,000 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».