Monthly Archives: October 2018

[2018 oracle code] psa java is still free

Posted on by
Reply

Public Service Announcement: Java is Still Free

Speaker: Trisha Gee (Java Community), Simon Maple  (LJC – London Java Community), Roman Kennke (Red Hat) (Didn’t catch his name) Simon Ritter (Azul), Tim Ellison (IBM) + Moderated by Steve Poole (IBM),

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

This talk is mainly Q&A. The high points.

  • What do the recent changes mean to us?
    • Simon R – 6 month release cycle/faster releases/new features more quickly. Oracle said impractical to provided long term support for all releases. Strategy similar to what Ubuntu does; one release every three years is LTS and others are feature releases. JDK 11 under different license. If download from oracle.com, Oracle Technology License Agreement – can use in dev/test/demos free. Must subscribe to use in Prod. If download from openjdk, can use completely free – GPL v2. OpenJDK has updates for 6 months. Open JDK source code product is what everyone uses to build. Oracle will contribute changes to Open JDK for 6 months. This means Adopt Open JDK will need someone to backport fixes from later releases to add long term support. Someone (probably RedHat) will have to step up to lead Open JDK project for JDK 8 and 11 to do the work of backporting fixes. Azul has Zulu which is Open JDK build. Have community version which is free and a commercial version where provide support for less $ than Oracle.
    • Tim – At IBM, Java is an enabler. IBM and customers have a lot invested in Java. Goal is not to make money from Java directly. Money comes from higher level products that run on Java. Goal/working on contributing back to OpenJDK and Eclipse community. Also offer a support contract. Work for hire. IBM represents problem you have in Java community.
  • IBM will contribute to OpenJDK if find bug fixes. Will this make branches differ?
    • Tim – for 6 months Oracle doing in public OpenJDK. After that, will be an internal fork from Oracle. The public OpenJDK one will be under control of the stewards of that project. There is a risk that the fixes are different. [there’s always been that risk for IBM JDK, no?]
    • Simon R – Oracle will upstream fixes into OpenJDK 11 until JDK 12 comes out. After that, not as easy as just back porting JDK 12 fixes. Since there are new features added, need to determine what is a bug fix or security fix that needs to be back ported. Further, features get removed (ex: CORBA module). Therefore there are no bug fixes/security patches for that feature to back port.
    • Roman – Took over OpenJDK 6 and then OpenJDK 7 updates after Oracle stepped back. Plan to do the same for OpenJDK 8 and 11 when that happens. RedHat plans to support OpenJDK 8 until 2023.
    • Simon R – Private group behind OpenJDK for major vendors that contribute. This is where security issues get discussed so patches can be made available. It’s not just Oracle. Covers versions as long as anyone is supporting.
  • Has Oracle committed to giving vulnerability group opportunity to back port before CVE released publicly?
    • Simon R – Yes. They are discussed earlier
  • Scott Selikoff asked how similar OpenJDK and Oracle JDK are at release?
    • Trisha – Aiming for it to be the same binary. Not literally the same because the license is in the binary.
    • Roman – Built from same sources
    • Simon R – Functionally the same
    • Trisha – If a bug is in one, it should be in both
    • SImon M – unlocking commercial features doesn’t make sense in OpenJDK, but does in Oracle JDK
  • Scott Selikoff asked if recommend using a non-LTS release?
    • Trisha – “it depends”. Large enterprises will go with LTS. Some people will be happy to use new features as they come in. Stable enough to use in prod. Non-banks may be happy to use.
    • Simon R – Java 13 and 15 are MTS (medium term support). Commercial decision on how long something supported
    • Trisha – LTS and updates are not the same thing. In past, were getting updates but not support
  • Is JDK license included in Oracle product
    • Simon R – ask Oracle
    • Trisha – thinks comes with product
  • If on Zing JDK 8 now and willing to upgrade once in next two years, what/when go?
    • Simon R – Following same LTS strategy as Oracle for Zing. Use Zulu/Red Hat/AdoptOpenJDK as alternative to Oracle JDK
  • What are ramifications of license period lapsing in internet sparse location.
    • Tim – ask Oracle. Wouldn’t stop working, but ask Oracle about licensing.
  • Why call OpenJDK 11 LTS if only get support for 6 months. What are plans for CVEs after that 6 month period. Using a CMS requires supported JDK.
    • Roman – RedHat supporting JDK 11 for many years. OpenJDK patches still free.
    • Tim – cost depends on where you get JDK from. Oracle created 3 year LTS concept. Vendors stepped up to align.
    • Simon M – LJC (London Java Community) and many companies using Adopt OpenJDK platform turned into build engine to make OpenJDK binaries available to community. Aiming for 4 years for LTS releases. Support people typically buy covers support and security. Support contracts gets vendor commitment to fix reported issues. Vs filing a bug and hoping it will happen. Most people care about CVEs not issues they specifically found.
    • Trisha – Oracle talking about Oracle releases OpenJDK. But not the only people to produce OpenJDK binary.
    • Simon M – Adopt OpenJDK supports more platforms than Oracle
    • Simon R – Difference between source code and binaries. Source code contains changes. Someone still needs to create the binaries. Aka vendors.
    • Roman – Trying to create OpenJDK binaries
  • Suppose Oracle makes small features to their branch. Do you see them doing that?
    • Trisha – that’s not how it works
    • Simon R – Oracle doing the opposite. Removing commercial features from Oracle JDK.
  • Will RHEL and WebSphere use LTS versions?
    • Roman – yes
    • Tim – Yes for IBM WebSphere
  • Thoughts on Mark R and running build with latest every 6 months?
    • Simon R – It’s about preparing for the future. Ideally you learn impact every 6 months.
    • Simon M – APIs can be removed. By testing on feature releases, better understanding in advance of how app could break.
    • Trisha – Changes need to make to app should still work on Java 8 so can make changes in app without having to upgrade
    • Simon M – jdeps tells you which APIs you are using that are marked for removal.
  • Will Open JDK and Oracle JDK version string to be exactly same?
    • Trisha – Yes. Version string under JEP.
  • Oracle committed to someone in a private meeting that will give at least 18 months lead time on removing documented features.
    • Simon R – very publicly stated one release (6 months) warning
    • Trisha – Stuff deprecated in 9 already gone in 11.
    • Simon M – Two people at Oracle gave conflicting info
    • Tim – Get them to sign it 🙂
  • Someone from Oracle said to ask him the ask Oracle stuff

My take: I wish this talk was better publicized. I also wish Oracle had done this so you could hear all the opinions at once. That said, a big thank you to IBM for setting this up!

[2018 oracle code one] evolutionary architecture in agile environment

Posted on by
Reply

Evolutionary architecture in agile environment

Speaker: Xavier Rene-Corail

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

“Conflicts”

  • Not that we don’t have a plan. We have a plan. But it can change
  • Emerging design – do have a high level design. Not chaos
  • Things change. There’s nothing that will not change. Make easy to change the things that will/might.
  • Prototype architecture. Working software over comprehensive documentation. Architects shouldn’t deliver paper docs

Software architecture is

  • “the important stuff (whatever that is)” – Ralph Johnson
  • finding internal *abiities
  • managing conflicting *abilities and determining which is most important

Agility is

  • ability to move quickly and easily – Oxford dictionary

Evolution of architectural styles

  • Monolith – not scalable, single point of failure
  • Layered – defacto standard for JEE apps
  • SOA – natively scalable, but cn turn into monolith
  • Microservices – now need orchestration
  • Severless – abstract more

Beware of

  • Dependency hell/service dependencies
  • Distributed transactions

General

  • Minimize coupling
  • Couple fro highly changing to infrequently changing
  • Ask users for feedback. Don’t overarchitect
  • Feature flags. Make safe to fail
  • Eat an elephant one bite at a time. Design that way too

Decide up front – programming languages and frameworks. These are difficult to change.

My take: Good session. My notes are “less good” because I was eating lunch during the design principles. So listening, but not blogging! 

[2018 oracle code one] hands on lab JNoSQL

Posted on by
Reply

Hands on Lab: Eclipse JNoSQL: One API to Many NoSQL Databases

Instructors: Leonardo Lima, Otavio Santana, Senior Software Engineer, Hillmer Chona, Patricia Uribe & Jonathan Vila Lopez

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

Lab URL: https://github.com/JNOSQL/oc1-hands-on-2018

Overview of NoSQL

  • No fixed data structure
  • not ACID
  • BASE -Basically Available, Soft State, Eventual consistency
  • Five types
    • key/value – Redis, Hazelcast, Couchbase
    • column family – Hbase, Cassandra
    • document – Couchbase, MongoDB, Riak
    • graph – Neo4J
    • multi-model – OrientDB, Couchbase
  • From most scalable/least complex to least scalable/most complex – Key/value, column family, document, graph

JNoSQL

  • First Jakarta EE specification
  • Mapping API – Artemis
    • Heavily based on annotation
    • “Query by” methods
    • Inject DocumentTemplate – has CRUD methods
  • Communication API – Diana
  • Trying to replicate JDBC/JPA for NoSQL
  • Traditionally, use different API for each NoSQL type
    • BaseDocument
    • Document
    • JsonObject
    • ODocument
  • DocumentEntity/Document – for all the types
  • Working on for 2 years
  • Almost up to 1.0 version
  • Configuration is one json file

My take: I like that they brought/shared their own wifi. Good overview at the beginning. I think I missed the point of the instructions at first. It felt too freeform. But then it made sense once they started explaining the code. So either it assumed knowledge or I thought we were doing something else. (I did get it to work; I just thought we were supposed to be doing something else.) Also, there was an instructor for each 1-2 attendees. Every time I went to do something (email, Slack, pull request), someone asked me if I needed help. I was waiting for Maven/Docker, not being idle! Also, not their fault, but the improvised lab room had sun blocking the screen. Overall, I enjoyed the lab. The second exercise clicked because I understood what we were doing!