Month: September 2020

Posted on

How to enable HTTPS certificate in a Spring Boot Java application

Setting up HTTPS for Spring Boot requires two steps:

  1. Getting an SSL certificate;
  2. Configuring SSL in Spring Boot.

We can generate an SSL certificate ourselves (self-signed certificate). Its use is intended just for development and testing purposes. In production, we should use a certificate issued by a trusted Certificate Authority (CA).

In either case, we’re going to see how to enable HTTPS in a Spring Boot application. Examples will be shown both for Spring Boot 1 and Spring Boot 2.

Introduction

In this tutorial, we’re going to:

  1. Get an SSL certificate
    • Generate a self-signed SSL certificate
    • Use an existing SSL certificate
  2. Enable HTTPS in Spring Boot
  3. Redirect HTTP requests to HTTPS
  4. Distribute the SSL certificate to clients.

If you don’t already have a certificate, follow the step 1a. If you have already got an SSL certificate, you can follow the step 1b.

Throughout this tutorial, I’ll use the following technologies and tools:

  • Java JDK 8
  • Spring Boot 2.2.2 and Spring Boot 1.5.22
  • keytool

Keytool is a certificate management utility provided together with the JDK, so if you have the JDK installed, you should already have keytool available. To check it, try running the command keytool --help from your Terminal prompt. Note that if you are on Windows, you might need to launch it from the \bin folder. For more information about this utility, you can read the official documentation.

On GitHub, you can find the source code for the application we are building in this tutorial.

1a. Generate a self-signed SSL certificate

First of all, we need to generate a pair of cryptographic keys, use them to produce an SSL certificate and store it in a keystore. The keytool documentation defines a keystore as a database of “cryptographic keys, X.509 certificate chains, and trusted certificates”.

To enable HTTPS, we’ll provide a Spring Boot application with this keystore containing the SSL certificate.

The two most common formats used for keystores are JKS, a proprietary format specific for Java, and PKCS12, an industry-standard format. JKS used to be the default choice, but now Oracle recommends to adopt the PKCS12 format. We’re going to see how to use both.

Generate an SSL certificate in a keystore

Let’s open our Terminal prompt and write the following command to create a JKS keystore:

keytool -genkeypair -alias tomcat -keyalg RSA -keysize 2048 -keystore keystore.jks -validity 3650 -storepass password

To create a PKCS12 keystore, and we should, the command is the following:

keytool -genkeypair -alias tomcat -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore keystore.p12 -validity 3650 -storepass password

Let’s have a closer look at the command we just run:

  • genkeypair: generates a key pair;
  • alias: the alias name for the item we are generating;
  • keyalg: the cryptographic algorithm to generate the key pair;
  • keysize: the size of the key. We have used 2048 bits, but 4096 would be a better choice for production;
  • storetype: the type of keystore;
  • keystore: the name of the keystore;
  • validity: validity number of days;
  • storepass: a password for the keystore.

When running the previous command, we will be asked to input some information, but we are free to skip all of it (just press Return to skip an option). When asked if the information is correct, we should type yes. Finally, we hit return to use the keystore password as key password as well.

What is your first and last name? 
    [Unknown]: 
What is the name of your organizational unit? 
    [Unknown]: 
What is the name of your organization? 
    [Unknown]: 
What is the name of your City or Locality? 
    [Unknown]: 
What is the name of your State or Province? 
    [Unknown]: 
What is the two-letter country code for this unit? 
    [Unknown]: 
Is CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct? 
    [no]: yes 

Enter key password for <tomcat> 
    (RETURN if same as keystore password):

At the end of this operation, we’ll get a keystore containing a brand new SSL certificate.

Verify the keystore content

To check the content of the keystore following the JKS format, we can use keytool again:

keytool -list -v -keystore keystore.jks

To test the content of a keystore following the PKCS12 format:

keytool -list -v -storetype pkcs12 -keystore keystore.p12

Convert a JKS keystore into PKCS12

Should we have already a JKS keystore, we have the option to migrate it to PKCS12; keytool has a convenient command for that:

keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -deststoretype pkcs12

1b. Use an existing SSL certificate

In case we have already got an SSL certificate, for example, one issued by Let’s Encrypt, we can import it into a keystore and use it to enable HTTPS in a Spring Boot application.

We can use keytool to import our certificate in a new keystore.

keytool -import -alias tomcat -file myCertificate.crt -keystore keystore.p12 -storepass password

To get more information about the keystore and its format, please refer to the previous section.

2. Enable HTTPS in Spring Boot

Whether our keystore contains a self-signed certificate or one issued by a trusted Certificate Authority, we can now set up Spring Boot to accept requests over HTTPS instead of HTTP by using that certificate.

The first thing to do is placing the keystore file inside the Spring Boot project. We want to put it in the resources folder or the root folder.

Then, we configure the server to use our brand new keystore and enable https. Let’s go through the steps both for Spring Boot 1 and Spring Boot 2.

