TensorFlow
Xavier Initializer
tf.contrib.layers
Code Migration
TensorFlow Update

change tf.contrib.layers.xavier_initializer to 2.0.0

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

In TensorFlow 2, tf.contrib is gone, so tf.contrib.layers.xavier_initializer() must be replaced with supported initializers from tf.keras.initializers. Xavier initialization is still available, but it now appears under the Glorot name. The correct migration is usually GlorotUniform or GlorotNormal, depending on which distribution your old code expected.

Xavier and Glorot Mean the Same Family Here

What TensorFlow 1.x called Xavier initialization is generally referred to as Glorot initialization in the Keras APIs. The purpose is the same: initialize weights so that signal scale stays reasonable as activations move forward and gradients move backward.

Old TensorFlow 1.x style:

python
1weights = tf.compat.v1.get_variable(
2    "weights",
3    shape=[128, 64],
4    initializer=tf.contrib.layers.xavier_initializer()
5)

TensorFlow 2 replacement:

python
1import tensorflow as tf
2
3weights = tf.Variable(
4    tf.keras.initializers.GlorotUniform()(shape=(128, 64)),
5    name="weights"
6)

For many migrations, GlorotUniform is the closest direct replacement.

Use Keras Initializers in Layers

If the weights belong to a Keras layer, pass the initializer to the layer definition instead of creating variables manually.

python
1import tensorflow as tf
2
3model = tf.keras.Sequential(
4    [
5        tf.keras.layers.Dense(
6            64,
7            activation="relu",
8            kernel_initializer=tf.keras.initializers.GlorotUniform(),
9            input_shape=(128,),
10        )
11    ]
12)

This is the idiomatic TensorFlow 2 approach. Let the layer own the variable creation and the initializer.

Choose Between Uniform and Normal Carefully

The old xavier_initializer() usually maps most naturally to a Glorot uniform initializer, but there was also a normal variant in older APIs. If the original model depended on a normal-distributed Xavier initializer, use:

python
initializer = tf.keras.initializers.GlorotNormal()

Most migrations do not need to obsess over tiny distribution details, but if reproducibility matters, check which variant the old code actually used.

Migrating Graph-Style Code

Some projects still run TensorFlow 1.x style graph code through compatibility APIs. In that case, you can still use Keras initializers while keeping the variable creation pattern.

python
1import tensorflow as tf
2
3tf.compat.v1.disable_eager_execution()
4
5weights = tf.compat.v1.get_variable(
6    "weights",
7    shape=[128, 64],
8    initializer=tf.keras.initializers.GlorotUniform(),
9)

This is useful during staged migrations where the training loop is still graph-based even though tf.contrib has been removed.

Do Not Search for a Direct tf.contrib Substitute

A common migration mistake is trying to find a one-to-one tf.contrib namespace replacement. TensorFlow 2 moved away from that design. The better question is, "Which supported TensorFlow or Keras API now owns this concept?"

For Xavier initialization, the supported home is tf.keras.initializers, not a hidden compatibility alias.

Test the Migration, Not Just the Import

Replacing the initializer makes the code import again, but you should still test the actual training behavior:

  • does the model train with stable loss
  • does initialization shape match the layer shape
  • do saved checkpoints still load correctly where expected

A syntactic migration is only the first step. Initialization choices influence training dynamics, so the updated code should be validated in practice.

Common Pitfalls

  • Looking for a surviving tf.contrib import path instead of using tf.keras.initializers.
  • Replacing Xavier initialization without considering whether the old code expected a uniform or normal variant.
  • Creating variables manually in TensorFlow 2 when a Keras layer should own the initializer instead.
  • Treating successful import as proof that the migration preserved model behavior.
  • Mixing old graph-style code and new Keras APIs without checking shape and execution assumptions.

Summary

  • 'tf.contrib.layers.xavier_initializer() should usually be replaced with tf.keras.initializers.GlorotUniform().'
  • Use GlorotNormal() only if the old code specifically relied on a normal-distributed Xavier initializer.
  • In Keras layers, pass the initializer to the layer rather than creating variables by hand.
  • Compatibility mode can still use Keras initializers in graph-style code.
  • After migration, validate actual training behavior instead of stopping at import success.

Course illustration
Course illustration

All Rights Reserved.