Use your budget to build apps. Not Oracle’s piggy bank.

CALCULATOR

See what you'll save by switching from Oracle Java SE to Azul.

Calculate Savings >

Oracle Java SE vs the Challengers

How Oracle Java compares to Azul Platform Core, Red Hat OpenJDK, Amazon Corretto, and AdoptOpenJDK.

Explore Java Alternatives >

The industry’s best OpenJDK support

CASE STUDY

Kyocera switched to Azul to gain direct support from Azul product and engineering teams.

Read the Case Study >

Why might you not want to go to the latest CPU version?

Before we start, it is important to just go through a couple of principles and things that usually we get on our conversations with our customers and prospects and so on. The first thing is important to understand here is that sometimes, the very first bullet here, sometimes depending on the version you are migrating to, you may not want to go to the latest CPU version.

This is true for very old LTL LTS versions like version 8. And because there is a lot of different updates on version 8 and we have a lot of different CVs there was addressed since the beginning of time for version 8, when version 8 was released in 2016. You may observe, if you try to migrate immigrate from an old version you have, a legacy application that is running in an old version of the JDK version 8 in your environment.

If you try to migrate to the latest version, you may observe some regressions in terms of performance. If this is... And then there is the idea of understanding what is really important. If security is really important and overcomes performance SLAs that you have for performance, then you should go through the latest version always. But if it's not true, if you want to balance things between the version performance and security, then we need to come up with a plan and do the migration in something that we call a light to light migration.

You shouldn't go directly to the latest versions from a very old version but instead, to the same version that is related to the Oracle distribution to that particular release. In this case we have update 92. Another thing here is related to... That's a misconception. Java has a premise saying, "Compiled once and runs anywhere."

Common Java migration misconceptions

So this is since the very beginning of time. When I started this 25 years ago first listen about applets, this was a main thing everywhere. So this was in the mainstream and that's exactly what we have here. So for instance, because we are doing a migration in the same major and minor version, well may have same major version of the JDK.

That means that you don't actually have to recompile any application and this is a misconception as well. So your CITD pipeline is unaltered. So you don't have to actually run it. So it's an infrastructure change and you don't have to touch your application. Mainly if you're doing just the migration, not... It's different migration for modernizing new applications. So if you want to modernize the JDK, that's a different story. Then you are going to have to recompile and probably there's going to be between versions, there's going to be a few jumps in terms of coding.

But if you're just doing the migration like to like, major versions to major version, version 8 to version 8, Oracle version 8 to us, Azul version 8, then you don't have to recompiled application. You just have to do the installation. Okay? So that's a very important thing.

Another thing that is important and we see quite a lot is related to support matrix we have for some products and sometimes, some of the products like in the example we see here, this comes from data stacks and you actually see the support matrix, our JDK listed right there as one of the options for that application.

But sometimes what happens is that you may not see our JDK listed precisely. We may not see something like we're seeing here like Azul OpenJDK or anything like that. But if you see something like OpenJDK just like we are seeing here, it means it supports Azul. That's important thing. So the support matrix, if the support matrix identify in the product that it supports OpenJDK, then it supports Azul, Zulu OpenJDK.

Java migration related to developer environments

Another thing that is important to notice when we talk about migration is related to developer environments and especially developer desktops because if we create a difference between development environments, lower... Let's just put it like lower platform environments, lower platform environments, and then control environments like production, staging and so on, what happens is that development environments are usually controlled by the application teams and the application teams they have to test.

And what happens sometimes is that they run installations, they install stuff into their environments. They're supposed to do this because they're testing new features, the applications, maintenance and so on, validating main new features and just bug fixes and so on. That's expected.

But at some point what happens is that if you go through this path, the development environment's either going to have some very old, some installation that is never used. It's just staying there. You may have garbage JDK installations that were there, just because at some point they were necessary and because they're not controlled, they can be sometimes hard to be identified. If you run an audit, they're going to appear there even if they're just lower platform environments.

Different story for control environments, but be careful with development environments. So another thing important here is validation. When we talk about validation, what we're talking about here is mainly testing. Testing implications, functionality is different from testing and validating the migration. So the first thing important to understand is that we can see the JDK as an infrastructure software for applications.

