{"title":"final Keyword","description":"","content":"The `final` keyword in Java is a small word with a big job: it tells the compiler that something cannot change after it's been set. The \"something\" can be a local variable, a method parameter, an instance field, a method, or even an entire class, and the rules shift a little for each one. This lesson walks through every flavor of `final` in Java, the exact rule it enforces, and the patterns where each one fits.\n\n---\n\n# The One-Line Rule\n\n`final` means **\"can only be assigned once\"** or **\"cannot be changed\"**, with the exact meaning depending on what it precedes.\n\n\n| Applied to | What gets locked |\n| --- | --- |\n| Local variable | Cannot be reassigned after its first value is set |\n| Method parameter | Cannot be reassigned inside the method body |\n| Instance field | Must be assigned exactly once, then cannot be reassigned |\n| Static field | Must be assigned exactly once, then cannot be reassigned |\n| Reference variable | The reference cannot point to a different object (the object itself can still mutate) |\n| Method | Cannot be overridden in a subclass |\n| Class | Cannot be extended by any subclass |\n\n\nEvery other rule about `final` in this lesson is a specialization of one of these rows. Keep this table in mind as we go. The interesting questions are usually \"what counts as 'assigned'?\" and \"what does 'cannot change' actually protect?\", not \"what does the word `final` mean?\"\n\n---\n\n# `final` Local Variables\n\nA local variable declared `final` can be assigned exactly once. The assignment can happen at the declaration or later in the same scope, but reassignment is a compile error.\n\n\n```java\npublic class FinalLocal {\n public static void main(String[] args) {\n final double taxRate = 0.07;\n double price = 100.0;\n double total = price + price * taxRate;\n System.out.println(\"Total: $\" + total);\n }\n}\n```\n\n\nHere `taxRate` is set at the declaration and never touched again. The `final` makes that promise explicit. A reader can scan the method and trust that `taxRate` stays `0.07` from declaration to return.\n\nAssignment at the declaration isn't required. A `final` local can be left without an initial value, as long as the compiler can prove every path assigns it exactly once before it's read.\n\n\n```java\npublic class FinalLocalDeferred {\n public static void main(String[] args) {\n final double shippingFee;\n int itemCount = 4;\n\n if (itemCount >= 3) {\n shippingFee = 0.0;\n } else {\n shippingFee = 5.99;\n }\n\n System.out.println(\"Shipping: $\" + shippingFee);\n }\n}\n```\n\n\nBoth branches of the `if` assign `shippingFee`, so by the time the `println` runs, the compiler is sure it's been set exactly once. That's enough.\n\nA second assignment is what the compiler refuses to accept.\n\n**What's wrong with this code?**\n\n\n```java\npublic class FinalReassignBad {\n public static void main(String[] args) {\n final int cartItemCount = 3;\n cartItemCount = 5; // compile error\n System.out.println(cartItemCount);\n }\n}\n```\n\n\nThe compiler reports:\n\n\n```shell\nerror: cannot assign a value to final variable cartItemCount\n cartItemCount = 5;\n ^\n```\n\n\n**Fix:** Drop the `final` if the value needs to change, or pick a different variable for the new value.\n\n\n```java\npublic class FinalReassignFixed {\n public static void main(String[] args) {\n final int initialItemCount = 3;\n int currentItemCount = initialItemCount;\n currentItemCount = 5;\n System.out.println(\"Started with \" + initialItemCount + \", now \" + currentItemCount);\n }\n}\n```\n\n\nThe original constant stays `final`. A separate, non-`final` variable tracks the changing value. Usually one of these two is the right intent.\n\n---\n\n# `final` Method Parameters\n\nA method parameter is a local variable that happens to receive its initial value from the caller. Marking it `final` prevents the method body from reassigning that variable.\n\n\n```java\npublic class FinalParam {\n public static double applyTax(final double subtotal, final double taxRate) {\n // subtotal = 0; // would be a compile error\n return subtotal + subtotal * taxRate;\n }\n\n public static void main(String[] args) {\n System.out.println(\"Total: $\" + applyTax(50.0, 0.07));\n }\n}\n```\n\n\nThe `final` here protects against a specific bug: code inside the method \"reusing\" a parameter to hold a different value, then reading it later as if it still held the caller's input. With `final`, that reuse fails at compile time, so the parameter always means what the parameter name says.\n\n`final` on a parameter is purely about the method body. It doesn't change anything for the caller. A caller passing `subtotal = 50.0` doesn't see any difference.\n\nIn practice, Java programmers don't sprinkle `final` on every parameter. Most teams reserve it for cases where it actively helps readability or where another language feature requires it (like accessing the parameter from an anonymous class or lambda). The compiler is happy either way.\n\n---\n\n# `final` Instance Fields\n\nA `final` instance field must be assigned exactly once. \"Once\" means exactly once on any path from object creation to use. The assignment can happen in three places:\n\n1. At the field declaration.\n2. Inside an instance initializer block.\n3. Inside every constructor of the class.\n\nThe compiler checks all three locations together. The rule it enforces is: by the time a constructor finishes, every `final` instance field must have been assigned exactly once.\n\n\n```java\npublic class Product {\n private final String productId;\n private final String name;\n private final double price;\n\n public Product(String productId, String name, double price) {\n this.productId = productId;\n this.name = name;\n this.price = price;\n }\n\n public String getProductId() { return productId; }\n public String getName() { return name; }\n public double getPrice() { return price; }\n\n public static void main(String[] args) {\n Product mouse = new Product(\"P-1001\", \"Wireless Mouse\", 29.99);\n System.out.println(mouse.getName() + \" ($\" + mouse.getPrice() + \")\");\n }\n}\n```\n\n\nAll three fields are assigned in the constructor. After the constructor returns, none of them can ever be reassigned. A `Product` built with `(\"P-1001\", \"Wireless Mouse\", 29.99)` holds those exact values for its entire life.\n\nThe fields that don't get an initial value at their declaration line are called **blank finals**. `productId`, `name`, and `price` above are all blank finals, because their declaration line gives only the type, not a value. Blank finals are useful when the value depends on the constructor arguments, which is most of the time for real data.\n\nA field that has an initial value at the declaration is also valid, just less flexible.\n\n\n```java\npublic class OrderConstants {\n private final int maxItemsPerOrder = 50;\n private final String currency = \"USD\";\n\n public int getMaxItemsPerOrder() { return maxItemsPerOrder; }\n public String getCurrency() { return currency; }\n\n public static void main(String[] args) {\n OrderConstants config = new OrderConstants();\n System.out.println(\"Max items: \" + config.getMaxItemsPerOrder());\n System.out.println(\"Currency: \" + config.getCurrency());\n }\n}\n```\n\n\nThese fields could also have been declared `static final` (covered below). The point: the assignment at the declaration counts as the one allowed assignment, and the constructor must not assign them again.\n\n**What's wrong with this code?**\n\n\n```java\npublic class BadProduct {\n private final String name;\n private final double price;\n\n public BadProduct(String name) {\n this.name = name;\n // price never assigned\n }\n}\n```\n\n\nThe compiler reports:\n\n\n```shell\nerror: variable price might not have been initialized\n public BadProduct(String name) {\n ^\n```\n\n\n**Fix:** Every constructor must assign every blank final field. Either give `price` a value at the declaration, or assign it in this constructor.\n\n\n```java\npublic class FixedProduct {\n private final String name;\n private final double price;\n\n public FixedProduct(String name) {\n this.name = name;\n this.price = 0.0;\n }\n\n public FixedProduct(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n```\n\n\nWith multiple constructors, the rule applies to each one independently. Each path that builds an object must assign every blank final exactly once.\n\n---\n\n# `final` on a Reference Variable\n\nThis is the part of `final` most easily misunderstood. When a `final` variable holds a reference to an object, the lock applies to the **reference** (the arrow), not to the **object** (the thing the arrow points to). The reference can't be made to point somewhere else. The object itself is still free to change its internal state, if its class allows mutation.\n\n\n```mermaid\nflowchart LR\n Box[\"final List items
(the variable / box)\"]:::cyan\n Arrow{{\"reference
locked by final\"}}:::orange\n Obj[\"ArrayList object
(state CAN change)\"]:::green\n\n Box --> Arrow --> Obj\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe `final` modifier locks the arrow from `items` to the `ArrayList`. The contents of the `ArrayList` are a completely separate question.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class FinalReference {\n public static void main(String[] args) {\n final List cart = new ArrayList<>();\n\n cart.add(\"Wireless Mouse\");\n cart.add(\"USB Cable\");\n cart.add(\"Headphones\");\n\n System.out.println(\"Cart size: \" + cart.size());\n System.out.println(\"Cart: \" + cart);\n\n // cart = new ArrayList<>(); // would be a compile error\n }\n}\n```\n\n\n`cart` is `final`, but calling `cart.add(...)` works fine. The `add` calls mutate the `ArrayList` that `cart` points to. They don't change which list `cart` points to. The only thing `final` forbids is `cart = somethingElse`.\n\nThat distinction matters because `final` is sometimes expected to \"freeze\" the object. It doesn't. To make the object's state unchangeable too, use either an unmodifiable wrapper (like `List.copyOf(...)`) or an immutable class. The rule to carry forward:\n\n\n> **INFO**\n>\n> **`final` on a reference locks the variable, not the object.**\n\n\n**What's wrong with this code?**\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class FrozenCart {\n public static void main(String[] args) {\n final List cart = new ArrayList<>();\n cart.add(\"Wireless Mouse\");\n\n cart = new ArrayList<>(); // expecting this to be allowed\n cart.add(\"USB Cable\");\n }\n}\n```\n\n\nThe error is on the second-to-last line:\n\n\n```shell\nerror: cannot assign a value to final variable cart\n cart = new ArrayList<>();\n ^\n```\n\n\n**Fix:** For a fresh empty list, clear the existing one instead of reassigning. The reference stays the same, but the contents become empty.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class FrozenCartFixed {\n public static void main(String[] args) {\n final List cart = new ArrayList<>();\n cart.add(\"Wireless Mouse\");\n\n cart.clear();\n cart.add(\"USB Cable\");\n\n System.out.println(\"Cart: \" + cart);\n }\n}\n```\n\n\nIf a different list is actually needed (perhaps because the old one is shared with something else), then `final` was the wrong choice and should be removed.\n\n---\n\n# `final` Methods\n\nA `final` method cannot be overridden by any subclass. The keyword sits on the method declaration, like this:\n\n\n```java\npublic class PaymentProcessor {\n public final double calculateTotal(double subtotal, double taxRate) {\n return subtotal + subtotal * taxRate;\n }\n}\n```\n\n\nA subclass can still inherit and call `calculateTotal`, but it can't replace it with its own version. Trying to override it produces a compile error.\n\nThe intent of `final` on a method is to say: \"this behavior is part of the class's contract, and subclasses shouldn't change it.\" A common case is methods that perform security or correctness checks. If a subclass could override `validateOrder` to skip a step, the protection would be optional. `final` removes that option.\n\n\n```java\npublic class OrderValidator {\n public final boolean isValidOrder(int itemCount, double total) {\n return itemCount > 0 && total > 0;\n }\n\n public static void main(String[] args) {\n OrderValidator validator = new OrderValidator();\n System.out.println(\"Valid: \" + validator.isValidOrder(3, 89.97));\n System.out.println(\"Empty cart valid: \" + validator.isValidOrder(0, 0.0));\n }\n}\n```\n\n\nWithout a subclass, the `final` doesn't do anything visible. The protection only matters once someone tries to extend `OrderValidator`.\n\n---\n\n# `final` Classes\n\nA `final` class cannot be extended. No subclass can inherit from it. The keyword sits between the access modifier and `class`.\n\n\n```java\npublic final class ProductId {\n private final String value;\n\n public ProductId(String value) {\n this.value = value;\n }\n\n public String getValue() {\n return value;\n }\n\n public static void main(String[] args) {\n ProductId id = new ProductId(\"P-1001\");\n System.out.println(\"ID: \" + id.getValue());\n }\n}\n```\n\n\nWriting `class CustomProductId extends ProductId { ... }` fails to compile with `cannot inherit from final ProductId`.\n\n`final` on a class is a stronger statement than `final` on individual methods. Marking each method `final` only prevents overriding. Marking the class `final` also prevents anyone from adding new fields or methods through subclassing, and it signals to readers: \"this class is the complete picture; don't try to extend it.\"\n\nA few core JDK classes are `final` for exactly this reason:\n\n\n| Class | Why it's `final` |\n| --- | --- |\n| `String` | Immutability and string-pool sharing depend on subclasses not being able to alter behavior |\n| `Integer`, `Long`, `Double`, etc. | Same reasoning, plus they back primitive autoboxing |\n| `LocalDate`, `LocalTime`, `LocalDateTime` | Modern date/time API relies on immutability |\n| `UUID` | Identity values that must not be subclassed |\n\n\nThe reason `class MyString extends String` is not legal is this: `String` is `final`.\n\n---\n\n# `static final` Constants\n\nA common use of `final` in production Java is to define constants. A constant is a value that's the same for every object of the class and never changes for the life of the program. The idiomatic spelling is `public static final`.\n\n\n```java\npublic class TaxConfig {\n public static final double TAX_RATE = 0.07;\n public static final double FREE_SHIPPING_THRESHOLD = 50.0;\n public static final int MAX_ITEMS_PER_ORDER = 50;\n\n public static void main(String[] args) {\n double subtotal = 80.0;\n double tax = subtotal * TAX_RATE;\n boolean freeShipping = subtotal >= FREE_SHIPPING_THRESHOLD;\n\n System.out.println(\"Subtotal: $\" + subtotal);\n System.out.println(\"Tax: $\" + tax);\n System.out.println(\"Free shipping: \" + freeShipping);\n }\n}\n```\n\n\nThree things are happening on those declarations:\n\n- `public` makes the constant accessible from any class.\n- `static` makes it belong to the class itself, so callers write `TaxConfig.TAX_RATE`, not `new TaxConfig().TAX_RATE`.\n- `final` makes the value unchangeable.\n\nThe naming convention for constants is `UPPER_SNAKE_CASE`. Words are uppercase, separated by underscores. This convention is universal across the Java ecosystem, and it makes constants visually distinct from regular variables. `MAX_ITEMS_PER_ORDER` in code is recognizable as a constant without further inspection.\n\n### Constants Defined in One Place, Used Everywhere\n\nConstants earn their place when the same value would otherwise be repeated across many files. Imagine that `0.07` for tax rate is hardcoded in ten different methods. When the tax rate changes (and it will), every `0.07` has to be hunted through the codebase with a risk of missing one. With `TaxConfig.TAX_RATE`, one line changes.\n\n\n```java\npublic class CheckoutService {\n public static double calculateTax(double subtotal) {\n return subtotal * TaxConfig.TAX_RATE;\n }\n\n public static double calculateTotalWithTax(double subtotal) {\n return subtotal + calculateTax(subtotal);\n }\n\n public static void main(String[] args) {\n double subtotal = 100.0;\n System.out.println(\"Tax: $\" + calculateTax(subtotal));\n System.out.println(\"Total: $\" + calculateTotalWithTax(subtotal));\n }\n}\n```\n\n\n`CheckoutService` doesn't store its own copy of the tax rate. It reads `TaxConfig.TAX_RATE` directly. If tax rules change, only `TaxConfig` needs an update.\n\n### Compile-Time Constants\n\nA `static final` field whose value is a primitive or `String` literal and is set at declaration is called a **compile-time constant**. The Java compiler inlines compile-time constants at the call site. That means after compilation, the bytecode of `CheckoutService` no longer references `TaxConfig.TAX_RATE` symbolically; it has `0.07` literally baked in.\n\n\n```java\npublic class Constants {\n public static final double TAX_RATE = 0.07; // compile-time constant\n public static final int MAX_ITEMS = 50; // compile-time constant\n public static final String CURRENCY = \"USD\"; // compile-time constant\n public static final double DYNAMIC = Math.random(); // NOT a compile-time constant\n}\n```\n\n\n`TAX_RATE`, `MAX_ITEMS`, and `CURRENCY` are compile-time constants because their values are literal expressions known at compile time. `DYNAMIC` is `static final` (assigned exactly once at class load), but its value comes from a method call, so it's only known at runtime. Compile-time constants enable a couple of small things, like being used in `case` labels of a `switch` statement. Runtime-final values cannot be used there.\n\nInlining is a performance win at call sites (no field lookup), but it has a sharp edge. If `TaxConfig` is in a separate library and only `CheckoutService` is recompiled after changing `TAX_RATE` from `0.07` to `0.08`, the old value is still inlined in any caller that wasn't recompiled. The fix is to recompile everything that depends on the constant. For values that change often, use a method like `getTaxRate()` instead.\n\n---\n\n# Where Different Forms of `final` Sit\n\nA single diagram that places each form of `final` next to what it locks:\n\n\n```mermaid\nflowchart TD\n Final[final keyword]:::cyan\n\n Final --> Var[Local variable
or parameter]:::orange\n Final --> Field[Instance or
static field]:::orange\n Final --> Method[Method]:::teal\n Final --> Class[Class]:::teal\n\n Var --> VarLock[Cannot reassign
after first set]:::green\n Field --> FieldLock[Must be set once,
then frozen]:::green\n Method --> MethodLock[Subclasses cannot
override]:::red\n Class --> ClassLock[Cannot be extended]:::red\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe shape of the rule is the same across the table: `final` removes one specific kind of change. What changes is what kind of thing is being changed.\n\n---\n\n# A Word About \"Effectively Final\"\n\nJava often treats a variable as if it were `final` even without the keyword, as long as it's never reassigned after its first value. Such a variable is called **effectively final**. The compiler computes this property automatically.\n\n\n```java\npublic class EffectivelyFinal {\n public static void main(String[] args) {\n int loyaltyPoints = 150;\n String customerName = \"Alice\";\n\n // Both are never reassigned below, so both are effectively final.\n\n System.out.println(customerName + \" has \" + loyaltyPoints + \" points.\");\n }\n}\n```\n\n\n\"Effectively final\" isn't written anywhere; the property only matters when another part of the language requires `final` or effectively final variables. Two features that ask for it:\n\n- **Anonymous classes** can only refer to local variables from the enclosing method if those variables are `final` or effectively final.\n- **Lambda expressions** have the same restriction.\n\nThe term comes up in an error message that eventually appears: \"local variables referenced from a lambda expression must be final or effectively final\". The cure is usually to stop reassigning the variable, or to copy its value into a fresh `final` one right before the lambda.\n\n---\n\n# Putting `final` to Work: A Small E-Commerce Class\n\nA slightly larger example uses several of the `final` forms together. It models a `LineItem` on an order: the product ID, name, unit price, and quantity, all set when the line is created and untouched after.\n\n\n```java\npublic class LineItem {\n public static final double TAX_RATE = 0.07;\n\n private final String productId;\n private final String name;\n private final double unitPrice;\n private final int quantity;\n\n public LineItem(String productId, String name, double unitPrice, int quantity) {\n this.productId = productId;\n this.name = name;\n this.unitPrice = unitPrice;\n this.quantity = quantity;\n }\n\n public double getSubtotal() {\n return unitPrice * quantity;\n }\n\n public double getTax() {\n return getSubtotal() * TAX_RATE;\n }\n\n public double getTotal() {\n return getSubtotal() + getTax();\n }\n\n @Override\n public String toString() {\n return name + \" x\" + quantity + \" @ $\" + unitPrice\n + \" (subtotal $\" + getSubtotal() + \", total $\" + getTotal() + \")\";\n }\n\n public static void main(String[] args) {\n LineItem mouse = new LineItem(\"P-1001\", \"Wireless Mouse\", 29.99, 2);\n LineItem cable = new LineItem(\"P-1002\", \"USB Cable\", 9.99, 1);\n\n System.out.println(mouse);\n System.out.println(cable);\n }\n}\n```\n\n\nThree forms of `final` are at work:\n\n- `TAX_RATE` is a `public static final` constant, shared by every `LineItem` and visible to outside code as `LineItem.TAX_RATE`.\n- `productId`, `name`, `unitPrice`, and `quantity` are blank final instance fields, assigned exactly once in the constructor and frozen after.\n- The class itself isn't `final` here, to allow subclassing later. To lock the design down completely, add `final class LineItem`.\n\nThis pattern (`final` fields set in the constructor, no setters) is a starting point for **immutable** classes. Immutable design has more rules (defensive copying for mutable fields, no methods that mutate state, sometimes a `final` class). For now, the takeaway is that `final` fields are one ingredient, not the whole recipe.\n\n---\n\n# Common Mistakes With `final`\n\nA few patterns are easy to get wrong. Each one comes from misunderstanding exactly which thing `final` is locking.\n\n### Mistake 1: Expecting `final` to Deep-Freeze a List\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class FrozenCartMyth {\n public static void main(String[] args) {\n final List cart = new ArrayList<>();\n cart.add(\"Wireless Mouse\");\n cart.add(\"USB Cable\");\n cart.clear();\n System.out.println(\"Items left: \" + cart.size());\n }\n}\n```\n\n\n`cart` is `final`, yet `cart.clear()` empties the list without complaint. `final` doesn't make the list immutable. For an immutable list, use `List.copyOf(otherList)` or `List.of(...)`, both of which return a list that throws `UnsupportedOperationException` on any mutation attempt.\n\n### Mistake 2: Forgetting to Assign a Blank Final\n\n\n```java\npublic class MissingAssign {\n private final String productId;\n\n public MissingAssign() {\n // productId never assigned\n }\n}\n```\n\n\nThe error is: `variable productId might not have been initialized`. **Fix:** assign `productId` in the constructor, in an initializer block, or at the declaration.\n\n### Mistake 3: Assigning a Final Field Twice\n\n\n```java\npublic class DoubleAssign {\n private final String name;\n\n public DoubleAssign() {\n this.name = \"Alice\";\n this.name = \"Bob\"; // compile error\n }\n}\n```\n\n\n`this.name` is already set when the second assignment runs, and a `final` field can only be assigned once. **Fix:** decide which value is correct and assign it once. For two valid options depending on context, use two constructors that each assign once.\n\n### Mistake 4: Reassigning a `final` Parameter\n\n\n```java\npublic static double normalize(final double price) {\n if (price < 0) {\n price = 0; // compile error\n }\n return price;\n}\n```\n\n\nThe parameter is `final`, so reassignment inside the body is forbidden. **Fix:** introduce a new local variable for the normalized value.\n\n\n```java\npublic static double normalize(final double price) {\n double adjusted = price;\n if (adjusted < 0) {\n adjusted = 0;\n }\n return adjusted;\n}\n```\n\n\nThe original parameter stays a faithful copy of what the caller passed in, and `adjusted` carries the post-normalization value. The two roles are split cleanly.\n\n### Mistake 5: Treating `static final` Numeric Literals As Free To Recompile\n\nA `public static final int MAX = 50;` in one library, used by a separate library, gets inlined. Changing `MAX` to `100` and recompiling only the constant's library leaves the other library still seeing `50` until it's rebuilt. **Fix:** rebuild every dependent library, or, for values that change often, expose the value through a method like `getMax()` instead of a constant.\n\n---\n\n# Reading `final` in Real Code\n\nA few rules of thumb that hold up well in practice:\n\n- `final` on a local variable or parameter is documentation: \"this variable doesn't change for the rest of this method.\"\n- `final` on a field is a contract: \"this object's value for this field is set at construction and never moves.\"\n- `final` on a reference field (a `List`, `Map`, custom object) locks only the reference. The object can still mutate unless its class disallows it.\n- `final` on a method or class is a hard limit: \"no subclass gets to change this.\" That has consequences for testing (mocking a `final` method through a basic subclass is impossible) and for extension (callers must use composition, not inheritance).\n- `UPPER_SNAKE_CASE` names are almost always `static final` constants. The casing alone signals the intent.\n\n`final` is a small word that makes constraints visible. The compiler enforces them, and readers benefit from the labels.\n\n---\n\n# Quiz","pageType":"java"}

final Keyword

Get Premium