package be.eek.test.mysql;

import java.io.IOException;
import java.io.InputStream;

public class MysqlBackup {

    /**
    main method is just to create a working example
    **/
    public static void main(String[] args) throws IOException {
        new MysqlBackup().MakeBackup();
    }

    public void MakeBackup() throws IOException {
        String dump = "mysqldump "      //Path to mysql
                + "--host=localhost "       //Mysql hostname
                + "--port=3306 "            //Mysql portnumber
                + "--user=root "            //Mysql username
                + "--password=test "        //Mysql password
                + "--add-drop-table "       //Add a DROP TABLE statement before each CREATE TABLE statement
                + "--add-drop-database "    //Add a DROP DATABASE statement before each CREATE DATABASE statement
                + "--complete-insert "      //Use complete INSERT statements that include column names.
                + "--extended-insert "      //Use multiple-row INSERT syntax that include several VALUES lists
                + "test";                   //Mysql databasename

        Process run = Runtime.getRuntime().exec(dump);

        InputStream in = run.getInputStream();

        int nextChar;
        StringBuffer sb = new StringBuffer();

        while ((nextChar = in.read()) != -1) {
            sb.append((char) nextChar);
        }

        //Here, you can for example write it to a file and save it
        System.out.println(sb);
    }
}

The same thing is also possible in php:

$dump = "mysqldump "
        . "--host=localhost "       //Mysql hostname
        . "--port=3306 "            //Mysql portnumber
        . "--user=root "            //Mysql username
        . "--password=test "        //Mysql password
        . "--add-drop-table "       //Add a DROP TABLE statement before each CREATE TABLE statement
        . "--add-drop-database "    //Add a DROP DATABASE statement before each CREATE DATABASE statement
        . "--complete-insert "      //Use complete INSERT statements that include column names.
        . "--extended-insert "      //Use multiple-row INSERT syntax that include several VALUES lists
        . "test";                   //databasename

$backup = system($dump);
echo $backup;
die();

When I’ve entered the room on Monday morning, the first thing I’ve noticed was that there where no stands with Java-companies or products. We all got a bag with a T-shirt which is really cool

The first event of the day in which I’ve attended was an introduction to Java Generics by Prof. Eric Steegmans. He explained during this 3 hours class all about Java Generics. He started with a very basic example used in in ArrayList and build his presentation up to more advanced features like generics in classes, generics with wildcards,…
He explained everything very well but the example in his demo was not really good. He was trying to show us a class which used generics but he implemented like 6 other classes which made the example a little bit to difficult to follow.

Next on the menu was another 3 hours class about JSF2 by Dan Allen, Peter Muir and Andy Schwartz. The course was divided into 3 sections: View(Andy), Controller (Dan) and Model (Peter). What I liked about there presentation style was the fact that they showed how something was in JSF 1.x, how they improved it in JSF2.0 en what they should improve in JSF 2.next.
The presentation given by Peter Muir was the best of the 3. He was very enthusiastic and explained why JSF shouldn’t concern (very much) about the model.
I’ve learned a lot in this presentation.

Next was a presentation about Hades by Oliver Gierke. It was a short presentation about implementing data access layers with JPA which is a lot easier with Hades.
I’m not quite sure if I will ever use Hades but it looked promising.

Last presentation of the day was about NoSQL with Cassandra and Hadoop by Steven Noels. He told us that his company developed a CMS which had some problems with scaling if it was deployed at big companies. As a solution they threw out the rational databases and went to another way of working. He explained which frameworks they compared (Googles Bigtables, Cassandra,Hades,..) and why they ultimately choosed Hades above Cassandra.
I like this way of thinking and will look to it in the (near) future.

It was a very interesting day.

The second day when I’ve entered the building, I’ve saw that the stands have arrived: Time to get me some nice goodies!!!
The big companies where all present (IBM,Oracle,Adobe,Springsource,..) and also a few minor companies (Atlassian, Jetbrains,..). There was one company absent…Sun, which is in my opinion a little bit strange since they don’t belong to Oracle yet.