The JVM that is used for running the applications, does it not change the behavior of the functionality? There is no changing behavior in the functionality. So there is no need to actually retest everything in the application because you're just changing the infrastructure software that is used for running the applications.

But still, it's necessary to run some tasks. We're going to have a quick discussion about this in a few moments, in a few slides. But it's just important that you won't have to go through your entire pipeline, meaning it makes no sense you run coverage tests.

Unit tests are great for validating functionality, internal functionality of the application, but there's no need to run such type of tests when we do a migration. We are mainly focused on very specific regression situations that are not quite related to the full spectrum of testing of an application.

End to end scenarios, for instance, test cases like these, they probably won't have to be executed during the migrations, not necessary. So that takes a lot of time from the migration itself. Another thing important here is related to the software asset management tools and what happens sometimes is that... Well, when you're doing an IT state, there's several tools that do this.

Software Asset Management Tools

We can just set a few... We can just talk about a few of them like there's Flexera at CCM and so on. There's a lot of tools that do that. But the real problem related to this when we are doing software asset management is that because they're responsible for the entire IT state of your organization, what is going to happen is that if you wanted to filter out only the JDK installations, what you're going to do is only retrieve basic... Well not all of them, but some of them will retrieve only basic information related to installed software.

Because Java has some very specific installations, can have different types of installations, not only using package managers or MSI packages, you can actually simply just unzip the JDK package into our environment and it is going to work. Those piece of software, those JDK installations, they won't actually be shown in the reports generated by the ITSAM tool. Okay.

So that's an important thing to remember. So we're going to have to extend that in order to get all the data and to map the entire Java estate.

Application teams working with the migration team

Finally, that's a very important thing and I wanted to place this one as the last bullet because the application teams, the apps teams, they need to walk hand in hand with the migration team. That's a very important aspect. They know the process, they understand how the application works, they understanding internal components that construct the application and because they do that, the information that they have is going to be crucial for succeeding with the migration, especially during the discovery phase.

Azul's agile migration method phases

In today's presentation, I'm going to be talking about the method that we use here in Azul. It's an agile method composed of three phases. The first one that we call a discovery, the second one that we call it execution. And the third one that we call it validation. It's a very simple process but it's very powerful as well. So initially when we talk about the discovery, discoveries can have as many sprints as necessary and this is what is actually going to happen. And then you move when you're ready and finish it up the discovery, you go to the execution and execution like the name describes, it should get everything to get the Java state, the classified Java state and put the migration into practice.

Finally is the validation stage. And usually, the validation probably is going to be composed of maybe one, maximum two sprints. Short sprints, we're talking about probably one or two weeks for validating the migration, the entire application stack. And the reason it is like this is because if we had a good, good mapping, good discovery phase, if I ran a good discovery phase, it's much simpler to go through the validation and execution and the validation.

Another thing that is important to add to this process is something that we call... Well, call it quality gauges. And the quality gauges are very important because you should define in the very beginning of the process, during the setup, this is sprint zero, very first iteration in the phase in the project, you should define the quality gauges that are related to this migration. So what do you expect in different phases?

You don't have to be only limited you want or one specific quality gauges. You can have as many as you want depending on your application, but they're very important to maintain the quality of the development, especially if you have vendors working with you during this migration. Okay?

Normal Java project vs. a Java migration project

All right. Okay. I wanted to put this slide here just in terms of comparison of a normal project and a migration project. The first thing you want to see in this very simple pie charts, diagrams here is that if we compare the design phase of a normal project with the discovery phrase in a migration project, you can see that the difference between designing and discovering are very, very different.

The difference is big. That's a very important aspect because in a normal migration project, the discovery phase is the one that is going to take the most. All the juice that is necessary to make the migration happen to succeed with the migration is actually in the discovery phase.

Java migration step: Discovery

There's a lot of things that are important to be done during discovery before you actually move to execution. A big portion of the project in itself will be the discovery. Execution will take some considerable amounts of effort, but discovery is the big portion of the entire project. And that's the reason in today's presentation is that we are going to be focusing more in the discovery, we're going to touch base a little bit the execution phase and the validation phase, but we are going to be most focused in the discovery phase.