Enable HTTPS in Spring Boot 1

Let’s open our application.properties file (or application.yml) and define the following properties:

server.port=8443

server.ssl.key-store-type=PKCS12
server.ssl.key-store=classpath:keystore.p12
server.ssl.key-store-password=password
server.ssl.key-alias=tomcat

security.require-ssl=true
application.properties (Spring Boot 1)

Enable HTTPS in Spring Boot 2

To enable HTTPS for our Spring Boot 2 application, let’s open our application.yml file (or application.properties) and define the following properties:

server:
  ssl:
    key-store: classpath:keystore.p12
    key-store-password: password
    key-store-type: pkcs12
    key-alias: tomcat
    key-password: password
  port: 8443
application.yml (Spring Boot 2)

Configuring SSL in Spring Boot

Let’s have a closer look at the SSL configuration we have just defined in our Spring Boot application properties.

  • server.port: the port on which the server is listening. We have used 8443 rather than the default 8080 port.
  • server.ssl.key-store: the path to the key store that contains the SSL certificate. In our example, we want Spring Boot to look for it in the classpath.
  • server.ssl.key-store-password: the password used to access the key store.
  • server.ssl.key-store-type: the type of the key store (JKS or PKCS12).
  • server.ssl.key-alias: the alias that identifies the key in the key store.
  • server.ssl.key-password: the password used to access the key in the key store.

Configure Spring Security to require HTTPS requests

When using Spring Security, we can configure it to require automatically block any request coming from a non-secure HTTP channel.

In a Spring Boot 1 application, we can achieve that by setting the security.require-ssl property to true, without explicitly touching our Spring Security configuration class.

To achieve the same result in a Spring Boot 2 application, we need to extend the WebSecurityConfigurerAdapter class, since the security.require-ssl property has been deprecated.

@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .requiresChannel()
            .anyRequest()
            .requiresSecure();
    }
}
SecurityConfig.java (Spring Boot 2)

For more information about how to configure SSL in Spring Boot, you can have a look at the Reference Guide. If you want to find out which properties are available to configure SSL, you can refer to the definition in the code-base.

Congratulations! You have successfully enabled HTTPS in your Spring Boot application! Give it a try: run the application, open your browser and check if everything works as it should.

3. Redirect HTTP requests to HTTPS

Now that we have enabled HTTPS in our Spring Boot application and blocked any HTTP request, we want to redirect all traffic to HTTPS.

Spring allows defining just one network connector in application.properties (or application.yml). Since we have used it for HTTPS, we have to set the HTTP connector programmatically for our Tomcat web server.

The implementations for Spring Boot 1 and Spring Boot 2 are almost the same. The only difference is that some classes for server configuration have been renamed in Spring Boot 2.

Configuring Tomcat for Spring Boot 1

@Configuration
public class ServerConfig {
  
  @Bean
  public EmbeddedServletContainerFactory servletContainer() {
    TomcatEmbeddedServletContainerFactory tomcat = new TomcatEmbeddedServletContainerFactory() {
      @Override
      protected void postProcessContext(Context context) {
        SecurityConstraint securityConstraint = new SecurityConstraint();
        securityConstraint.setUserConstraint("CONFIDENTIAL");
        SecurityCollection collection = new SecurityCollection();
        collection.addPattern("/*");
        securityConstraint.addCollection(collection);
        context.addConstraint(securityConstraint);
      }
    };
    tomcat.addAdditionalTomcatConnectors(getHttpConnector());
    return tomcat;
  }
  
  private Connector getHttpConnector() {
    Connector connector = new Connector("org.apache.coyote.http11.Http11NioProtocol");
    connector.setScheme("http");
    connector.setPort(8080);
    connector.setSecure(false);
    connector.setRedirectPort(8443);
    return connector;
  }
}
ServerConfig.java (Spring Boot 1)

Configuring Tomcat for Spring Boot 2

@Configuration
public class ServerConfig {

    @Bean
    public ServletWebServerFactory servletContainer() {
        TomcatServletWebServerFactory tomcat = new TomcatServletWebServerFactory() {
            @Override
            protected void postProcessContext(Context context) {
                SecurityConstraint securityConstraint = new SecurityConstraint();
                securityConstraint.setUserConstraint("CONFIDENTIAL");
                SecurityCollection collection = new SecurityCollection();
                collection.addPattern("/*");
                securityConstraint.addCollection(collection);
                context.addConstraint(securityConstraint);
            }
        };
        tomcat.addAdditionalTomcatConnectors(getHttpConnector());
        return tomcat;
    }

    private Connector getHttpConnector() {
        Connector connector = new Connector(TomcatServletWebServerFactory.DEFAULT_PROTOCOL);
        connector.setScheme("http");
        connector.setPort(8080);
        connector.setSecure(false);
        connector.setRedirectPort(8443);
        return connector;
    }
}
ServerConfig.java (Spring Boot 2)

4. Distribute the SSL certificate to clients