The first presentation was again a 3 hours during class about the Java EE6 platform by Antonio Goncalves and Alexis Moussine-Pouchkine. I was in doubt if I would follow this course at first because a colleague of mine said he once saw a presentation by Antonia Goncalves which was kinda boring. Not this time!! It was the best presentation I’ve seen on Devoxx this year. They explained most of the new features in EE6 (validation, jsf, EJB3.1,EJB Lite, JSF2.0, Servlet3.0,JAX-RS 1.1,JPA2.0,..) and gave an example for each feature.
I’m very excited about JavaEE6. It’s a lot easier and has a lot of cool features.
They told us that Java EE6 (and GlassfishV3) will be released in December. I can’t wait.

The next course I’ve attented was about SOA in practice by Nicolai Josuttis. I had heard a few things about SOA but wasn’t very sure what it was so I was very curious about this presentation.
Nicolai explained how and when a company should setup a SOA architecture. It was very clear explained and what I’ve liked was the fact that the speaker wasn’t someone who would use SOA always. He explained that it isn’t necessary for many companies. A really good presentation which gave me the insights into SOA which I didn’t had before.

After that, there was a short presentation about a year of monitoring with Java-Monitor by Kees Jan Koster. He explained a few different techniques how you can monitor your JVM and how to detect and fix some issues. The presentation was a little bit to short but was very interesting.

The last course I’ve attended was about lookup, a new OSGi Service Registry. I have no experience with OSGi and this course was sadly a little bit to abstract for me.

The conclusion of these 2 days at Devoxx is that I’ve learned a lot and there will come some exciting times for Java in the near future. I wish I could also attend the 3 other days but sadly that’s not the case. I’ve enjoyed the Devoxx-time and hope to attend again next year!!

Xml Attributes

In this first example, I’ll show you how the lifecycle of a bean happens within the xml-configfile.

In the xml-file, we can define an init- and destroy-method to the bean, which will be called automatically by Spring.
Config.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

    <bean id="attributesTest" class="a.Test" init-method="initMethod" destroy-method="destroyMethod">
    </bean>
</beans>

Main program
In this case, I’ll use AbstractApplicationContext because this Context has a function to destroy the Context which a normal ApplicationContext doesn’t have.

package a;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class XmlAttributesTest {
    public static void main(String[] args) {
        AbstractApplicationContext ctx = new ClassPathXmlApplicationContext("Config.xml");
        ctx.registerShutdownHook();
        Test test =  ctx.getBean("attributesTest",Test.class);
    }
}

Test.java

package a;

public class Test{

    public Test(){
        System.out.println("We are in the constructor of Test");
    }

    public void initMethod(){
        System.out.println("We are in initMethod of Test");
    }

    public void destroyMethod(){
        System.out.println("We are in destroyMethod of Test");
    }

}

The output will be:

We are in the constructor of Test
We are in initMethod of Test
We are in destroyMethod of Test

It’s also possible to declare default init- and destroy-methods in the xml-file. This is done in the beans-tag:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"
       default-init-method="initMethod"
       default-destroy-method="destroyMethod">
...

LifeCycles with interfaces

It’s possible to call the lifecyclemethods by implemnting a Spring interface.
It’s very easy to do but I don’t recommend this because when you use the interfaces, your code will be highly coupled to the Spring Framework which isn’t always a good case.
Config.xml
You don’t have to set an init and destroy method in the xml-file

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

    <bean id="interfacesTest" class="b.Test">
    </bean>
</beans>

Main program
This is always the same…

package b;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class InterfaceTest {

    public static void main(String[] args) {
        AbstractApplicationContext ctx = new ClassPathXmlApplicationContext("Config.xml");
        ctx.registerShutdownHook();
        Test test =  ctx.getBean("interfacesTest",Test.class);
    }
}

