Avoiding Wildcard imports in Java/Kotlin with IntelliJ

What is a wildcard import or a star import?

When you want to import multiple classes from the same package like this:

import com.example.exception.CustomerNotFoundExcetpion
import com.example.exception.ProductNotFoundExcetpion
import com.example.exception.ProductOutOfStockException
import com.example.exception.AdressNotFoundException

Java has an option to combine them into a single line using wildcard imports:

import com.example.exception.*

Is it bad?

Performance-wise, no. Using a wildcard import doesn’t actually import all the classes in the package. When your code is compiled, only the classes used from this package are added to the bytecode. So there is zero performance difference between wildcard import and explicit imports.

Then why should we avoid it?

  • Explicit imports clearly states what external classes the current class is directly using, provided that you don’t leave redundant imports in your code.
  • If there are two classes with the same name from different packages, it can introduce collision when using wildcard imports.
  • When multiple people are working in a project, wildcard imports can create confusion as to which classes are actually imported

Many large Java projects that I have worked with, have a checkstyle rule to disallow wildcard imports for the above reason.

Now that we have understood why explicit imports are better than implicit imports, let’s see how we can make IntelliJ always use explicit imports.

By default, IntelliJ will convert implicit imports into wildcard imports when it sees 5 import statements from the same package.

This setting can however by set to a large value like 99 to prevent the automatic wild card imports.

Goto Preferences -> Editor -> Code Style -> Java (or Kotlin) -> Update the following two values to 99:

  • Class count to use import with ‘*’
  • Names count to use static import

Also remove all the entries from the “Packages to Use Import with ‘*'” table.

Click ‘Apply’ and close the dialog. Now do ‘Optimize Imports’ again to remove the wildcard imports automatically now and in the future.

More ‘Import’ options can be customized with IntelliJ. Follow this link for more customizations:

The default Sun & Google’s Checkstyle rules also recommend avoiding star import by throwing this exception:

(imports) AvoidStarImport: Using the '.*' form of import should be avoided

To add this rule to your checkstyle configuration, add this line:

<module name="AvoidStarImport"/>

React: How to use Apollo with ‘Union Types’ in GraphQL

Apollo is one of the most popular React library to work with GraphQL APIs. However they don’t have native support when your APIs contain union types.

Let’s look at an example API that contains union types and how we can work with them using Apollo. Assuming you have an API like this:

  search(text: "an") {
    ... on Human {
    ... on Droid {
    ... on Starship {

that returns this response….

  "data": {
    "search": [
        "__typename": "Human",
        "name": "Han Solo",
        "height": 1.8
        "__typename": "Human",
        "name": "Leia Organa",
        "height": 1.5
        "__typename": "Starship",
        "name": "TIE Advanced x1",
        "length": 9.2

If you use the above query via Apollo, you will see this warning messages in the browser console:

You are using the simple (heuristic) fragment matcher, but your queries contain union or interface types. Apollo Client will not be able to accurately map fragments. To make this error go away, use the `IntrospectionFragmentMatcher` as described in the docs:

This is because Apollo by default uses a simple heuristics matching to match the response string into the Response object. We need to do some extra work to tell Apollo how to parse the response with union types.

Apollo has a separate section on their docs about this.

Step 1: Save the information about the fragment types in a separate file:

const fetch = require('node-fetch');
const fs = require('fs');

fetch(`${YOUR_API_HOST}/graphql`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    variables: {},
    query: `
        __schema {
          types {
            possibleTypes {
  .then(result => result.json())
  .then(result => {
    // here we're filtering out any type information unrelated to unions or interfaces
    const filteredData =
      type => type.possibleTypes !== null,
    ); = filteredData;
    fs.writeFile('./fragmentTypes.json', JSON.stringify(, err => {
      if (err) {
        console.error('Error writing fragmentTypes file', err);
      } else {
        console.log('Fragment types successfully extracted!');

The JSON file should look something like this:

  "__schema": {
    "types": [
        "kind": "UNION",
        "name": "UnionSearchDetails",
        "possibleTypes": [
            "name": "Human"
            "name": "Droid"
            "name": "Starship"

Step 2: Create fragmentMatcher using the JSON file from the previous step:

import { IntrospectionFragmentMatcher } from 'apollo-cache-inmemory';
import introspectionQueryResultData from './fragmentTypes.json';

const fragmentMatcher = new IntrospectionFragmentMatcher({

Step 3: Now include this fragmentMatcher in cache object and pass it to the Apollo client:

import ApolloClient from 'apollo-client';
import { InMemoryCache } from 'apollo-cache-inmemory';
import { HttpLink } from 'apollo-link-http';

// add fragmentMatcher code from step 2 here

const cache = new InMemoryCache({ fragmentMatcher });

const client = new ApolloClient({
  link: new HttpLink(),

Now all done. The warnings and errors that you noticed previously should have gone away and the Response object from Apollo should contain the correct data.

How to use ‘Union types’ in tests and storybooks?

Now that you have fixed the problem for production code, how can we fix it for your tests or storybooks?

Apollo provides MockedProvider for this purpose. Here is a sample:

<MockedProvider mocks={mocks} addTypename cache={cache}>
     <MyComponenent />

The important change here from the sample code is that addTypename has to be true, to allow Apollo to use the __typename in the response to map the object to the correct type.