When using a self-signed SSL certificate, our browser won’t trust our application and will warn the user that it’s not secure. And that’ll be the same with any other client.

It’s possible to make a client trust our application by providing it with our certificate.

Extract an SSL certificate from a keystore

We have stored our certificate inside a keystore, so we need to extract it. Again, keytool supports us very well:

keytool -export -keystore keystore.jks -alias tomcat -file myCertificate.crt

The keystore can be in JKS or PKCS12 format. During the execution of this command, keytool will ask us for the keystore password that we set at the beginning of this tutorial (the extremely secure password).

Now we can import our certificate into our client. Later, we’ll see how to import the certificate into the JRE in case we need it to trust our application.

Make a browser trust an SSL certificate

When using a keystore in the industry-standard PKCS12 format, we should be able to use it directly without extracting the certificate.

I suggest you check the official guide on how to import a PKCS12 file into your specific client. On macOS, for example, we can directly import a certificate into the Keychain Access (which browsers like Safari, Chrome and Opera rely on to manage certificates).

If deploying the application on localhost, we may need to do a further step from our browser: enabling insecure connections with localhost.

In Firefox, we are shown an alert message. To access the application, we need to explicitly define an exception for it and make Firefox trust the certificate.

In Chrome, we can write the following URL in the search bar: chrome://flags/#allow-insecure-localhost and activate the relative option.

Import an SSL certificate inside the JRE keystore

To make the JRE trust our certificate, we need to import it inside cacerts: the JRE trust store in charge of holding all certificates that can be trusted.

First, we need to know the path to our JDK home. A quick way to find it, if we are using Eclipse or STS as our IDE, is by going to Preferences > Java > Installed JREs. If using IntelliJ IDEA, we can access this information by going to Project Structure > SDKs and look at the value of the JDK home path field.

On macOS, it could be something like /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home. In the following, we’ll refer to this location by using the placeholder $JDK_HOME.

Then, from our Terminal prompt, let’s insert the following command (we might need to run it with administrator privileges by prefixing it with sudo):

keytool -importcert -file myCertificate.crt -alias tomcat -keystore $JDK_HOME/jre/lib/security/cacerts

We’ll be asked to input the JRE keystore password. If you have never changed it, it should be the default one: changeit or changeme, depending on the operating system. Finally, keytool will ask if you want to trust this certificate: let’s say yes.

If everything went right, we’d see the message Certificate was added to keystore. Great!

Conclusion

In this tutorial, we have seen how to generate a self-signed SSL certificate, how to import an existing certificate into a keystore, how to use it to enable HTTPS inside a Spring Boot application, how to redirect HTTP to HTTPS and how to extract and distribute the certificate to clients.

On GitHub, you can find the source code for the application we have built in this tutorial.

If you want to protect the access to some resources of your application, consider using Keycloak for the authentication and authorization of the users visiting your Spring Boot or Spring Security application.

Posted on

Code-First Java Module System Tutorial

The Java Platform Module System (JPMS) brings modularization to Java and the JVM and it changes how we program in the large. To get the most out of it, we need to know it well, and the first step is to learn the basics. In this tutorial I’ll first show you a simple Hello World example and then we’ll take an existing demo application and modularize it with Java 9. We will create module declarations ( module–info.java) and use the module path to compile, package, and run the application – code first, explanations second, so you can cut to the chase.

I use two projects in this tutorial and both can be found on GitHub: The first is a very simple Hello World example, the other the ServiceMonitor, which is the same one I use in my book on the module system. Check them out if you want to take a closer look. All commands like javac, jar, and java refer to the Java 9 variants.

Hello, Modular World

Let’s start with the simplest possible application, one that prints Hello, modular World! Here’s the class:

To become a module, it needs a module–info.java in the project’s root source directory:

With the common src/main/java directory structure, the program’s directory layout looks as follows:

These are the commands to compile, package and launch it:

Very similar to what we would have done for a non-modular application, except we’re now using something called a “module path” and can define the project’s main class (without a manifest). Let’s see how that works.

Modules

Modules are like JARs with additional characteristics

The basic building block of the JPMS are modules (surprise!). Like JARs, they are a container for types and resources; but unlike JARs, they have additional characteristics – these are the most fundamental ones:

  • a name, preferably one that is globally unique
  • declarations of dependencies on other modules
  • a clearly defined API that consists of exported packages

The JDK was split into about a hundred so-called platform modules. You can list them with java —list–modules and look at an individual module with java —describe–module ${module}. Go ahead, give it a try with java.sql or java.logging:

A module’s properties are defined in a module declaration, a file module–info.java in the project’s root, which looks as follows:

It gets compiled into a module–info.class, called module descriptor, and ends up in the JAR’s root. This descriptor is the only difference between a plain JAR and a modular JAR.

Let’s go through the three module properties one by one: name, dependencies, exports.

Name

The most basic property that JARs are missing is a name that compiler and JVM can use to identify it with. It is hence the most prominent characteristic of a module. We will have the possibility and even the obligation to give every module we create a name.