Test.java
We have to implement InitializingBean for init-methods and DisposableBean for destroy-methods

package b;

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

public class Test implements InitializingBean, DisposableBean {

    public Test(){
        System.out.println("We are in the constructor of Test");
    }

    public void afterPropertiesSet() throws Exception {
        System.out.println("We are in afterPropertiesSet of Test");
    }

    public void destroy() throws Exception {
        System.out.println("We are in destroy of Test");
    }
}

Lifecycle with annotations

Config.xml
Don’t forget to include to enable annotations with the Contextparameters in the xml-file

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans 

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/context

            http://www.springframework.org/schema/context/spring-context-3.0.xsd">
   <context:annotation-config/>

    <bean id="annotationsTest" class="c.Test">
    </bean>

</beans>

Main program
Still the same…

package c;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class AnnotationsTest {

    public static void main(String[] args) {
        AbstractApplicationContext ctx = new ClassPathXmlApplicationContext("Config.xml");
        ctx.registerShutdownHook();
        Test test = ctx.getBean("annotationsTest", Test.class);
    }
}

Test.java
We can use the lifecyclemethods with the annotations @PostConstruct for init-methods and @PostDestroy for destroy-methods.

package c;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

public class Test {

    public Test() {
        System.out.println("We are in the constructor of Test");
    }

    @PostConstruct
    public void start(){
        System.out.println("We are in the start-method of Test");
    }

    @PreDestroy
    public void stop(){
        System.out.println("We are in the stop-method of Test");
    }
}

Putting them all together

It’s possible to use the 3 methods all together
Config.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans 

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/context

            http://www.springframework.org/schema/context/spring-context-3.0.xsd">
   <context:annotation-config/>

    <bean id="allTogether" class="d.Test" init-method="initMethod" destroy-method="destroyMethod">
    </bean>
</beans>

Main program

package d;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class AllTogetherTest {

    public static void main(String[] args) {
        AbstractApplicationContext ctx = new ClassPathXmlApplicationContext("Config.xml");
        ctx.registerShutdownHook();
        Test test = ctx.getBean("allTogether", Test.class);
    }
}

Test.java
We are using interfaces AND annotations.
It’s even possible to use multiple times the same annotation:

package d;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

public class Test implements DisposableBean,InitializingBean {

    public void destroy() throws Exception {
        System.out.println("DisposableBean-Interface");
    }

    public void afterPropertiesSet() throws Exception {
        System.out.println("InitializingBean-Interface");
    }

    @PostConstruct
    public void start(){
        System.out.println("First PostConstruct");
    }

    @PostConstruct
    public void start2(){
        System.out.println("Second PostConstruct");
    }

    @PostConstruct
    public void start3(){
        System.out.println("Third PostConstruct");
    }

    @PreDestroy
    public void stop(){
        System.out.println("PreDestroy");
    }

    public void initMethod(){
        System.out.println("initMethod");
    }

    public void destroyMethod(){
        System.out.println("destroyMethod");
    }
}

The output is:

Third PostConstruct
Second PostConstruct
First PostConstruct
InitializingBean-Interface
initMethod
PreDestroy
DisposableBean-Interface
destroyMethod

So we can conclude that the annotations are processed first, followed by the interfaces and at last the methods from the xml-file.

In this little blogpost, I’ll try to explain the differences between ServletConfig and ServletContext and when you can use them into a Java Web Application.

ServletConfig

ServletConfig is actually very simple. Like stated above, you can retrieve parameters for the servlet which are set at deployment time.
I’ll explain this with a very simple example.

If you have created a servlet with the name “MyServlet” you can add the following 2 variables into the servlet:

    <servlet>
         <servlet-name>MyServlet</servlet-name>
         <servlet-class>servlets.MyServlet</servlet-class>
         <init-param>
             <param-name>variable1</param-name>
             <param-value>I'm var1</param-value>
         </init-param>
         <init-param>
             <param-name>variable2</param-name>
             <param-value>I'm var2</param-value>
         </init-param>
     </servlet>
     <servlet-mapping>
         <servlet-name>MyServlet</servlet-name>
         <url-pattern>/MyServlet</url-pattern>
     </servlet-mapping>

