DOCSLIB.ORG

Multi-Project Multi-Product Openjdk Builder

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Multi-Project Multi-Product Openjdk Builder Multi-project multi-product OpenJDK builder ● Name matters ● Projects matter ● Storage matters ● Not selling product, sharing reasons Multi-project multi-product OpenJDK builder ● we have infrastructure ● ready to open ● ready to deploy ● not as competitor, ● as complement. ● Now stalled, waiting for this meeting ● in its best, it can be joined Name matters ● build #xyz is good...but... but not here ● we took Fedoras' Name-Version-Release (.Architecture) (NVR/NVRA) – n-v-r.a ● dashes from behind, still surprisingly... – evolved, proven – nicely readable – works just fine – date is very bad idea Name matters Name matters Name matters ● N – java-X-openjdk ● quite fedora bound ● probably not best for adopt openjdk ● V – tag ● the only thing going through all projects merging from main forest ● R – repo (stripped from common parts) – practically anything ● number of changesets since last tag ● 0 is release candidate – keywords ● static, slowdebug, fastdebug, zero, openj9 ● A – src or real platform (i686, x86_64, aarch64, ppc64le...) Why is naming so important and so hard? ● OpenJDKs is not only (now) jdk9 and/or jdk8 – the projects (EA of EA/tech preview) have even same importance as stable releases ● jigsaw ● shenandoah ● ports – all those were/are as much awaited as main jdk – when project is built, it nothing more then jdk of version it is based on with additional features ● multiple projects(repos) built into single products(jdks of specific version) ● new release system might change this a bit ● multiple repos to provide single product and we (like we right here) *care* about *all* forests (?) ● mayor jdk must be clear from name project to product mapping ● product == java compliant => – java-9-openjdk, java-1.8.0-openjdk, java-1.7.0-openjdk ● project == repo => – icedtea7-forest, icedtea7-2.6forest, jdk7u => java-1.7.0-oenjdk – jdk8u, jdk8u-aarch64, jdk8u-aarch64-shenandoah, jdk8u-shenandoah, jdk8u-jigsaw => java- 1.8.0-openjdk – jdk9, jdk9u, jdk9u-shenandoah, jdk9u-jigsaw => java-9-openjdk ... – iced tea really should be considered in – same for icedtea-web – windows github repos? – forest approval process ● name must clearly show the identification of project it is from pull ● forests will be with us for some time – To add forest must be automated ● Any user can add own forest – The whole setup will probably need management anyway ● Keep single developer usecase in mind ● pull on forest is far from being straight-forward ● multi-project multi-product environment is not making it easier ● hg incoming on all trees is decision point for pull in case of pooling – Git alternative? ● official builder can be (should be) triggered by hook pull ● we currently semi-pool, so – granularity is often more then one changeset – we use hooks in case of internal builds ● one patch can cover more trees ● jenkin's url build-now timeout serves well here ● this fact (more changesets in single patch) enforces the observer logic anyway ● hg incoming+hg pull+hg update later – all three provides very important logs ● Easy to generate “the patch” – all mentioned logic have easy maintenance ● shared script about 100lines over all of this – ignoring windows git repos :( src snapshot ● pull can bring both release candidate and testing version(s) – more variants are build from same revision ● More src snapshots o changeset: 2000:c6c15bd2fa20 | tag: tip ● ☠☠☠☠ merge ☠☠☠☠ | o changeset: 1999:af980289e0df – |\ tag: jdk8u162-b02 can bring in even more | | | o changeset: 1998:01c1e35a6ade candidates -> | | | o changeset: 1997:7a25d12cd94f | | tag: jdk8u152-b16 – Should bring in also releases | o changeset: 1996:d680e12deacb | |\ tag: jdk8u152-b15 ● If not yet processed in past .... - tip is u162-b02+X changeset, however - u152-b16+1 changesets is there too (01c1e35a6ade) - our top one is 4 src snapshots from one pull - not most easy task, especially in forests - may not be applicable on low-tagging rate projects src snapshot ● we know – what to pull – when to pull – what jdk is an result – we already know some artifacts ● hg incoming, pull and update logs – other important artifacts are ● logs of individual trees ● heads of trees ● combined patch (difference from old heads) [webrev?] – because more changesets in patch – enough info to drop .hg (120mb->60mb) ● logs &comp should be both in snapshot tarball and jenkions artifacts ● we know all targets of snapshot (fastdebug, slowdebug, zero, openj9...) – multiplying of src snapshots ● we guess already name, but what to do with it? src snapshot ● N – java-X-openjdk ● quite fedora bound – probably not best for adopt openjdk ● V – tag ● the only thing going through all projects merging from main forest ● R – repo (stripped from common parts) – practically anything ● number of changesets since last tag ● 0 is release candidate – keywords ● static, slowdebug, fastdebug, zero, openj9 ● A – src – src.tarxz ● tarxz is to keep the dots adapted with .rpm, .zip and other src snapshot ● pooling x hooks x other triggers ● remember – pull is per project – build per product ● ok...project might affect build ● Surprisingly complicated setup file ● Build 165 and up – External scheduler is checking changes, and lunches job only if chaged – unstable build=changed ● 164 and down. Normal pooling – There is row of 50 stable builds – Not much interesting view... src snapshot ● src snapshot (and logs) is jenkins artifact ● src snapshot is arch-independent operation – implementation have nothing to do with following builds – still the src snapshot must be tight with builds ● jenkins is really bad in this ● even worse with multi-project multi-product environment ● upload to well organized shared space – current awesome front-page is subset of web page reading from this storage src+builds(+logs) shared storage fake-koji ● inspired by fedora koji – Real koji doesn’t have products, projects and variants ● well readable for humans ● well readable for machines – jenkins koji-scm plugin - https://github.com/judovana/jenkins-scm-koji-plugin ● grouping product->project ● grouping project->product ● variants (slowdebug, fastdebug, zero, openj9...) ● listing(s) – with good listing and grouping and jenkins binding, custom search not necessary Fake koji human readable part (1) ←its not nice, it really needs front-page :) ←listing products ←Listing product’s projects ← Latest build of project first ● With variants ← Product→Project→archs+variants→ bits – But missing: ● Stable versions Fake koji human readable part (2) – project’s Full listing with variants → ● Even with variants focused listing ● And failed (partial) builds – Still missing: ● Stable versions Fake koji human readable part transiting with machine readable part ● Http directory listing – All containing, reducible full text search – Grouping builds, srcs and logs in well organized form Fake koji machine readable part ● Queries – Curl api is great, but might soon lack readability ● Json replies are not well readable from bash – Last N builds of product – Last N builds of project * – Last N stable builds of product – Last N stable builds of project * – Give me failed build(s) – Giive me passed builds on some arch only – product’s projects * – Architectures of build – Variants of build ** – Logs of build – Files of builds – Status ● Finished (since all primary archs pass) ● Failed (since first primary arch fail) ● Running (since src upload to last secondary arch) – …. ● We have xmlrpc to be compatible with original koji * not done, not missing for now, still nice to have ** workarounded in current implementation Build ● Once we have – Source snapshot ● With all info about the change – Proper name ● Major jdk and project-specific stuff – Variants and architectures description – Place where to get it all – Place where to upload it – The build itself is easy ● Reporting is not Build ● How to build matters a LOT – Forest contributors must be able to contribute to the build part ● If they don’t care, project get disabled ● Have `Is release “button”` – Build part must be simple and unified ● Build differs only between major JDK releases – But small changes might change form project to project – Variants affects build in minor way, but the result is absolutely different ● Must be reproducible – Final configure_call+make_call+whatever_else_call is generated and stored as build artifact as important a logs and bits – VM image should be accessible ● If possible, build with full bootstrap ● Src.tarxz → ARCH.tarxz – Build and build call is uploaded to its place in fake-koji ● Surprisingly easy to achieve in our proof of concept environment Build ● Logs of build matters a LOT – Forest contributors must be able to receive failed build reports ● Not only contributors ● subscribing for projects? ● Logs are big – Separated x joined stdout/err can help – Simple grepping of fail, error or warning with reasonable -A -B – Html coloring of above, is helping extraordinary well – Access to full build log x reproducible build ● Repeated failures – Once the logs are truncated to shard of its size while kept useful – It is easy to make a pattern matching pinpointing know failures ● Beta now at our side ● All the logs are uploaded to its place in fake koji (and kept as jenkins artifact as well) ● Still surprisingly easy to achieve in our proof of concept environment Primary and secondary architectures ● Build is running since src upload ● Build is failed, when one of primary architectures fails ● Build is finished, when all primary architectures are finished ● Build is unstable when some secondary architecture
Load more