The best name for a module is the reverse-domain naming scheme that is already commonly used for packages

Naming a module will often be pretty natural as most tools we use on a daily basis, be it IDEs, build tools, or even issue trackers and version control systems, already have us name our projects. But while it makes sense to take that name as a springboard on the search for a module name, it is important to choose wisely!

The module system leans heavily on a module’s name. Conflicting or evolving names in particular cause trouble, so it is important that the name is:

  • globally unique
  • stable

The best way to achieve that is the reverse-domain naming scheme that is already commonly used for packages:

Dependencies And Readability

All dependencies have to be made explicit with requires directives

Another thing we missed in JARs was the ability to declare dependencies, but with the module system, these times are over: Dependencies have to be made explicit – all of them, on JDK modules as well as on third-party libraries or frameworks.

Dependencies are declared with requires directives, which consist of the keyword itself followed by a module name. When scanning modules, the JPMS builds a readability graph, where modules are nodes and requires directives get turned into so-called readability edges – if module org.codefx.demo.jpms requires module java.base, then at runtime org.codefx.demo.jpms reads java.base.

The module system will throw an error if it cannot find a required module with the right name, which means compiling as well as launching an application will fail if modules are missing. This achieves reliable configuration one of the goals of the module system, but can be prohibitively strict – check my post on optional dependencies to see a more lenient alternative.

All types the Hello World example needs can be found in the JDK module java.base, the so-called base module. Because it contains essential types like Object, all Java code needs it and so it doesn’t have to be required explicitly. Still, I do it in this case to show you a requires directive:

Exports And Accessibility

A module’s API is defined by its exports directives

A module lists the packages it exports. For code in one module (say org.codefx.demo.jpms) to access types in another (say String in java.base), the following accessibility rules must be fulfilled:

  • the accessed type ( String) must be public
  • the package containing the type ( java.lang) must be exported by its module (java.base)
  • the accessing module (org.codefx.demo.jpms) must read the accessed one (java.base), which is typically achieved by requiring it

Reflection lost its superpowers

If any of these rules are violated at compile or run time, the module systems throws an error. This means that public is no longer really public. A public type in a non-exported package is as inaccessible to the outside world as a non-public type in an exported package. Also note that reflection lost its superpowers. It is bound by the exact same accessibility rules unless command line flags are used.

Since our example has no meaningful API, no outside code needs to access it and so we don’t actually have to export anything. Once again I’ll do it nonetheless for demonstration purposes:

Module Path

We now know how we can define modules and their essential properties. What’s still a little unclear is how exactly we tell the compiler and runtime about them. The answer is a new concept that parallels the class path:

The module path is a list whose elements are artifacts or directories that contain artifacts. Depending on the operating system, module path elements are either separated by : (Unix-based) or ; (Windows). It is used by the module system to locate required modules that are not found among the platform modules. Both javac and java as well as other module-related commands can process it – the command line options are —module–path and –p.

All artifacts on the module path are turned into modules. This is even true for plain JARs, which get turned into automatic modules.

Compiling, Packaging, Running

Compiling works much like without the module system:

(You of course have to replace ${source–files} with an actual enumeration of the involved files, but that crowds the examples, so I don’t do it here.)

The module system kicks in as soon as a module–info.java is among the source files. All non-JDK dependencies the module under compilation requires need to be on the module path. For the Hello World example, there are no such dependencies.

Packaging with jar is unchanged as well. The only difference is that we no longer need a manifest to declare an application’s entry point – we can use —main–class for that:

Finally, launching looks a little different. We use the module path instead of the class path to tell the JPMS where to find modules. All we need to do beyond that is to name the main module with —module:

And that’s it! We’ve created a very simple, but nonetheless modular Hello-World application and successfully build and launched it. Now it’s time to turn to a slightly less trivial example to see mechanisms like dependencies and exports in action.

The ServiceMonitor

Let’s imagine a network of services that cooperate to delight our users; maybe a social network or a video platform. We want to monitor those services to determine how healthy the system is and spot problems when they occur (instead of when customers report them). This is where the example application, the ServiceMonitor comes in: It monitors these services (another big surprise).

As luck would have it, the services already collect the data we want, so all the ServiceMonitor needs to do is query them periodically. Unfortunately not all services expose the same REST API – two generations are in use, Alpha and Beta. That’s why ServiceObserver is an interface with two implementations.

Once we have the diagnostic data, in the form of a DiagnosticDataPoint, they can be fed to a Statistician, which aggregates them to Statistics. These, in turn, are stored in a StatisticsRepository as well as made available via REST by MonitorServer. The Monitor class ties everything together.

All in all, we end up with these types:

  • DiagnosticDataPoint: service data for a time interval
  • ServiceObserver: interface for service observation that returns DiagnosticDataPoint
  • AlphaServiceObserver and BetaServiceObserver: each observes a variant of services
  • Statistician: computes Statistics from DiagnosticDataPoint
  • Statistics: holds the computed statistics
  • StatisticsRepository: stores and retrieve Statistics
  • MonitorServer: answers REST calls for the statistics
  • Monitor: ties everything together

