[2018 oracle code one] monday keynote

Main menu:


Recent Posts


RSS Feed RSS - Posts

October 2018
« Sep    

Past Posts

Java/Java EE



[2018 oracle code one] monday keynote

October 22nd, 2018 by Jeanne Boyarsky

Monday keynote

For more blog posts, see The Oracle Code One table of contents

GitHub – Matthew McCullough

  • Project Skara – investigate alternative SCM and code review options – https://github.com/Project-Skara/jdk
  • Building a development community
    • Power of 1 – just do one thing
    • If everyone does, the global community makes progress
    • ”think small to accomplish more”
    • Java dominates
  • GitHub loves Java
    • Resque – redis
    • Webhooks  kestrel
    • Analytics – kafka
    • Hydro – all systems can be powered by same data structure – kafka – distributed log
    • Like Ruby but some downside. Each parallel process uses memory. Lack of strong typing, JVM dominates streaming ecosystem
  • Tools to support the effort
    • Looking to move some? All? JDK projects from Mercurial to Git
    • Showed a pull request, a comment and a static analysis check

Oracle (missed name)

Last year announced three commitments and met them

  • Provided closed source tech to Open JDK. Delivered Oracle JDK under Open JDK
  • Deliver enhancements and innovation more rapidly – 6 month release cadence
  • Enterprise long term support  $25/month/processor (or server) and $2.50/month/developer