If we have time at the end, we can actually have an open discussion or after, we can have an additional call as Elise was talking in the beginning just to discuss the other aspects for about execution and validation in terms of testing. But we're going to touch base some of the aspects here in today's presentation.

All right. So the very first step thing you want to have is the inventory. One important thing about inventory, your Java state, is that you don't have to wait to inventory different environment types. So you don't have to do it in lower environments first, including development, QA, integration and then moving to staging, production and so on. Sandbox, doesn't matter.

You don't have to actually do this. You can actually inventory everything at the same time and that's what it is expected. You do an entire inventory of the entire Java state, everything that you have not only servers but talk about servers, but also desktops as well. So you collect that inventory and that's some of the data you can actually retrieve and get. At the end, if we have time, I'm going to run a quick demo and I'm going to show you how can you extract this information from the JVM, the JDK directly.

But this is mainly what you want to have when you're doing the inventory because this is what is used for classifying the data afterwards. When we talk about classifying the data, let me just open a parenthesis.

Classifying the data means that we are actually collating the raw data that came from the inventory or the JDK, all the JDK installations and mapping those to specific applications, products and test strategies. So this is what we talk about when classifying the data. And this is important here because by just looking at this, we can actually start the process of classifying the data.

So usually this is what you will need for inventory in the very beginning, the very first step in the discovery phase. How you start this. A couple of things here in this slide. This is a very simple slide, but it's a very important one and that's the reason I place under parenthesis this couple of words that we call it KISS.

I don't know if everyone here knows what KISS means, but simply is keep it simple stupid or keep it stupid simple. So that's the reason we have. So start by just scratching the entry points and then move forward and start collecting more data, more data to actually get where you want. But in this particular case, the approach that we're having for the first step of the classification is dividing the data into different buckets.

What you're going to do, as we saw here in the very beginning, you're going to get the data, the raw data that you inventory. And again, this can be data that you retrieve from your tool, from whatever tool you use like a CCM and so on, Flexera, it doesn't matter. Or it can even be a custom tool. And then after you get that raw data, that what you want to do first is just run a quick classification. And that's why we have those first buckets here.

So we have a bucket for each one of the data that was classified from the very beginning of the inventory. So you have the possible migration bucket, you have the need for further investigation bucket, you have the bundle JDK bucket, you have the not used bucket and you have looks like garbage bucket.

By analyzing that data, you're going to classify the data initially in the very beginning into one of those buckets. You're going to place this in one of those buckets. The reason you're going to do this is because you need to use this and just filter out, just garbage and garbage out the data that is really important. The data that is not really important because what we really want to get is to those final buckets that we have here in the bottom, the ready for migration, do not migrate and mark for renewal.

Java migration step: Execution

That's the final stage of the discovery. When we get to this stage, it means that we are ready to go to execution. And each one of those buckets will have a different action. Important things to talk about, this slide is for instance, in the very beginning you should trust heavily into tools. Because when we brand the first time and we start doing the classification, the tools can actually give you a lot of information and can help you filter out right away what is necessary and what is not necessary.

In the very first bucket classification we see here, in the first level right here. So here in the first level, this is what we are doing. Basically using tools to help us identify where to place those JDK installations. And not only that, not placing and separating the JDK installations into different buckets, but also defining specific properties for each one of those buckets.

Because this is also very important and I place here, the two most important properties you want to have when you're classifying your JDK installations into buckets, the configuration your JDK installation has, that's very important. This includes several different things like for instance, how your JDK is installed. Because when you're doing the migration, you want to have a similar installation for Platform Core.

Not only that, but do you have something that happens quite often? So if you have an application server, I'm going to give you an example. If you have an application server running and your organization is mapped as an internal CA, you're going to have to place those certificates into the certs in the security portion of the Java Runtime. And if you simply do the migration, one is going to happen is that the new CA certs that is placed there will not have the certificates that testify that your organization is a CA for how many certificates are generated internally.

You're going to have some strange errors because of that. The configuration is mainly describing, there's a set of properties describing what you need to have to succeed in the migration. And then we have another group of properties that I name here as compensation actions. This is because in some situations this is mainly related to the difference we have with the Oracle JDK and the Zulu or Open Zulu, OpenJDK.