The application depends on the Spark micro web framework and we reference it by the module name spark.core. It can be found in the libs directory together with its transitive dependencies.

With what we learned so far, we already know how to organize the application as a single module. First, we create the module declaration module–info.java in the project’s root:

Note that we should choose a module name like org.codefx.demo.monitor, but that would crowd the examples, so I’ll stick to the shorter monitor. As explained, it requires spark.core and because the application has no meaningful API, it exports no packages.

We can then compile, package, and run it as follows:

As you can see, we no longer use Maven’s target directory and instead create classes in classes and modules in mods. This makes the examples easier to parse. Note that unlike earlier, we already have to use the module path during compilation because this application has non-JDK dependencies.

And with that we’ve created a single-module ServiceMonitor!

Splitting Into Modules

Now that we got one module going, it’s time to really start using the module system and split the ServiceMonitor up. For an application of this size it is of course ludicrous to turn it into several modules, but it’s a demo, so here we go.

The most common way to modularize applications is a separation by concerns. ServiceMonitor has the following, with the related types in parenthesis:

  • collecting data from services ( ServiceObserver, DiagnosticDataPoint)
  • aggregating data into statistics ( Statistician, Statistics)
  • persisting statistics ( StatisticsRepository)
  • exposing statistics via a REST API ( MonitorServer)

But not only the domain logic generates requirements. There are also technical ones:

  • data collection must be hidden behind an API
  • Alpha and Beta services each require a separate implementation of that API ( AlphaServiceObserver and BetaServiceObserver)
  • orchestration of all concerns ( Monitor)

This results in the following modules with the mentioned publicly visible types:

  • monitor.observer ( ServiceObserver, DiagnosticDataPoint)
  • monitor.observer.alpha ( AlphaServiceObserver)
  • monitor.observer.beta ( BetaServiceObserver)
  • monitor.statistics ( Statistician, Statistics)
  • monitor.persistence ( StatisticsRepository)
  • monitor.rest ( MonitorServer)
  • monitor ( Monitor)

Superimposing these modules over the class diagram, it is easy to see the module dependencies emerge:

Reorganizing Source Code

A real-life project consists of myriad files of many different types. Obviously, source files are the most important ones but nonetheless only one kind of many – others are test sources, resources, build scripts or project descriptions, documentation, source control information, and many others. Any project has to choose a directory structure to organize those files and it is important to make sure it does not clash with the module system’s characteristics.

If you have been following the module system’s development under Project Jigsaw and studied the official quick start guide or some early tutorials, you might have noticed that they use a particular directory structure, where there’s a src directory with a subdirectory for each project. That way ServiceMonitor would look as follows:

This results in a hierarchy concern/module and I don’t like it. Most projects that consist of several sub-projects (what we now call modules) prefer separate root directories, where each contains a single module’s sources, tests, resources, and everything else mentioned earlier. They use a hierarchy module/concern and this is what established project structures provide.

The default directory structure, implicitly understood by tools like Maven and Gradle, implement that hierarchy. First and foremost, they give each module its own directory tree. In that tree the src directory contains production code and resources (in main/java and main/resources, respectively) as well as test code and resources (in test/java and test/resources, respectively):

I will organize the ServiceMonitor almost like that, with the only difference that I will create the bytecode in a directory classes and JARS in a directory mods, which are both right below ServiceMonitor, because that makes the scripts shorter and more readable.

Let’s now see what those declarations infos have to contain and how we can compile and run the application.

Declaring Modules

We’ve already covered how modules are declared using module–info.java, so there’s no need to go into details. Once you’ve figured out how modules need to depend on one another (your build tool should know that; otherwise ask JDeps), you can put in requires directives and the necessary exports emerge naturally from imports across module boundaries.

By the way, you can use JDeps to create an initial set of module declarations. Whether created automatically or manually, in a real-life project you should verify whether your dependencies and APIs are as you want them to be. It is likely that over time, some quick fixes introduced relationships that you’d rather get rid of. Do that now or create some backlog issues.

Compiling, Packaging, And Running

Very similar to before when it was only a single module, but more often:

Congratulations, you’ve got the basics covered! You now know how to organize, declare, compile, package, and launch modules and understand what role the module path, the readability graph, and modular JARs play.

On The Horizon

If you weren’t so damn curious this post could be over now, but instead I’m going to show you a few of the more advanced features, so you know what to read about next.

Implied Readability

The ServiceMonitor module monitor.observer.alpha describes itself as follows:

Instead it should actually do this:

Spot the transitive in there? It makes sure that any module reading monitor.observer.alpha also reads monitor.observer. Why would you do that? Here’s a method from alpha‘s public API:

It returns an Optional<ServiceObserver>, but ServiceObserver comes from the monitor.observer module – that means every module that wants to call alpha‘s createIfAlphaService needs to read monitor.observer as well or such code won’t compile. That’s pretty inconvenient, so modules like alpha that use another module’s type in their own public API should generally require that module with the transitive modifier.