You can retrieve variable2 with the following code:

getServletConfig().getInitParameter("variable2");

Retrieve all the variables of the servlet and loop over them:

Enumeration allvars = getServletConfig().getInitParameterNames();
while (allvars.hasMoreElements()) {
     String next = (String) allvars.nextElement();
     out.println(next + " has the value " + getServletConfig().getInitParameter(next));
}

It’s also possible to retrieve the servlets name through getServletconfig

out.println("The name of the servlet is: " + getServletConfig().getServletName());

ServletContext

ServletContext can be used to retrieve application-wide parameters, get serverparameters and store/retrieve/remove application-wide attributes.

It is possible to call the ServletContext right on or through the ServletConfig. Both are the same so you can choose between them.

if (getServletContext().equals(getServletConfig().getServletContext())) {
       out.println("both calls retrieve the same Context");
}

Just like with ServletConfig, you can set parameters in the Deployment Descriptor. They are initialized on compile time. It’s not possible to remove or add them on runtime.

<context-param>
        <param-name>variable3</param-name>
        <param-value>Im var 3</param-value>
</context-param>

And call them in your servlet just like the ServletConfig parameters:

getServletContext().getInitParameter("variable3")

Unlike ServletConfig, ServletContext can work with attributes. These are parameters or objects which you can set into the servlet and retrieve in every other servlet of your Web Application:

getServletContext().setAttribute("test", "I'm an application-wide String");
..
out.println(getServletContext().getAttribute("test"));
..
getServletContext().removeAttribute("test");

I’ll end this little short tutorial with an example of how you can retrieve serversettings through the Context:

out.println(getServletContext().getContextPath());
out.println(getServletContext().getMajorVersion());
out.println(getServletContext().getRealPath(""));
out.println(getServletContext().getServerInfo());

If there are any more questions, just shoot them

Annotation based DI
It’s possible in Guice to inject a class with the help of annotations. In this example, I create a mainclass which creates an order. Inside the order there will be a payment done. There are 2 types of payments (by card or cash) and they will be injected by Guice.
Payment

public interface Payment {
    public void pay();
}

PaymentCash

public class PaymentCashImpl implements Payment {
    public void pay() {
        System.out.println("I'll pay just plain cash");
    }
}

PaymentCard

public class PaymentCardImpl implements Payment{
    public void pay() {
        System.out.println("I'll pay with a credit card");
    }
}

Order

public class Order {

    private Payment payment;

    public Payment getPayment() {
        return payment;
    }

    public void setPayment(Payment payment) {
        this.payment = payment;
    }

    public void finishOrder(){
        this.payment.pay();
    }
}

Main

public class Main {
    public static void main(String[] args) {
        Order order = new Order();
        Payment payment = new PaymentCardImpl();
        order.setPayment(payment);
        order.finishOrder();
    }
}

There isn’t any Dependency injection in the code above. All the classes are highly coupled into each other. So it’s time to do some magic:
Payment
You can tell through the use of annotations which Payment type is the default implemented class

@ImplementedBy(PaymentCardImpl.class)
public interface Payment {
    public void pay();
}

Order
Inject the payment type in the order. What we here say is: Inject the default paymentimplementation, which is set by the @implementedby annotation, into the payment field.

public class Order {
    @Inject
    private Payment payment;
....

Main
Lastly, we have to rewrite the main class. In this example, we get an order which uses the PaymentCard as payment type

public class Main {
    public static void main(String[] args) {
       Injector injector = Guice.createInjector();
        Order order = injector.getInstance(Order.class);
        order.finishOrder();
    }
}

You can run this code. The output should be -I’ll pay with a credit card-. This code is so cool because if we want to switch to payment with cash at a later point, we just have to change the @implementedBy annotation in the interface and we are done.

Injection types
Guice knows different types of injection. The 3 most used are constructor, field and method injection (Examples are based on the above example)
Constructor injection

import com.google.inject.Inject;

public class Order {
    private Payment payment;