The main differences we have. They're not much, they're just a few of them but for some situations, and we're going to briefly talk about some of them in just a few moment, but for specific situations, you're going to have to work around or define compensation actions for those environments before you actually finish the migration. It's not only separating into buckets, but also putting and adding some properties to the JDK installations there inside each one of these buckets we have here.

All right. And then at some point, you're going to have to go to the menu integration and this is where you use the teams, the interviews with different teams and you're going to use compliance as well to finalize the data that was placed here by the tools and accurate separate each one of the JDK installations in your Java state into those buckets.

They're self-explanatory, so I'm not going to waste a long time explaining which one of those and what they do and so on. It's self-explanatory. But I want to talk about it briefly to this specific bucket here, small one gray painted that we call it down downgrade bucket. And let just put it something here, this is not recommended. I've just put it like this for you guys here. Not recommended but because we'll have thousands of cases of migrations actually, and we see this in some situations and this is a decision that sometimes it needs to be taken that you download the application, then this is probably what you may consider.

I can give a quick example in terms of this. If you talk about applets for instance, so if you have an applet that is running an Oracle GTK and has some complex deployment rules set with signage jars and it's complicated and is not really working and there is no intention to actually create a separated branch for development, this using a different technology like for instance in Java Web Start with [inaudible 00:25:47] and so on.

Then in some situations, it's a good idea to just go below the Oracle exposure and continue to run the application until it gets to the time where it's decided that particular application is going to either be put in the vault, separated, not going to be used or is going to reach end of life or you want to modernize that application for not running such an old and unsecure and crappy solution like applets are.

It was a great idea like 25 years ago, not so much anymore. That's the reason we have here. Another thing that you could notice in this graph is those dashed lines and the solid lines. The solid lines here, the path that you're probably going to take after you finish the classification and the dashed lines are just options that can appear after you finish the manual iteration of validating and analyzing the data you have.

One thing guys, so if you have any questions just feel free to post them in the chat and I will gladly respond. Or we can wait until the end. Either way, it works just fine.

Java migration step: Classification

All right, so classification. A couple of things important related to classification. So the very first thing is what we call it in agile, teams workshops. This is precisely what we have in a normal project. When we're collecting new requirements and use cases, this is the same thing with a different strategy because instead of collecting the functionality, the requirements for something that will be developed, what we are doing is mainly trying to do a discovery in the application itself.

What you want to have from those. What exactly do you want to have from those scene workshops, what you want to have is a complete component diagram of how the application is constructed, all the components that the application has. Because you have to use those, you're going to use those afterwards to mitigate risk and prepare. Those compensation actions we saw before, this is why it's so important.

Of course there's other ways we're going to talk about some of them to actually get this information from, but for most cases talking to the application teams will give a better classification always related to the application.

Another thing important is that, as I said in the beginning, asset manager tools usually give you installation paths. Something that was installed and put it into [inaudible 00:28:48], that is in the environment. And this is good because this is precisely what Oracle is going to audit. So that's a good thing. But most of the time, it is not going to give you as a response some rogue installation or JDK installation in a specific path that is used with a specific product for instance.

In some situations you have to extend the search for your Java state, but just using manual iterations in the file system for some service. There is a lot of ways to do this. That's a broader discussion. It extrapolates a little bit what we are talking here, the time that we have, but if you have questions related to this, I'm more than open to give you some ideas and things that we usually do.

Again, mainly any IT administrator we will go through and use. All right, so package installation analysis is a very important feature. Because as I said in the beginning, Java can be installed in different things. I kind of already said this, but anyways, Java can be installed as a system-wide configuration. It can be installed for specific users. And this happens quite sometimes in shared environments.

You have for instance, users that they're specific to running specific applications. Like for instance, if you have an application server and you need to run that application server with specific JDK distribution, you're probably going to have a user that is related to that application server and the environment will actually have the configuration for running that JDK with your product or your application server in this case.