Oracle (Mark Reinhold – Chief architect of Java platform)

  • Left behind slow release model [picture of elephant followed by cheetah for fast].
  • Worried about keeping up [picture of cat pounding keyboard]
  • Other languages release once or twice a year Java must to remain competetitive
  • Modules and internal APIs
    • Monoloithic. Removed some modules, but still large. Hard to clean up object graph. Originally needed Corba for hello world!
    • Can modularize existing app, but don’t have to. Might not be worth if for legacy app and that’s ok.
    • Three of high CVEs would have been prevented with modules. (That’s half of them.)
    • Prevents sun.* an .*internal.* packages. Treated as public because didn’t want to break. Modules prevent this problem by not exporting
    • JDK 9-11 will run internal APIs with warnings, but will no longer compile. Not sure when this will end, but will be Java 12 or later. In future release, will not run at al.
    • jdeps —jdk-internals my.jar – detects use of internal APIs. Even gives a suggested replacement where available
  • Finally started removing things from Java. Removed two modules in Java 11. Costly to maintain, source of several security vulnerabilities. Available elsewhere or irrelevant (CORBA). Also removed some APIs. Looked at use in the wild to confirm hardly anyone uses.
  • Deprecate for removal at least one release in advance and possibly more. This allows compier to warn you about it.
  • Release can contain anti-feature (feature removal)
  • Top misconceptions about new release model
    • Each release will be as disruptive – No. pace of innovation not changing. [agreed]
    • Non LTS releases are experimental – No.  its about support [agreed]
    • To remove an old feature, must be deprecated three years in advance. No. Just requires working build. [Mark said this last year. I don’t know anyone who built everything with Java 9/10]
    • Can ignore non-LTS releases if don’t migrate often. No. Should build each so ready for LTS [Mark said this last year. I don’t know anyone who built everything with Java 9/10]
  • I using Java 9+, update all your dependencies
  • Projects
    • Amber – right sizing language ceremony
      • Already have some type inference with generics and lambdas and var
      • Raw string literals in backslash. No need to backslash everything. Useful in regex!
      • This gives us multi line strings!
      • Java 12 preview feature – 99% done. Trying to get feedback. So need to turn on in order to use. But will be in Java 13 presumably
      • Switch case. Implies detecting if missed a case [this looks cool bt don’t understand how it works. Also a preview feature.
      • record – implies POJO – getter/setter/equal/hashcode. Can @Override to customize. Can’t add instance fields.
      • Pattern matching – avoid casts. Works well with switches
    • Loom  – continuations and fibers
      • Fiber – assgned to a thread when actually run it. Less resource intensive and less complicated than Threads.
      • Continuations – behind the scenes for implementing fibers
    • Panama – Foreign functional/data interface
      • JNI is intentionally slow
      • [I didn’t pay much attention to this as it isn’t a feature I use now]
    • Vahalla  – value types and specialized generics

Nevermore than 6 months/3 years of support. No. Depends on what community does [RedHat already spoke up]

My take: Fun fact. There’s a wifi hotspot in a box under the chair in front of me. Also Mark was awesome! Mark did have some “speaker note” issues which he handled well. I’m really excited about Amber. And I like that Mark did a live demo for Loom. Even though it didn’t work 100%, that’s ok because it’s very early software! Funny how the keynote was Mark and “opening acts for Mark”!

[2018 oracle code one] Better Software, Faster: Principles of Continuous Delivery and DevOps

October 22nd, 2018 by Jeanne Boyarsky

Better Software, Faster: Principles of Continuous Delivery and DevOps
Speaker: Bert Jan Schrijver

For more blog posts, see The Oracle Code One table of contents

Audience survey

  • Started with a survey on how long doing development. A lot of people 10-15 years. One guy over 30
  • Most people said they were doing CI. Many hands went down when asked if commit daily, if build fals and if fixed within ten minutes


  • Continuous Integration – integrate frequently.
  • Continuous Delivery – build and test so can release at any time
  • Continuous Deployment – every change goes through build/test pipeline and automatically goes to prod
  • DevOps – dev and ops engineers working together; jointly responsible


  • Automate (almost) everything – faster and more repeatable
  • Keep everything in version control
  • If it hurts, do it more often. Bring the pain forward. Get better at it that way
  • Build quality in.
  • “Done” means actually released. It needs to be in a build/deployed
  • Entire team is responsible for delivery process
  • Continuous improvement

Ingredients of CD

  • Culture & Organization
    • agile
    • build the right thing/build the thing right
    • support what you build
    • cross functional teams
    • leave room to experiment/fail
    • Fun approach: biggest screw up of week got to park closest to door
  • Design & Architecture
    • Version control
    • Modularity
    • Branching strategy – don’t have long lived branches
    • Database changes
    • Design for failure
    • Feature toggles
  • Build & Deploy
    • Pipelines – automated sequence of stages to deliver software from version control to your users
    • Types of pipelines: build and deployment – try to roll forward, not back
  • Test & Verification
    • Need a testing strategy
    • Test automation – can’t keep testing manually
    • Non functional requirements – when requirement not met, it makes the system non- functional
    • Security testing
    • Performance testing
    • Verify expected business value is met
  • Information & Reporting
    • Static code analysis
    • Traceable pipelines
    • Automatic change logs
    • Usage metrics – actual data to determine if data is used
    • Dynamic dashboards – let users adapt to what need
    • Data driven decisions – act on metrics
    • Fix problems before users notice

Continuous Delivery vs DevOps

  • The term DevOps came first
  • DevOps is about freedom and responsibility. It is about having empathy. Other teams are neighbors, not blockers.
  • Lack of CD excuses – regulation, not building website, too much legacy code, people not smart enough
  • Actual reasons for lack of CD – culture, architecture

Pattern or antipattern?

  • Continuous delivery without devops – pattern
  • Uniform build pipelines – both. Easy to change, but limits flexibility
  • Long pipelines – anti-pattern. People won’t wait. Feedback slow.
  • Obsess over test automation – pattern
  • Logging and metrics for ops only – anti-pattern
  • Obsess over feedback loops – pattern
  • Manual steps in a delivery pipeline – both. Good to have automated
  • Long living branches – anti-pattern
  • Dev/prod parity – anti-pattern
  • Design for failure – pattern
  • Tests don’t provide business value – anti-pattern. They prevent issues. A working system is definitely is business value.
  • Parallelized pipelines – Pattern
  • Continuous Delivery = Continuous Deployment – anti-pattern. For most companies, deploying to prod every sprint/two weeks is fine.
  • Automate database changes – pipeline
  • Testing NFR’s in the build pipeline – pattern

My take: This was an excellent review. Bert started by saying this was an intro. On some level, he’s right. Although I think this would be a drinking from a firehose thing if completely new. I’m at the point where having the review was a good way of settling in my mind why we do certain things. I missed a couple of the patterns/anti-pattern q & a but they were really good 

[2018 oracle code one] CD/DevOps Live Cooking Show

October 22nd, 2018 by Jeanne Boyarsky

Continuous Delivery/DevOps Live Cooking Show
Speaker: Michael Huttermann (had trouble making the umlat)

For more blog posts, see The Oracle Code One table of contents


  • Many definitions
  • Shared concepts, goals, tools

Early “DevOps” authors

  • Adam Smith
  • Edwards Demings
  • Eliyahu Moshe Goldratt


  • Short cycle time from workspace to deploy/cloud. Helps to create own definition; doesn’t require a tool
  • Create pipeline – start with a value stream map
  • Need tools to accelerate cycle time
  • Pipeline is a donut, not a tube
  • Glue together existing tools
  • Use quality gates
  • Implement high degree of automation. Doesn’t need to be 100% automation


  • Make up the workflow
  • ex: continuous build, dev build, release candidate build, general availability build
  • Showed about 20 different steps for a pipeline
  • DevOps – contains a number of concerns so no need to say DevSecOps specifically [I have DevSecOps in two of my talk titles here to emphasize security]

Demo (selected stages)

  • Showed in Jenkins a number of jobs each. Many had a green box/description before it. Like a group? [how do you do that?]
  • Commit and push
  • Showed sonarlint giving feedback on code before push.
  • Blue Ocean view in Jenkins to show pipeline
  • Showed quality gate failing in SonarQube

My take: I like that the first half was lecture and the second half was a demo. It was the longest pipeline I’ve seen to date.