    @Inject
    public Order(Payment payment){
        this.payment=payment;
    }
   ...
}

Method injection

import com.google.inject.Inject;

public class Order {
    private Payment payment;

    @Inject
    public void setPayment(Payment payment) {
        this.payment = payment;
    }
   ...
}

Field injection

public class Order {
    @Inject
    private Payment payment;
   ...
}

Module based DI
It’s also possible to use Modules for injecting data. It’s maybe a little more work but I like it because all the configuration is in the same file. You can compare this with the xml-file in Spring applications.
Payment
Remove the @ImplementedBy annotation in the paymentinterface

public interface Payment {
    public void pay();
}

MyModule
Next, create the Module class. It has to implement Module, which has one method: configure.
The code speaks for its self. You say nothing more than bind Payment to PaymentCard.

public class MyModule implements Module {
    public void configure(Binder arg0) {
        arg0.bind(Payment.class).to(PaymentCardImpl.class);
    }
}

Instead of implementing Module, you can also extend AbstractModule. It’s just a matter of choice.

public class MyModule extends AbstractModule {
    public void configure() {
        bind(Payment.class).to(PaymentCardImpl.class);
    }
}

Main
Lastly, we have to put the module into our injector and we are done.

public class Main {
    public static void main(String[] args) {
        MyModule module = new MyModule();
        Injector injector = Guice.createInjector(module);
        Order order = injector.getInstance(Order.class);
        order.finishOrder();
    }
}

The 4 lines in the main class can be written into 1 single line:

public class Main {
    public static void main(String[] args) {
        Guice.createInjector(new MyModule()).getInstance(Order.class).finishOrder();
    }
}

Subclassing
In Guice, it’s easy to subclass an implementation.
Payment

public interface Payment {
    public void pay();
}

PaymentCardImpl

public class PaymentCardImpl implements Payment{
    public void pay() {
        System.out.println("I'll pay with a credit card");
    }
}

PaymentVisaCard
extend payment card with paymentvisacard

public class PaymentVisaCard extends PaymentCardImpl {
    public void pay() {
        System.out.println("I'll pay with a card from Visa");
    }
}

Nothing special in the Main class
Main

public class Main {
    public static void main(String[] args) {
        Guice.createInjector(new MyModule()).getInstance(Payment.class).pay();
    }
}

MyModule
You can specify the hierarchy in the moduleclass

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(Payment.class).to(PaymentCardImpl.class);
        bind(PaymentCardImpl.class).to(PaymentVisaCard.class);
    }
}

If you run this code, the Visa Card will be used.
Annotationbindings
It’s also possible to use annotations for injection
Payment
There’s nothing special in the interface and implementations:

public interface Payment {
    public void pay();
}

PaymentCardImpl

public class PaymentCardImpl implements PaymentCashImpl{
    public void pay() {
        System.out.println("I pay with a card");
    }
}

PaymentCashImpl

public class PaymentCashImpl implements Payment {
    public void pay() {
        System.out.println("I pay cash");
    }
}

Next, we have to created the annotations @cash and @Card
Cash

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.ElementType;
import java.lang.annotation.Target;

import com.google.inject.BindingAnnotation;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.PARAMETER})
@BindingAnnotation
public @interface Cash { }

Card

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.ElementType;
import java.lang.annotation.Target;

import com.google.inject.BindingAnnotation;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.PARAMETER})
@BindingAnnotation
public @interface Card { }

Main

public class Main {
    public static void main(String[] args) {
        Guice.createInjector(new PayModule()).getInstance(Order.class).finishOrder();
    }
}