Specific product path Java Runtime. So you find most likely, most of the times you'll find the JDK installation as part of the product structure. We call it those bundled JDKs with product. And then you'll have another thing that is very important, this is specifically for Windows and I place it under parenthesis here because MSI installations are a license feature to Oracle. So if you have any Java Runtime installed by MSI, and you can actually check this in the Windows hydro, right? The Windows hazard three actually tells if the installation went through MSI or not. This is a license feature and it's important to identify, but for most of the cases, the normal ITSAM tools, they retrieve that information for you.

One important thing, this is kind of an extension from everything that we talked so far, and this is to analyze the process table as well. The reason we are saying this is because remember there is one bucket here that says not used. If the JDK is there and it's not being used, you have to understand why it is not being used at first, but mainly you have to remove the JDK that is not being used because if it is a license, if it increases your exposure to Oracle, you don't want to have there. You don't want to have that particular JDK in your environment because with the new license changes as you know, it's a zero installations of the Oracle JDK.

Even if there is one, the entire organization is jarred. So this is not what you want. So that's the reason it's important to actually analyze, actually this is one of the reasons you want to analyze the process table and the process hierarchy in the operational system because initially, it's going to give you that information and we have some techniques for that.

For instance, I'm giving a couple of examples because if you run this only once, you're not going to get... If you analyze the process hierarchy of the JVM processes, you're not going to get probably batch processes that may run at some specific point of time. So you may want to have some discovery phrase for those processes using some specific scheduler. In this case on Linux, very old trustworthy crown tab, everyone knows this. Works great, you can place a discovery there.

On Windows, you can use the scheduler. So the scheduler, the task scheduler, the scheduler in Windows works pretty well. So you keep this discovery running there for a time and then after this period of time, you're going to get a consolidation of all the JVM processes that ran during that time.

If you, by any chance not find a running JVM process related with what you discovered, what you have in your Java state for that particular host, you know what do. Another thing as well, you can get additional information. Like for instance, you can get what is the version of the product that is being used. But just analyzing this, so you can actually compare the information you get from the process table in the operational system with the information you have from the application teams. And then by comparing, you can actually see what is trustworthy and what is not.

Java migration step: Compliance

Finally, and also very important is the compliance. The compliance thing I said in the beginning, apps, teams need to work, need to run hand in hand with the migration team, but the compliance team as well. Because there's a lot of things that are important that extrapolate a little bit the technical aspect of the migration and this is related to political aspects like licensing different versions.

I'm going to give you a couple of examples what happens, and those happens quite a lot in most organizations. Especially in desktops, but they happen in own service as well. Development service and this example is related to downloading software, installing and testing it. Oracle for instance, know all the Oracle products, most of them, I'm not going to say all of them, but most of the Oracle products come with a JDK embedded into it.

But you can actually download those products without any charge and test them running a local machine, on your desktop or in a server. There's no impediment that says you cannot do this if your company policy allows you to do this. If your organization allows you to do this, there is no limitation of running and pulling with something like this. So if you just run the classification in this stage and you talk to the application teams and you went and analyzes the process table and you ran some pattern to identify if this is a bundled JDK or not, you will see that all right, so I can see here that this product, like for instance, Oracle database, so I can see that the Oracle database is installed here and the JDK is related to the Oracle JDK database, which is by the way, all okay.

In terms of classifying the data, this is not wrong, but do we really have a valid license to run that piece of software? That's a very important thing. The compliance team will help you, we know in their internal audits to retrieve that information from you for you during this discovery phase. And then you know what you do. Either you remove it or you're going to have to take some action, verticalize to place that installation in valid terms with the Oracle conditions to and remove the exposure.

Deep dive into classification

All right. We're going to dive a little deeper here in terms of classification. In this particular case, what I'm showing here is a way to initially classify the data. There's other ways to do this and some tools actually do this without any problem. For instance, if you run a report in Flexera, it will retrieve that information, if you need it.

SCCM also retrieves it. But in this particular case, what you're talking about is imagine that you're running this as an extension of your normal asset management process. Pattern based classification, this is a nice and useful way to classify your data. Like for instance, you can have a script that reads some pattern-based [inaudible 00:37:46] expression here, but it doesn't have to be. But regular expression is very good. They're very powerful. You have to be fluent on those.