Recommended publications
  • It's Always Sunny with Openj9
    It’s always sunny with OpenJ9 Dan Heidinga, Eclipse OpenJ9 Project Lead VM Architect, IBM Runtimes @danheidinga DanHeidinga 2 https://upload.wikimedia.org/wikipedia/commons/9/98/Storm_clouds.jpg cjohnson7 from Rochester, Minnesota / CC BY (https://creativecommons.org/licenses/by/2.0) My Day Job http://docs.oracle.com/javase/8/docs/index.html Eclipse OpenJ9 Created Sept 2017 http://www.eclipse.org/openj9 https://github.com/eclipse/openj9 Dual License: Eclipse Public License v2.0 Apache 2.0 Users and contributors very welcome https://github.com/eclipse/openj9/blob/master/CO NTRIBUTING.md 6 A JVM for the cloud 7 Built with the Class Libraries you know and love JDK JDK JDK JDK 8 11 14 next Single source stream at OpenJ9 No (LTS) JDK left behind! 8 Right, the cloud 9 Cloud requirements on Java ▪ Fast startup –Faster scaling for increased demand ▪ Small footprint –Improves density on servers –Improves cost for applications ▪ Quick / immediate rampup –GB/hr is key, if you run for less time you pay less money 10 OpenJ9 helps… … containers out of the box 11 Automatically detect if running in a container ▪ Based on the container limits: – Tune the GC Heap – Limit GC & active JIT threads – Constrain Runtime.availableProcessors() to cgroup quotas – Out of the box idle tuning 12 Avoid rebuilding containers just to adjust heap size ▪ -XX:InitialRAMPercentage=N – Set initial heap size as a percentage of total memory ▪ -XX:MaxRAMPercentage=N – Set maximum heap size as a percentage of total memory ▪ Running in containers with set memory limits? – OpenJ9
    [Show full text]
  • Oracle Utilities Testing Accelerator Licensing Information User Manual Release 6.0.0.3.0 F35952-01
    Oracle Utilities Testing Accelerator Licensing Information User Manual Release 6.0.0.3.0 F35952-01 June 2021 Oracle Utilities Testing Accelerator Licensing Information User Manual, Release 6.0.0.3.0 Copyright © 2019, 2021 Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation"
    [Show full text]
  • Current State of EA and Its Uses in The
    Jfokus 2020 Current state of EA and Charlie Gracie Java Engineering Group at Microsoft its uses in the JVM Overview • Escape Analysis and Consuming Optimizations • Current State of Escape Analysis in JVM JITs • Escape Analysis and Allocation Elimination in Practice • Stack allocation 2 Escape Analysis and Consuming Optimizations 3 What is Escape Analysis? • Escape Analysis is a method for determining the dynamic scope of objects -- where in the program an object can be accessed. • Escape Analysis determines all the places where an object can be stored and whether the lifetime of the object can be proven to be restricted only to the current method and/or thread. 4 https://en.wikipedia.org/wiki/Escape_analysis Partial Escape Analysis • A variant of Escape Analysis which tracks object lifetime along different control flow paths of a method. • An object can be marked as not escaping along one path even though it escapes along a different path. 5 https://en.wikipedia.org/wiki/Escape_analysis EA Consuming Optimizations 1. Monitor elision • If an object does not escape the current method or thread, then operations can be performed on this object without synchronization 2. Stack allocation • If an object does not escape the current method, it may be allocated in stack memory instead of heap memory 3. Scalar replacement • Improvement to (2) by breaking an object up into its scalar parts which are just stored as locals 6 Current State of Escape Analysis in JVM JITs 7 HotSpot C2 EA and optimizations • Flow-insensitive1 implementation based on the
    [Show full text]
  • Master Your Java Applications in Kubernetes
    Master your Java applications in 03.2019 Kubernetes Andy Moncsek 1 Ó Adcubum AG About me § Andy Moncsek à Architect § Creator or… see my Github § Likes coffee & HiFi & cameras § Twitter: @AndyAHCP 2 Ó Adcubum AG Agenda § Choose your (Java) Runtime § Build & execute your applications § Create your image § Run your applications in Kubernetes § Final thoughts 3 Ó Adcubum AG Typical issues You plan to move to Kubernetes? § How to integrate? § Slow startup? § No more capacity? 4 Ó Adcubum AG Choose your (Java) Runtime 5 Ó Adcubum AG Choose your (Java) Runtime § Support? § License & LTS? § Container aware? § since Java SE 8u131 & JDK 9 § changes in JDK 8u191 & JDK 10 6 Ó Adcubum AG Many (possible) options, out there Choose your (Java) Runtime + Substrate VM Hotspot + C1 & C2 Jit + Hotspot 7 Ó Adcubum AG OpenJ9 Choose your (Java) Runtime § Contributed by IBM to the Eclipse Foundation in 2017 § It replaces HotSpot JVM in the OpenJDK build § Small memory footprint & fast startup § Optimization for virtualized environments 8 Ó Adcubum AG GraalVM Choose your (Java) Runtime § Universal VM running various languages § Removes isolation & enables interoperability between programming languages § Can be integrated in various native & managed env. (OpenJDK, Node.js, OracleDB, MySQL,…) § The Graal compiler § as JIT compiler since Java 10 § as AOT compiler since Java 9 9 Ó Adcubum AG Relation to Containers / Kubernetes? Choose your (Java) Runtime § JVM needs to be aware of containers (CPU & memory) § Small memory/image footprint (run & deploy many containers)
    [Show full text]
  • Guiding Inlining Decisions Using Post-Inlining Transformations Erick
    Guiding Inlining Decisions Using Post-Inlining Transformations by Erick Eduardo Ochoa A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science Department of Computing Science University of Alberta c Erick Eduardo Ochoa, 2019 Abstract Inlining strategies in just-in-time (JIT) compilers have relied on a mixture of heuristics and frequency information to discriminate between inlining candi- dates. Even though nested inlining is the norm in JIT compilers, modeling inlining as a variation of the greedy knapsack algorithm provides sub-optimal solutions. Recent advancements by Craik et al. [16] allow for solutions for the nested inlining problem, however, they require grading inlining candidates based on an abstract notion of \benefit". In this thesis, we define this abstract notion of \benefit” through the use of static analysis and frequency information. The choice of using static analysis instead of heuristics has consequences on the guarantees that an inlining strategy provides and on the compilation time incurred by the compiler. We show that our proposed static analysis is compa- rable to heuristics in terms of compilation time, memory resources used during compilation, and impact on run time. While our proposed inlining strategy increased run time by 4% compared to the default inlining strategies found in the OpenJ9 Java Virtual Machine (JVM), our inlining strategy allows compiler engineers to fine tune the abstract notion of \benefit” and provides human readable reports that show why inlining decisions were taken. The number of proposed inlining plans that differ between the heuristics and the static analyses is small, however, it provides a lower bound for how more powerful static analyses may improve inlining in the future.
    [Show full text]
  • 15 Ways to Optimize Spring Boot for the Cloud ☁️
    15 Ways to Optimize Spring Boot for the Cloud ☁️ Billy Korando - @BillyKorando Developer Advocate - IBM 17 Ways to Optimize Spring Boot for the Cloud ☁️ Billy Korando - @BillyKorando Developer Advocate - IBM Keep Current http://ibm.biz/javanewsletter https://cloud.ibm.com/docs/java ️ ️️ ️ ️ Optimization Factors ️ Observability Improvement ️ ️ Resiliency EfficiencyEfficiency ️️ ️ ️️ Scalability Security ️ Sources/Additional Reading 1. You Don’t Have to Do Microservices to be on the Cloud ORDERS ADDRESSES FULFILLMENT ITEMS ORDER USER HISTORY The Distributed Monolith 1. You Don’t Have to Do Microservices to be on the Cloud Challenges with Microservices: Distributed Systems Have Emerging Problems Require Organizational Change Deep Understanding of DDD and Your Domain 1. You Don’t Have to Do Microservices to be on the Cloud With Monoliths You Can: Use Spring Boot Can be CI/CD 2. Use the Services Provided by Your Cloud Platform ☁️ 2. Use the Services Provided by Your Cloud Platform ☁️ 3. Spring Cloud Sleuth for Request Tracing and Correlation 3. Spring Cloud Sleuth for Request Tracing and Correlation <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency> 3. Spring Cloud Sleuth for Request Tracing and Correlation Trace ID Span ID service1,2485ec27856c56f4,2485ec27856c56f4 service2,2485ec27856c56f4,9aa10ee6fbde75fa service3,2485ec27856c56f4,1210be13194bfe5 service2,2485ec27856c56f4,9aa10ee6fbde75fa service4,2485ec27856c56f4,1b1845262ffba49d service2,2485ec27856c56f4,9aa10ee6fbde75fa service1,2485ec27856c56f4,2485ec27856c56f4 3. Spring Cloud Sleuth for Request Tracing and Correlation Time well spent Time poorly spent Project Dapper 4.
    [Show full text]
  • Red Hat Single Sign-On 7.4 Red Hat Single Sign-On for Openshift on Eclipse Openj9
    Red Hat Single Sign-On 7.4 Red Hat Single Sign-On for OpenShift on Eclipse OpenJ9 For use with Red Hat Single Sign-On 7.4 Last Updated: 2021-09-09 Red Hat Single Sign-On 7.4 Red Hat Single Sign-On for OpenShift on Eclipse OpenJ9 For use with Red Hat Single Sign-On 7.4 Legal Notice Copyright © 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
    [Show full text]
  • Openj9 a Lean, Mean Java Virtual Machine
    OpenJ9 a Lean, Mean Java Virtual Machine Billy Korando Developer Advocate - IBM @BillyKorando [email protected] https://billykorando.com/category/openj9/ https://github.com/wkorando/openj9-batch-processor @BillyKorando Subscribe to the Java Newsletter https://developer.ibm.com/newsletters/java/ For your Spring & JakartaEE needs https://cloud.ibm.com/docs/java @BillyKorando Ideal Demand Demand Capacity Time @BillyKorando Real World Demand Demand Capacity Time @BillyKorando Evolution of Running Applications Increasing flexibility and granularity Bare Metal @BillyKorandoTime Meeting Demand - Bare Metal Demand Capacity Time @BillyKorando Evolution of Running Applications VM VM VM Virtual Machines Increasing flexibility and granularity Bare Metal @BillyKorandoTime Meeting Demand - VMs Demand Capacity Time @BillyKorando Evolution of Running Applications VM VM Containers Managed on Cloud VM Virtual Machines Increasing flexibility and granularity Bare Metal @BillyKorandoTime Meeting Demand - Containers/Cloud Demand Capacity Time @BillyKorando Benefits of Running in the Cloud ● Rapidly expand/reduce capacity in response to demand ● Reduced capital costs ● Reduced operations costs @BillyKorando The Cloud Gives Us Compute on Demand @BillyKorando The Demand Is Metered @BillyKorando -Xmx = @BillyKorando Traditional Profile Lag Peak Resource use Throughput Capacity Time @BillyKorando Meeting Demand - Containers/Cloud Demand Capacity @BillyKorandoTime Demands of Running in the Cloud ● Fast startup ● Minimal memory footprint ● Minimal CPU usage ● Small
    [Show full text]
  • Enabling RISC-V Support on Maxinevm
    The University of Manchester Research Enabling RISC-V support on MaxineVM Document Version Accepted author manuscript Link to publication record in Manchester Research Explorer Citation for published version (APA): Zakkak, F., Fumero, J., & Kotselidis, C. (2018). Enabling RISC-V support on MaxineVM. Paper presented at RISC- V Workshop 2018, . Citing this paper Please note that where the full-text provided on Manchester Research Explorer is the Author Accepted Manuscript or Proof version this may differ from the final Published version. If citing, it is advised that you check and use the publisher's definitive version. General rights Copyright and moral rights for the publications made accessible in the Research Explorer are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Takedown policy If you believe that this document breaches copyright please refer to the University of Manchester’s Takedown Procedures [http://man.ac.uk/04Y6Bo] or contact [email protected] providing relevant details, so we can investigate your claim. Download date:25. Sep. 2021 Enabling RISC-V support on MaxineVM Foivos S. Zakkak Juan Fumero Christos Kotselidis The University of Manchester The University of Manchester The University of Manchester United Kingdom, M13 9PL United Kingdom, M13 9PL United Kingdom, M13 9PL [email protected] [email protected] [email protected] ABSTRACT range from the standard benchmark suites, to applications run- In this paper we outline the current state of language Virtual Ma- ning on top of Big Data frameworks, including domain specific chines (VMs) running on RISC-V as well as our initiatives in aug- applications and implementations of managed languages.
    [Show full text]
  • Red Hat Data Grid for Openshift
    Red Hat Data Grid 7.3 Red Hat Data Grid for OpenShift Run Data Grid on OpenShift Last Updated: 2021-07-06 Red Hat Data Grid 7.3 Red Hat Data Grid for OpenShift Run Data Grid on OpenShift Legal Notice Copyright © 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
    [Show full text]
  • IBM Is Increasingly Moving Our Java Innovation Into Community-Empowering Forums
    Please note Copyright © 2018 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here. IBM and the IBM logo are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml. Oracle and Java are registered trademarks of Oracle and/or its affiliates. ‘Eclipse’ is a trademark of Eclipse Foundation, Inc. Other names and logos depicted in this presentation may be trademarks of their respective owners.
    [Show full text]
  • Liberty Quarterly Update 19.0.0.7-19.0.0.9
    Liberty Quarterly Update Liberty Quarterly Update 19.0.0.7-19.0.0.9 Alasdair Nottingham STSM @nottycode WebSphere Proof of Technology Agenda • Part 1: Liberty value and evolution • Part 2: Technical deep-dive: what’s new this quarter • Part 2a: Jakarta EE & Eclipse MicroProfile – Kevin Sutter • Part 2c: Liberty Performance Update – Vijay Sundaresan • Part 5: Q&A • For complete WAS Update presentation, see http://ibm.biz/WebSphereUpdate Liberty Quarterly Update Liberty Quarterly Update Liberty value and evolution Why would I want it? WebSphere Proof of Technology Why are customers choosing Liberty? • “We want to reduce costs, simplify, and become cloud ready” • Development efficiencies • Flexible license options – even with collective management • Rapid provisioning – small disk size – zip packages – remove the Ops team from the app update flow • Lower running costs – dynamic config – zero migration – self-tuning thread pools Liberty Quarterly Update Fit-for-purpose server • You control which features are loaded into each server instance <feature>servlet<feature>jsf-2.3</feature>-4.0</feature> jsp-2.3 jsf-2.3 Java EE servlet-4.0 http-1.1 appmgr Kernel Liberty Quarterly Update Liberty in Docker IBM Cloud Kubernetes Service app and config Azure Kubernetes Service Hosted Google Kubernetes Engine + Cloud Amazon Elastic Kubernetes Service liberty and java Jelastic = + os config portable container Red Hat Open Shift Container Platform + Private Cloud Pivotal Kubernetes Service Pivotal Cloud Foundry FROM dockeropen-liberty ADD myapp.war /config/dropins/myapp.war
    [Show full text]