Module
You have to specify which annotations refers to which implementation in the moduleclass

public class PayModule extends AbstractModule{
    @Override
    protected void configure() {
        bind(Payment.class).annotatedWith(Cash.class).to(PaymentCashImpl.class);
        bind(Payment.class).annotatedWith(Card.class).to(PaymentCardImpl.class);
    }
}

Order
Now you can use the annotation in your code to inject the right class

public class Order {

    @Inject
    private @Card Payment payment;
   ...

If you want to chane Cardpayments to Cashpayments, just change the @Card annotation to @Cash

Namedannotationbindings
You can also use named annotations. This is a Guice annotation where the value is specified inside the moduleclass.
The paymentinterface, the Main and the Cash and Card implementations are the same as the previous example.
Module
Give the annotations a name (“Cash” and “Card”)

public class PayModule extends AbstractModule{
    @Override
    protected void configure() {
        bind(Payment.class).annotatedWith(Names.named("Cash")).to(CashPayment.class);
        bind(Payment.class).annotatedWith(Names.named("Card")).to(CardPayment.class);
    }
}

Main

 * @author wim
 */
public class Main {
    public static void main(String[] args) {
        Injector inj = Guice.createInjector(new PayModule());
        Order order = inj.getInstance(Order.class);
        order.getPaymentCard().pay();

        Guice.createInjector(new PayModule()).getInstance(Order.class).getPaymentCash().pay();
    }
}

Order
Now you can use them in your order

public class Order {

    private Payment paymentCash;
    private Payment paymentCard;

    @Inject
    public void setPaymentCash(@Named("Cash") Payment payment){
        this.paymentCash=payment;
    }

    public Payment getPaymentCash(){
        return paymentCash;
    }

    @Inject
    public void setPaymentCard(@Named("Card") Payment payment){
        this.paymentCard=payment;
    }

    public Payment getPaymentCard(){
        return paymentCard;
    }
}

These annotations are very simple but I don’t recommend them. Guice doesn’t check them on spelling or validity so they are kinda error prone.
Instancebinding
With instancebinding, you can easily give a value to an instance
Module
Give a value to a name inside the module

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(String.class)
        .annotatedWith(Names.named("PaymentType"))
        .toInstance("...I'm a Visa Card...");
    }
}

Main

public class Main {
    public static void main(String[] args) {
        String text = Guice.createInjector(new MyModule()).getInstance(Order.class).getText();
        System.out.println(text);
    }
}

Order
Use the annotation. The String text will be injected with “…I’m a Visa Card…”.

public class Order {

    @Named("PaymentType")
    @Inject
    private String text;

    public String getText(){
        return text;
    }
}

Providers
The last example is with the use of providers.
A provider can be used when you have to craete an object. You have to annotate it with the @Provides annotation and the return type is the bound type.
Payment

public interface Payment {
    void pay();
    int getAmount();
}

CashPayment

public class CashPayment implements Payment{

    private int amount;

    public void pay() {
        System.out.println("Inside cashpayment");
    }

    public void setAmount(int amount){
        this.amount=amount;
    }

    public int getAmount(){
        return amount;
    }
}

Main

public class Main {
    public static void main(String[] args) {
        Payment payment = Guice.createInjector(new MyModule()).getInstance(Payment.class);
        payment.pay();
        System.out.println(payment.getAmount());
    }
}

MyModule
Inside the module class, we can construct the class and set the amount of payment.

public class MyModule extends AbstractModule{

    @Override
    protected void configure() {
    }

    @Provides
    Payment providePayment(){
        CashPayment pay = new CashPayment();
        pay.setAmount(100);
        return pay;
    }
}

Conclusion
You can do more with Guice than described above but that’s up to you to find out.
I love Guice!! It’s pretty simple and works very good. You don’t have to use XML to bind your classes and it’s very lightweight. If you just wan’t to use Dependency Injection, Guice is in my opinion the number 1.