Well, it's annoying in the very beginning, but after you know them, you love it. You love it. You love them for the end of [inaudible 00:38:01]. You're going to love it for the end of your life because you do a lot of things.

So you can actually use regular expressions to classify your data when you're doing the inventory. For instance, if my discovery phase identify those three JDK installations, we have three examples here. And I put those JDK installations running under my specific pattern, I can easily identify that all of those are actually part of a product that is called an Oracle Fusion Middleware and they're the Oracle Business Intelligence suite. So it means that if you have the Oracle Business Intelligence Suite or the Oracle Fusion Middleware license, you don't have to worry about those JDKs because they're bundled with that product.

Those should be placed on that bucket we saw should not migrate. And then you say, but this is valid. So then you may have a question related to this. So is this valid for all the cases? Yeah. For most, let's just put it like this.

Not for all of them, but for most of them because usually they have... Especially when you talk about products, known products, they have a very specific installation structure and you can use that right as a clever way to extract this information from. But of course, it may not work for all the cases, but for most cases, yes, it works. If you want to identify typical running an Oracle, you want to identify any Oracle product, you can actually use something like this or something similar to this, not only from the package manager installations of the JDK, but also whatever package you have in your environment, it was just unpacked in places somewhere.

Okay. How about the garbage selection? Well, this is pretty straightforward. You can have a pattern based classification just like we saw before, but just by looking into the path configuration, you can see what looks like garbage and what doesn't look like garbage.

In this particular case, at each one of the entries, and this came from a real case. I just changed it, the words a little different to not identify the customer, but this came from a real case. As you can see, but just analyzing the installation path, you can quickly identify what JDKs are just standing there, they're just garbage. They're not really being used. So you can see here, this is inside the trash, trash bin and windows.

This is the commissions, this is just those two are just backups. You're going to find a lot of this in your development environments. That's what you're going to find. A lot of this in your development environments because people are...

Even in production, sometimes you find some crappy stuff like this, but in development environments you find a lot of crappy stuff like this. But those are all valid Oracle JDK installations. See the risk here. So that's why it's so important to quickly identify your Java state and classify it as quick as possible like in this example, just put it in, it looks like a garbage a bucket and it is really confirmed by the application team, by your internal validation, by the compliance team, then this is just marked for removal into the to-be-removed bucket.

And here, an example in terms of why the process table is so useful. In this particular example here, we are collecting information from a developer machine. This is a desktop machine. And as you can see here, if we don't know how the JDK is being used in this particular case, it's pretty straightforward because the JDK is just a portion of the installation path of this product.

But in some cases, that product may be using a standalone version of the JDK or a system-wide installations. And just by doing the inventory, you may not identify what products or applications are used in that specific JDK installation. But in this case, just to show us an example from a developer machine, you can clearly see information that can be useful for you. Like for instance, you can get the details we see here. So we know that this is a Visual Studio code.

Just by analyzing the data here, we can actually get it Microsoft and VS code right there. We know the versioning of the JDK, right? Because the version of JDK is right here. And if we run this particular executable, the Java executable here, we can actually get the version as well. So we are going to get it all the time. We know that the publisher is RedHat. We can actually get this from the installation. We know the version by just looking into the information we get from the process, we can actually identify what is the product that is being used with the JDK.

Finally, Visual Studio code is a developer tool. Just a simple example to see how powerful this is. Of course, in this particular case, what we are doing here is not being shown, but what we're doing here, we are just navigating through the hierarchy.

And that's a very important thing. What you want to do is when you're analyzing the process table for and looking for JVM processes, what you want to do is you want to navigate the hierarchy, the process hierarchy of the JVM. The very first stage, if you take only into the very first level, the current level of the JVM process, you may not get the information you need. Because it's mainly just the JVM, it doesn't tell much. But if you navigate through the hierarchy, the next level, the parent level, the parent process level may tell you more about the application.

A quick example to our application that runs on Windows, Windows services. If you have a JDK that is wrapped around the Windows service, you can actually by just analyzing the parent that is triggering the child process, the JVM. In this case, you can actually identify what product this particular JVM process is related to.

Future compatibility

All right, so considerations about the future compatibility. There's a couple of things that are important. If we compare Oracle JDK with OpenJDK, there's a couple of features that Oracle uses that is specific license to the Oracle JDK. And this is just a list of some of them.