There are more uses for implied readability.

Optional Dependencies

This is quite straight-forward: If you want to compile against a module’s types, but don’t want to force its presence at runtime you can mark your dependency as being optional with the static modifier:

In this case monitor seems to be ok with the alpha and beta observer implementations possibly being absent and it looks like the REST endpoint is optional, too.

There are a few things to consider when coding against optional dependencies.

Qualified Exports

Regular exports have you make the decision whether a package’s public types are accessible only within the same module or to all modules. Sometimes you need something in between, though. If you’re shipping a bunch of modules, you might end up in the situation, where you’d like to share code between those modules but not outside of it. Qualified exports to the rescue!

This way only monitor and monitor.statistics can access the monitor.util package.

Open Packages And Modules

I said earlier that reflection’s superpowers were revoked – it now has to play by the same rules as regular access. Reflection still has a special place in Java’s ecosystem, though, as it enables frameworks like Hibernate, Spring and so many others.

The bridge between those two poles are open packages and modules:

An open package is inaccessible at compile time (so you can’t write code against its types), but accessible at run time (so reflection works). More than just being accessible, it allows reflective access to non-public types and members (this is called deem reflection). Open packages can be qualified just like exports and open modules simply open all their packages.

Services

Instead of having the main module monitor depend on monitor.observer.alpha and monitor.observer.beta, so it can create instances of AlphaServiceObserver and BetaServiceObserver, it could let the module system make that connection:

This way, monitor can do the following to get an instance of each provided observer factory:

It uses the ServiceLoader API, which exists since Java 6, to inform the module system that it needs all implementations of ServiceObserverFactory. The JPMS will then track down all modules in the readability graph that provide that service, create an instance of each and return them.

There are two particularly interesting consequences:

  • the module consuming the service does not have to require the modules providing it
  • the application can be configured by selecting which modules are placed on the module path

Services are a wonderful way to decouple modules and its awesome that the module system gives this mostly ignored concept a second life and puts it into a prominent place.

Reflection

Ok, we’re really done now and you’ve learned a lot. Quick recap:

  • a module is a run-time concept created from a modular JAR
  • a modular JAR is like any old plain JAR, except that it contains a module descriptor module–info.class, which is compiled from a module declaration module–info.java
  • the module declaration gives a module its name, defines its dependencies (with requires, requires static, and requires transitive) and API (with exports and exports to), enables reflective access (with open and opens to) and declares use or provision of services
  • modules are placed on the module path where the JPMS finds them during module resolution, which is the phase that processes descriptors and results in a readability graph

If you want to learn more about the module system, read the posts I linked above, check the JPMS tag, or get my book The Java Module System (Manning). Also, be aware that migrating to Java 9 can be challenging – check my migration guide for details.

Posted on

Aumentare la visibilita del sito

Ti stai chiedendo come aumentare visibilità sito  sui motori di ricerca ma non sai come fare, oppure sei alla ricerca di strategie nuove ed efficaci? Tutto quello che devi fare è dedicare 5 minuti del tuo tempo alla lettura di questa pagina.

Quelle che ti descriverò di seguito sono alcune efficaci strategie che se attuate congiuntamente ti permetteranno di aumentare il tuo posizionamento online in modo significativo.

Ricorda tuttavia che aumentare visibilità sito  si può, ma ciò è legato a svariati fattori variabili nel tempo. La definizione e implementazione del giusto mix di strategie da adottare è quindi il risultato di una costante pratica ed esperienza.

Aumentare visibilità sito: SEO/SEM

Aumentare visibilità sito è un’attività legata intimamente a due discipline: il search engine optimization (SEO) e il search engine marketing (SEM). L’attuazione efficace di tecniche e metodologie SEO/SEM permette infatti di: verificare posizionamento sito; aumentare traffico sito e aumentare le visite al sito web.

Attraverso l’adozione di strategie SEO sarà possibile migliorare il posizionamento sui motori di ricerca e quindi aumentare visibilità sito su google gratis, mentre con il SEM l’aumento di visibilità immediata è legata all’acquisto di pubblicità a pagamento o all’adesione a campagne PPC (pay-per-click). Il SEM è quindi indicato per una strategia di breve termine mentre il SEO di medio-lungo termine.

Il Seo ed il Sem si basano interamente su delle singole parole chiave (keyword) o un gruppo di parole (long tail), inserite nei motori di ricerca o search engine. Ricercare e capire quali keywords gli utenti utilizzano per raggiungere un sito keyword research è fondamentale per attuare strategie SEO o campagne SEM finalizzate all’incremento della visibilità del sito stesso.

Strategie SEO

