Try CircleCI Orb

CircleCI is one of the popular Countinuous Integration and Continuous Delivery Platform. With CircleCI you can create your pipeline through code. You need to write your CI/CD job, steps and required commands in yml format as shown in sample configuration file below.

With the configuration file placed in your code repository under .circleci directory is automatically considered by CircleCI Cloud which reads this file and executes the jobs.

CircleCI Orb is nothing but a reusable package. In your CircleCI jobs, you may need to run similar commands repetitively, you can simply create an orb doing that comman thing and make your CircleCI configuration more readable and maintanable.

How to create orb?

Creating and sharing orb is made very simple by CircleCI team. You can simply use this template and follow the instructions given in README file that's it! To summarize you need to follow below steps which I followed to create a simple orb,

  • Sign up to CircleCI using GitHub
  • Install CircleCI CLI
  • Create CircleCI namespace for your organization (or user in case you don't have any organization) if not already,
    • circleci namespace create <name> --org-id <your-organization-id>
  • Initialize orb, choose to download template straight away
    • circleci orb init <your-orb-name>

  • Push your changes to GitHub repository
  • Check whether CircleCI pipelines running successfully or not. (ssh or lint checks may fail, you need to fix them and commit the changes until all steps succeed)
  • Create Release with v0.0.1 tag on GitHub
  • If everything is green on CircleCI, visit your orb registry to see your first orb!
For developing and testing orb, you can create a separate branch which will publish development version, you can finally merge this development branch into master when you have something to release to your public registry.


I have created a simple public orb called, notiforb which is kind of utility to send notification from your CircleCI pipeline to Google Chat (and more in future). To send message to Google Chat you can simply add following to your CircleCI configuration file. 

1. Import Orb into your CircleCI config.

  notiforb: akash-ccn/notiforb@0.0.1

2. Use command in Job step.

  - notiforb/gchat-notify:
      message: "Hi, this is CircleCI notifORB!"

Here multiple things happen behind the scene in gchat-notify command which is taken care inside orb. Now let's see what we have in orb code.

commands: Consider them as functions of programming where your pass parameters and execute some instructions.

jobs: Sample jobs to describe usage of orb in CircleCI registry.

examples : For showing how to use your orb.

executors : Environment where commands of orb can be executed. Depending on your orb you may or may not require executors.

@orb.yml : Contains description and display information.

scripts: Majorly in CircleCI execution we execute shell scripts on some virtual machine or container. This directory contains all scripts that are used in notiforb. 

templates : This directory is specific to notiforb which contains Google Chat webhook request template to be used for sending messages.

Here the example orb is very basic and created for learning purpose only, but you can move boilerplate code to orb whether it can be comman shell script, executors, validations etc. CircleCI itself manages many public orbs and provides regular updates.

References :

  • CircleCI Orbs Overview 
  • notiforb - Source 
  • notiforb - CircleCI Registry
  • Java EE to Jakarta EE

    Jakarta EE is nothing but aquisition and rebranding of Java EE done by Eclipse Foundation.  By the time I'm writing this post, Jakarta EE 10 is the latest released version.

    Few years back Oracle decided not to manage Java EE anymore and give it's ownership to an open source foundation.  Finally, it was given to Eclipse Foundation, however, the Java trademarks including existing specification names can not be used by Jakarta EE specifications. Thus javax.* could not be used as package due to which it had to be renamed to something else, which decided to be jakarta.*. 

    So it was shift of ownership from Oracle to Eclipse Foundation. This shift ended up with concerns of backward compatibility for existing libraries and frameworks which were heavily relying on Java EE. 

    Basically, all the users of Java EE had to switch to this Jakarta EE in near future for long term support and updates with the cost of backward compatibility. Even Jakarta EE didn't explicitly addressed this issue but consumers of Java EE realized and started moving to Jakarta EE gradually seeing the first release of Jakarta EE 8.

    This has impacted different frameworks, application servers and libraries al together including Spring, Glashfish, Tomcat, Jetty, JBoss, etc. 

    Few months ago Spring Boot 3 got released with GA having new baseline of Java 17 and Jakarta 9 (and support for Jakarta EE 10 as well). As you see not just Jakarta EE but even Java 17 is being pushed to be considered for upgrade considering it to be LTS. In case you are using older pre-jakarta Spring version and looking forward to upgrade to Spring Boot 3, you have to deal with updating your classes and interfaces using javax.* to jakarta.* imports if you have any.

    IntelliJ Idea has option of doing this refactoring of imports Refactor > Migrate Packages and Classes > Java EE to Jakarta EE.

    Bottom line is, everything which was under javax.* can now be found and referred at jakarta.*. In upcoming days we may see major changes at Jakarta which will make migration even difficult if we don't switch to it in near future. 

    References :

    Cloud and The Carbon

    The era of transition to cloud computing is at it’s peak. Everything we can think of softwares are gradually moving to cloud for different benefitting reasons comapred to on premise setup whether it can be security, maintenance, cost, availability or scalability. Cloud is now a preffered solution for most organizations. But cloud computing is not actually "Cloud" computing, it’s just connected powerful data centers placed at different geo locations which works together for us to provide lot of cloud services.

    Ever thought of impact of these data centers on environment? You will be surprised to know that the carbon footprint of Cloud computing around the globe is higher than airline industry. It is true that unlimited capacity of cloud comes with negative impact on this extraordinary planet.

    Let’s try to understand the overall picture.

    Why it’s impacting the environment?

    Carbon emission due to these data centers is negatively impacting the environment. Increase in Co2 (Carbon Dioxide) can increase overall temprature of planet resulting in global warning and climate change. Which has significant impact on the helth of all creatures that flourish on the planet including humans.

    Why data centers create so much carbon?

    These data centers contains lot of servers and the computation produces heat similar to your mobile phone or laptop but exponentially way more heat that that. To ensure smooth functioning the air cooling system is installed on these data centers. This air cooling systems which runs 24x7 to ensure ~100% availability are responsible for such high carbon footprint. 

    Such powerful data center can consume electricity equivalent of thousands of homes and out of that 40% electricity is used for this air cooling system. Worth to note that these data centers don't directly produce Co2 but the method of electricity production through hydrocarbon fuels produces the Co2.

    What are the solutions to this problem?

    We are so much relied on Cloud nowadays, usage and consumption is surely going to increase in upcoming years. Many Cloud providers have already started to take steps for sustainable environment by pledging to transition into becoming carbon neutral. However, stringent and transparent agency is required to review and recommend solutions to the cloud providers. 

    Interestingly, there is an example of sustainable data center, EcoDataCenter of Sweden which uses free cooling method.

    Java 17 PRNG API

    Java 17 come up with new API for Pseudo-Random Number Generators. There are several resons behind introducing new PRNG API. Which provides uniform ways to use existing and new PRNG algorithms.

    New interface is introduced due to following reasons,

    • ThreadLocalRandom extends Random class and overrides pretty similar set of methods which can be avoided by using interface.
    • To replace usage of SplittableRandom PRGN objects with Random we have to change every variable even though the classes having some similar behaviors.
    • Code duplication in Random, SplittableRandom and ThreadLocalRandom
    • Make it easy to introduce new PRGN implementation without much code changes.
    • Provide support for PRGNs which are jumpable or leapable. (i.e. Xoroshiro128+)

    What does new Random generator API provides?

    Following diagram can explain hierarchy of random generators,

    As we can see RandomGenerator is the parent interface extended by StreamableGenerator interface which enables streams of object to generate statistically independent objects.

    Two child interfaces SplittableGenerator and JumpableGenerator extends StreamableGenerator interface which are introduced as part of Java 17.

    Also, old Random class is now extending the RandomGenerator, which is done to bring older random generation into one umbrella and preserve it. As a result child class SecureRandom now automatically supports RandomGenerator. Thus we won’t need to reimplement SecureReandom class or it’s associated implementations. 


    Allows to create new SplittableGenerator from existing one which will generate statistically independent results. After split, high probability is that both objects will together generate values with same statistical properties like it is generated by single object. Provides two major split() and splits() methods to return split off and effectively unlimited stream of splits from existing generator.

    Worth to note that the SplittableRandom (which is an implementation of SplittableGenerator) instances are not thread-safe.

    Java 17 also has implementation of LXM family of PRNG algorithms which includes following classes,

    • L32X64MixRandom
    • L32X64StarStarRandom
    • L64X128MixRandom
    • L64X128StarStarRandom
    • L64X256MixRandom
    • L64X1024MixRandom
    • L128X128MixRandom
    • L128X256MixRandom
    • L128X1024MixRandom


    Allows to generate random values and jump to a point in state cycle.

    Provides jump() method, which jump forward to fixed distance (typically 264). Also, jumps() method returns effectively unlimited stream of object post jumping forward. This are major methods, but it also provides other methods as well like jumpDistance() which returns the distance by which the jump() method will jump forward, copyAndJump() which copies existing generator, jumps it forward and returns the copy etc. Unlike split() which returns the split off object, jump() is void which just jumps.

    LeapableGenerator interface extends JumpableGenerator. Which allow to jump ahead a large number of draws.

    Following implementations of JumpableGenerator are provided in Java 17,

    • Xoshiro256PlusPlus
    • Xoroshiro128PlusPlus

    Sample program to get implemented random generators in Java 17, Output:
    Provided RandomGenerators :
    Create RandomGenerator :Xoshiro256PlusPlus

    Reference :