Well, we don't have to go through all of them, but there is one that I want to talk about and this is related to Java Web start. So old applications that use Java Web Start, Java Web Start is as license Oracle feature, but the specification for the Java Web Start is not.

It's an open source and it's part of the community process. That's a GSR for the JNLP specification and we support a tool that runs that. It's similar things, called IcedTea-Web Web. It's a different configuration. It requires additional steps, but it runs the JNLP and all files exactly like the Java Web Start in Oracle does. We have other things as well. Like for instance, if you have applications that runs graphics in the server side and when I mean graphics is not only process imaging but also putting text into those images and so on.

For quick examples, if you generate reports, not using report but using open source standards like Jasper or others and generate a PDF report, then what is going to happen is that the monotype fonts are actually licensed and you may see no stranger errors and we provide open source version of this is free of use, free of charge to use.

And this is the commercial compatibility kits for JDK 6-8 for most of the cases where those problems happens. There's other workarounds that can be done. We can discuss this afterwards like installing other font types on Linux and so on, that also work around those issues. But it's just important to know. In terms of a risk assessment, there's a couple of things that are important. So in terms of the interviews, remember the very first stage are the interviews, the round tables with the apps teams. And this is not only for identifying how the components are organized, but also to identify possible risk that needs to be mitigated. When we talk risk, we just make a big word, it's not really like this, but we need to identify what additional effort is necessary to work around some of those things that I just described it to you guys.

That's the reason we see here. There's a couple of things that can be done here, some clever ways to do this. For instance, by just interviewing the apps teams, you can actually get this information from example, do you have applets running your environment? You generate reports, do you generate QR codes for instance? And then put images, taxing it or barcode and so on. Those types of interviews are great to get this information from. Another thing that is important is the version analysis.

So if you have JDK installation, the JDK 13 installed in your environment, you won't need to actually worry about Java website or even applets because they're not supported on JDK 13, package introspection is something that we do. We have a tool, we have several tools that we can provide to you guys by request is a way, if you don't have a lot of context or the application owners, they don't really know about the internal components of the application, it can happen.

You can actually have a Java just go and do an introspection into the packages and search for specific things like for instance, JNLP files or specific classes and so on. So you can actually do this, but just using by code engineering, it's possible to do this. We have a tool that does that. So if you want to know more about it, just let us know.

You can actually use application name inversion. That's important thing because if you have... There's no products that have no problem whatsoever running with the OpenJDK. We have a list of those. You don't have to worry about it. You don't have to even test those because we know that they work, they simply work. For instance, solar. Most of the Apache products simply work. And not only those, but others as well. You simply do the migration.

It's a seamless migration, nothing's going to happen. So you don't have to worry about those as well. Power users interviews are important, especially for desktop applications. Application documentation is also another great way to extract information from the application. Finally, if you use some internal repositories, maybe repositories or other repos that can extract the patches that are used by the application, you can actually try to infer ways to identify and classify additional actions that need to be taken in order to finish the immigration.

Test strategy

Okay. That's a very important slide test strategy. And I think, yeah, I can talk about this the entire day if you guys want, right? Test strategy, important things you get from this. When you're doing immigration, don't worry about the entire application functionality because that's not what you want to do. The only thing you want to have here is test for regression, exactly like you do when you run a patch update in your operational system, for instance.

So you want to test regression for all the products that are run there. It is part of the same idea. So when we talk about regression here, mainly what you want to have during the testing for the migration is just quick smoke tests. Just verify the basic functionality and that's it only for very critical functional applications. For those cases, you may want to have in our end engine and a few end scenarios, but not all of them.

We recommend that you have those tests automated because it's faster to run the validation. But if you don't have that and you have a QA team that is responsible to just run manual tests like QATs for example, that's absolutely fine as well. For desktops, when you have desktop applications, then you can use the power users in your organization to actually run the validation into those desktops applications.

And if you don't have automation, I highly recommend, we highly recommend that you actually automate the smoke test for some of the specific and critical functionality of the applications you are migrating. It's not something that is hard to do. We have a few examples. We can provide those two to you as well as Docker. We have Docker images that can also be used for doing this for automation.

Effort matrix estimation

Just let us know and we're going to help you as much as we can. Final topic, I promise you Elise, this is fast. But this is a very important thing. The matrix here, it's an effort matrix estimation is what we are using here is two different axis. We have one axis that is related to the JDK risk, which is most of the time is going to be very low for 99% of the cases are going to be very low.

And then you have this other axis on this size, and this is related to the [inaudible 00:53:34] of the application. And based on this, we have some scoring that you can use based on this classification of the data by just analyzing where your application stands, in this matrix, you can get a categorization off the application. And this is what we have here as an example, a four stage category.

In this particular case here, what we have is dependent on classification, this is going to go to category one, two, three and four. And by just running this example here, as you can see, mission-critical application, you're going to get on a scoring basing on those, and the classification is going to go right here.

This category one, it's category two, category four, category four. And basing on those, you can actually come to your rationale and not only be prepared for what is your stats strategy, which is very important. What the test strategy should use based on the category classification.

But not only that, but also effort estimation. We are not talking about project timeline here. This is different story. It's going to be very unique for each one of the products, the projects. But we are talking about overall effort estimation. So we can actually place a rationale and just identify based on the team that is involved, what is the effort based on the category done by the classification for category then during this phase. Okay, so that's it. I don't know. I think [inaudible 00:55:11], if you guys have any questions.

Where can I get support for Java 6 and 7?

Elise: I want to squeeze in one question, but Joao, it's such great content and it's so important. Again, I want people to know that we're thinking about office hours. Send us an email at migration@azul.com.

This one question is where can I find support for Java 6 and 7? And everybody else, we will get back to you individually. So thank you so much and thank you, Joao. Where can I get support for Java 6 and 7?

Joao Gonzalez: Okay. That's a very important question because we are the only ones today with that support, we are the only company today JDK distributor that supports version 6 and version 7. So we are actually providing patching updates for those versions.

So if you have old applications running on version 6, we're still updating those versions and supporting those versions. So the quick answer to that is that the only place you can actually get support for version 6 and 7 is at Azul using a Azul Platform Core.

Elise: So if for some reason you wanted to migrate off of Oracle and you're running these old applications, we actually can help you do that because we have those versions and they're updated and we can make sure that you... And also, we have not only PSU but CPU versions, so you can get exactly the same support that you're getting from Oracle for typically 70% cheaper. Sorry, everybody. Product marketing here.

Do any OpenJDK distributions support applets?

Joao, I think we might have time for one more question. You touched on applets and this person wants to know if any OpenJDK distributions support applets.

Joao Gonzalez: So first of all, there's two things in this question. The OpenJDK distribution actually have apples and old versions, you can actually download those from the vault for some open dedicated distributors, but we don't actually support... Actually, there is no implementer of the OpenJDK today that actually support applets. Applets are an unsupported feature in the OpenJDK now, but if you run, of course all the updates from version 6 to version 7, you can actually run applets on those versions, but they're not supported.

So you cannot support your application if your application is running on applets. We do our best. We do the migration, we help you, guide you through the usage with your applets with OpenJDK. Well, we have some problems in some specific situations that need some additional consideration, but for most cases, they just work. Applets work on OpenJDK as they work on Oracle JDK as well.

Elise: We'll try this one question. We have last couple minutes or last... Well, okay. We'll send you an answer. This is a question about whether or not, this is a concern from if they moved off of Oracle JDK and they had Oracle applications running. They're concerned that they'll still be targeted by Oracle for an audit.

Oracle does have the right to audit you if you have other Oracle applications. But we can talk to you about how to make sure that you don't have Oracle, the Oracle JDK running, which would expose you to that new employee metric license.

Joao, thank you so much for your time today and thank you all attendees. You have stuck with us through this whole hour and I appreciate that. I hope it's a sign that you've enjoyed the content. Please take the survey and let us know how we're doing and how we can be better. We will send you the recording and the PDF of the presentation.

Again, if you want to join office hours, then please let us know at migration@azul.com. With that, goodbye. Have a wonderful, wonderful day everyone. Thank you for attending. Thank you, Joao. That was wonderful.