Google è il principale motore di ricerca e sono circa 200 i fattori di ranking che i suoi algoritmi valutano al fine di stabilire una gerarchia tra pagine per una data ricerca. Gli algoritmi vengono però costantemente aggiornati (Panda, Penguin, Pigeon, Hummingbird, Mobilegeddon, Fred, RankBrain). Escludendo dal prendere in considerazione attività di blackhat seo (acquisto di link, link stuffing, ecc.) per aumentare visite sito, si riportano alcuni fattori di seo on-page e seo off-page utili al posizionamento seo sui motori di ricerca:

  1. Tag Title: Google da molto peso alle parole poste all’inizio del Tag Title (H1), per cui includi strategicamente la tua parola chiave o focus keyword all’inizio del Titolo della tua pagina/articolo, ma anche negli H2 e H3 (sottotitoli).
  2. Url seo friendly: usa degli URL brevi e semplici da ricordare che includano la tua focus keyword (es. https://www.miosito.it/aumentare visibilità sito)
  3. Uso multimedia: usa differenti formati di multimedia (foto, video, infografiche, ecc.) nei post che pubblichi facendo però attenzione a non “appesantire” la pagina/sito
  4. Link esterni: includi almeno due link esterni a siti la cui autorità è riconosciuta (siti istituzionali, blog popolari, siti d’informazione o culturali governativi, ecc.)
  5. Velocità sito web: la velocità di caricamento della tua pagina o sito web non è un cruciale fattore di ranking ma ha una sua valenza. Occorrerà perciò ottimizzare anche: immagini, CSS, Java script, flash è ecc. In rete vi sono svariati tool per monitore la velocità tra i quali segnaliamo GTMetrix, Google Page speed insight e YSlow
  6. Bottoni social: assicurati che nel tuo sito siano presenti dei bottoni di condivisione (share buttons) relativi ai principali social media
  7. Link interni: ricordati di aggiungere al nuovo post da pubblicare 2-3 link interni riferiti ad articoli/pagine precedentemente pubblicati
  8. Ottimizzazione immagini: inserire la parola chiave nel tag alt text dell’immagine ti permetterà di aumentare visibilità sito e traffico dal motore di ricerca immagini di Google
  9. Link building o Link earning: questa strategia consiste nella creazione di backlinks, che non sono altro che link di qualità verso il tuo sito provenienti da altri siti Web. Questi vengono considerati da Google come un indice di qualità dei tuoi contenuti. Ricevere molti backlinks attribuisce quindi  “autorevolezza” e “popolarità” al tuo sito favorendone indicizzazione. Ci sono essenzialmente due modi per generare backlinks:

–  attuare un’efficace campagna di pubbliche relazioni digitali o Digital Pr al fine di ottenere da altri proprietari di blog/siti web e
social media influencer la creazione di link verso i contenuti del tuo sito
–  creare dei contenuti rilevanti che riescono a generare curiosità, interesse e favoriscano la creazione naturale di link verso il tuo
sito (link baiting)

Come vedi, migliorare sito internet, attraverso il SEO è un argomento ampio ed in continuo aggiornamento, per approfondimenti si consiglia pertanto di leggere il nostro articolo sul tema.

Articolo SEO

Strategie SEM e Display Advertising

Il SEM è il processo di guadagnare traffico e visibilità sui motori di ricerca attraverso azioni a pagamento, come ad esempio l’acquisto di link (poco ben visto da Google), l’acquisto di spazi pubblicitari su siti rilevanti, o l’adesione a campagne di Pay per Click come Google Adwords. Per gli annunci di tipo search, infatti Google mette a disposizione le prime 4 e le ultime 3 posizioni in ogni pagina della SERP. In questo modo Google garantire agli inserzionisti di aumentare visibilità sito in modo immediato ma non in modo gratuito.

Il sistema su cui si basa Adwords è un sistema ad asta: l’inserzionista fa un offerta per la keyword o una keyphrase per cui vuole che esca il suo annuncio. In base alle offerte ricevute per una keyword è assegnato a ciascun annuncio un punteggio di qualità. Adwords bandisce l’asta in tempo reale.

Il metodo di pagamento per l’inserzionista varia a seconda del tipo di annuncio: in metodo più diffuso è quello del cost per click (CPC), ossia l’inserzionista paga ogni volta che riceve un click sul suo annuncio.

Per approfondire scarica la miniguida SEM!

Migliorare sito internet: crea e/o invia una Sitemap

Una Sitemap è una lista ordinata di tutte le pagine di un sito che si vuole vengono indicizzate da un motore di ricerca. Per aumentare visibilità sito è sicuramente un’ottima cosa aiutare i bot/spider/robots/crawler dei motori di ricerca a trovare e capire di cosa trattano tutte le pagine del tuo sito Web. L’invio di una sitemap è particolarmente importante se:

  • Il tuo sito a contenuti dinamici
  • il tuo sito a pagine che non sono facili da trovare dai bots (per esempio pagine con Rich AJAX o immagini)
  • il tuo sito contiene delle pagine con dei link che non “lincano” correttamente ad un’altra pagina.

Puoi creare la sitemap del tuo sito manualmente tramite RSS feed o tramite strumenti come Google search console (come creare ed inviare una sitemap con search console)

Aumentare visibilità sito gratis: crea contenuti di qualità, unici e facili da condividere

Scrivere dei contenuti di qualità, unici e rilevanti per un business è (come abbiamo visto in precedenza) molto importante sia per guadagnare dei backlinks sia per attribuire reputazione, autorevolezza e popolarità al nostro sito. Creare dei contenuti facili da condividere sulle piattaforme social attraverso i social buttons non contribuisce direttamente ad aumentare visibilità sito .

Tuttavia lo fa indirettamente poiché la condivisione dei contenuti sui social aumenta la possibilità di ricevere dei backlinks, che sappiamo essere un fattore che favorisce il ranking di un sito web.

La scrittura sul Web per essere efficace deve però seguire delle precise regole che riguardano forma, stile e contenuto, che ci vengono fornite dal SEO copywriting. A queste vanno associate anche delle tecniche di persuasione applicate al marketing, che provengono da una nuova area di studi: il neuromarketing.

Posizionamento online: individua ed elimina problemi ed errori

Un sito Web, specie se di grosse dimensioni, potrebbe essere sottoposto a errori e piccoli problemi di vario genere. Questi accumulandosi nel tempo possono iniziare a causare dei problemi tanto gravi da ridurre anziché aumentare visibilità sito. Attraverso strumenti come SEMRush o Raven Tools è possibile sanare questa condizione riconducibile solitamente a:

  • Duplicazione o assenza del tag title
  • link rotti (Broken links)
  • Immagini prive del testo alternativo o alt text
  • Pagine bloccate dai robots.text
  • Redirect di tipo 302 che dovrebbero essere di tipo 301 (scopri come fare un redirect)

Scopri come diventare un SEO Specialist

Migliorare ricerca Google: imposta strumenti di web analytics

Un’altra efficace strategia da adottare per aumentare visibilità sito  è quella che prevede l’adozione di tecnologie e metodologie di Web Analytics. Queste permettono di monitorare tutte le attività di SEO/SEM e di web marketing implementate permettendo di raccogliere un enorme numero di dati dalla cui elaborazione è possibile ricavare preziose informazioni su come ottimizzare le performance del sito web, dell’app o della piattaforma social che si sta gestendo. Gran parte dei processi di web analytics prevedono e si sviluppano in quattro fasi essenziali:

  • Raccolta dei dati online
  • L’analisi delle informazione raccolte attraverso opportune metriche
  • L’individuazione dei KPI
  • La creazione di una strategia on-line

Lo strumento più utilizzato per la web analytics è Google Analytics. Si tratta di una piattaforma gratuita (anche se esiste una versione a pagamento) la cui installazione consiste in un piccolo frammento di codice Javascript che deve essere collocato all’interno del tuo sito web. Altri strumenti molto noti sono Alexa ed i vari Twitter analytics e Facebook insights.

Se ti piace fare digital marketing e vorresti trasformare la tua passione in un lavoro ti consiglio di dare uno sguardo alla guida su come cercare aziende che assumono nel marketing digitale.

Aumentare visibilità sito: verifica l’andamento nel tempo

Un’altra strategia da attuare al fine di aumentare la visibilità del sito  è quella di collegare quest’ultimo a Google Search Console. Si tratta di un servizio gratuito offerto da Google che oltre a creare ed inviare la sitemap di un sito permette di:

  • Controllare importanti backlinks al tuo sito
  • verificare che Google non stia sperimentando dei problemi di indicizzazione con il tuo sito
  • rilevare quali sono gli intenti di ricerca (query) che portano traffico verso il tuo sito
  • verificare nel tempo il posizionamento del sito web sui motori di ricerca per vedere se vi è la necessità di attuare qualche accorgimento in più per migliorare il posizionamento online.

Oltre a search console potrai avvalerti anche di altri numerosi strumenti o tool e software per aumentare visite al sito, tra questi Trafficwave, Auto traffic generator e traffic programmer.

Visibilità su Google gratis: registrazione di un’attività a Google my business

Se il tuo sito Web ha finalità di business un modo per aumentare le visite al sito Web stesso è quello di registrare la tua attività su Google my business. Successore di Google Places, la registrazione a questa piattaforma permette di aumentare visibilità sito nei risultati di ricerca localizzati. Alla registrazione segue l’invio presso la tua attività di una lettera contenente un pin.

Questo invio consente a Google di verificare la collocazione geografica della tua attività. Dalla verificazione si ha così un’alta possibilità di apparire nei risultati di ricerca (e su Google Maps) di persone che stanno cercando un’attività come la tua nell’area in cui operi.

Conclusioni

Aumentare visibilità sito è un’attività complessa. Se hai necessità per il tuo business ma non vuoi farti assistere in questo processo da un professionista, valuta una soluzione molto più efficace e meno onerosa. Partecipa tu stesso ad uno dei corsi o master in aula o online proposti da Digital Coach per diventare: