We Keep Coding

Is it correct to have static factory method to get a new instance with one field updated?

I think the title is self-descriptive but I will give an example to elaborate on my question. I have a DTO class with few fields (a CarDataTransferObj class in my example). In another class (let's call it class A) I need to create a new instance of that object few times, but with only one field updated (length field in my example). Given DTO must be immutable in class A. As there is "many" fields in the class CarDataTransferObj, I thought about following approach (to avoid repeating code in class A):
#Builder
public class CarDataTransferObj {
private Integer id;
private String color;
private String manufacturer;
private String model;
private String uniqueIdNr;
private Integer nrOfDoors;
private EngineType engineType;
private Integer length;
private Integer safetyLevel;
public static CarDataTransferObj newInstanceWithUpdatedLength(final CarDataTransferObj car, final Integer newLength) {
return CarDataTransferObj.builder()
.id(car.getId())
.color(car.getColor())
.manufacturer(car.getManufacturer())
.model(car.getModel())
.uniqueIdNr(car.getUniqueIdNr())
.nrOfDoors(car.getNrOfDoors())
.engineType(car.getEngineType())
.length(newLength)
.safetyLevel(car.getSafetyLevel())
.build();
}
}
For me it smells like a little anti-pattern usage of static factory methods. I am not sure whether it's acceptable or not, hence the question.
Is using static factory method in the presented way an anti-pattern, and should be avoided ?

In my searching, I didn't come across anyone calling this1 an anti-pattern.
However, it is clear that if you try to do this using a classic builder that is not specifically implemented to support this mode of operation .... it won't work. For instance, the example CarBuilderImpl in the Wikipedia article on the Builder design pattern puts the state into an eagerly created Car instance. The build() method simply returns that object. If you tried to reuse that builder in the way that you propose, you would end up modifying a Car that has already been built.
There is another problem you would need to worry about. In we modified the Wikipedia CarBuilder example to add actual wheels (rather than a number of wheels) to the Car being built, we have to worry about creating cars that share the same wheels.
You could address these things in a builder implementation, but it is unclear whether the benefits out-weigh the costs.
If you then transfer this thinking to doing this using a factory method, you come to a slightly different conclusion.
If you are doing this as a "one-off", that's probably OK. You have a specific need, the code is clunky ... but so is the problem.
If you needed to do this for lots of different parameters, or combinations of parameters, this is not going to scale.
If the objects that are created are mutable, then this approach is could be problematic in a multi-threaded environment depending on how you control access to the objects you are using as templates.
1 - There are no clear measurable criteria for whether something is an anti-pattern or not. It is a matter of opinion. Admittedly, for many anti-patterns, there will be wide-scale agreement on that opinion.

It seems a little inefficient to construct an entirely new instance via a builder every time you want to make a new copy with a small modification. More significantly, it sounds like the places where you need the class to be immutable are isolated to places like class A. Why not try something like this:
public interface ICarDataTransferObject {
public Integer GetId();
public String GetColor();
public String GetManufacturer();
public String GetModel();
public String GetUUID();
public Integer GetDoorCount();
public EngineType GetEngineType();
public Integer GetLength();
public Integer GetSafteyLevel();
}
public class CarDataTransferObject Implements ICarDataTransferObject {
private Integer _id;
private String _color;
private String _manufacturer;
private String _model;
private String _uniqueIdNr;
private Integer _nrOfDoors;
private EngineType _engineType;
private Integer _length;
private Integer _safetyLevel;
public Integer GetId() { return _id; }
public void SetId(Integer id) { _id = id; }
public String GetColor() { return _color; }
public void SetColor(String color) { _color = color; }
public String GetManufacturer() { return _manufacturer; }
public void SetManufacturer(String manufacturer) { _manufacturer = manufacturer; }
public String GetModel() { return _model; }
public void SetModel(String model) { _model = model; }
public String GetUUID() { return _uniqueIdNr; }
public void SetUUID(String uuid) { _uniqueIdNr = uuid; }
public Integer GetDoorCount() { return _nrOfDoors; }
public void SetDoorCount(Integer count) { _nrOfDoors = count; }
public EngineType GetEngineType() { return _engineType; }
public void SetEngineType(EngineType et) { _engineType = et; }
public Integer GetLength() { return _length; }
public void SetLength(Integer length) { _length = length; }
public Integer GetSafteyLevel() { return _safetyLevel; }
public void SetSafteyLevel(Integer level) { _safteyLevel = level; }
public CarDataTransferObject() {}
public CarDataTransferObject(ICarDataTransferObject other) { ... }
public ReadOnlyCarDataTransferObject AsReadOnly() {
return ReadOnlyCarDataTransferObject (this);
}
}
}
public class ReadOnlyCarDataTransferObject Implements ICarDataTransferObject {
private ICarDataTransferObject _dto = null;
public Integer GetId() { return _dto.GetId(); }
public String GetColor() { return _dto.GetColor(); }
public String GetManufacturer() { return _dto.GetManufacturer(); }
public String GetModel() { return _dto.GetModel(); }
public String GetUUID() { return _dto.GetUUID(); }
public Integer GetDoorCount() { return _dto.GetDoorCount(); }
public EngineType GetEngineType() { return _dto.GetEngineType(); }
public Integer GetLength() { return _dto.GetLength(); }
public Integer GetSafteyLevel() { return _dto.GetSafteyLevel; }
public ReadOnlyCarDataTransferObject (ICarDataTransferObject other) {
_dto = other;
}
}
Now when you want class A to have a copy no one can modify, just use the copy constructor and only expose a ReadOnly version of that copy.
public class A {
ICarDataTransferObject _dto;
ReadOnlyCarDataTransferObject _readOnlyDTO;
public ICarDataTransferObject GetDTO() { return _readOnlyDTO; }
public A(ICarDataTransferObject dto) {
_dto = new CarDataTransferObject(dto);
_readOnlyDTO = new ReadOnlyCarDataTransferObject(_dto);
}
}
You commonly see this approach in .NET applications.

While it is debatable whether your static method is an anti-pattern or not, it surely won't scale for combinations of different attributes. Nonetheless, even if it's not an anti-pattern, I think there is a better way to accomplish what you need.
There's a variant of the traditional builder pattern that, instead of creating a new empty builder, accepts an already built object and creates an already initialized builder. Once you create the builder this way, you simply change the length attribute in the builder. Finally, build the object. In plain code (no Lombok, sorry) it could be like this:
public class CarDataTransferObj {
private Integer id;
private String color;
// other attributes omitted for brevity
private Integer length;
// Private constructor for builder
private CarDataTransferObj(Builder builder) {
this.id = builder.id;
this.color = builder.color;
this.length = builder.length;
}
// Traditional factory method to create and return builder
public static Builder builder() {
return new Builder();
}
// Factory method to create and return builder initialized from an instance
public static Builder builder(CarDataTransferObj car) {
Builder builder = builder();
builder.id = car.id;
builder.color = car.color;
builder.length = car.length;
return builder;
}
// getters
public static class Builder {
private Integer id;
private String color;
private Integer length;
private Builder() { }
public Builder withId(Integer id) { this.id = id; return this; }
public Builder withColor(String color) { this.color = color; return this; }
public Builder withLength(Integer length) { this.length = length; return this; }
public CarDataTransferObj build() {
return new CarDataTransferObj(this);
}
}
}
Now with all this infrastructure in place, you can do what you want as easy as:
CarDataTransferObj originalCar = ... // get the original car from somewhere
CarDataTransferObj newCar = CarDataTransferObj.builder(originalCar)
.withLength(newLength)
.build();
This approach has the advantage that it scales well (it can be used to change any combination of parameters). Maybe all this builder's code seems boilerplate, but I use an IntelliJ plugin to create the builder with two keystrokes (including the variant factory method that accepts a built instance to create an initialized builder).

I'm still new to java but..
I guess making a copy method which takes the CarDataTransferObj object variables and sets their values to another CarDataTransferObj object variables and changing the the length using it's setter method would be better idea
Example:
public class CarDataTransferObj {
private Integer id;
private String color;
private String manufacturer;
private String model;
private String uniqueIdNr;
private Integer nrOfDoors;
private EngineType engineType;
private Integer length;
private Integer safetyLevel;
public void Copy(CarDataTransferObj copy) { //Could add another parameter here to be the new length
copy.setId(id);
copy.set(color);
copy.setManufacturer(manufacturer);
copy.setModel(model);
copy.setUniqueIdNr(uniqueIdNr));
copy.setNrOfDoors(nrOfDoors));
copy.setEngineType(engineType));
copy.setLength(length);
copy.setSafetyLevel(safetyLevel));
}
}
public class SomeOtherClass {
CarDataTransferObj car1 = new CarDataTransferObj(); //Using this way made you able to use the constructor for a more useful thing
//You set the variables you want for car1 here
CarDataTransferObj car2 = new CarDataTransferObj();
car1.Copy(car2)
car2.setLength(newLength) //Set the new length here
}

Is this method of initialization recommended?

So when I was coding my own project, a problem came up with initializing an object. My class has so many attributes that needs to be initiated BUT not always all of them, which . That's when I came up with this idea (but I'm not sure if it's used before anywhere):
public class MyClass {
public static final int DEFAULT1 = 1;
public static final int DEFAULT2 = 2;
public static final int DEFAULT3 = 3;
private int attr1;
private int attr2;
private int attr3;
private MyClass(){
attr1 = DEFAULT1;
attr2 = DEFAULT2;
attr3 = DEFAULT3;
}
public static MyClass create(){
return new MyClass();
}
public MyClass setAttr1(int attr1){
this.attr1 = attr1;
return this;
}
public MyClass setAttr2(int attr2){
this.attr2 = attr2;
return this;
}
public MyClass setAttr3(int attr3){
this.attr3 = attr3;
return this;
}
}
When I create a new MyClass instance I would do:
MyClass obj = MyClass.create().setAttr1(3).setAttr3(1);
It worked for me (kind of because I tested it but I haven't decided to use it in my project). My question is, is this legit? Would it create any kinds of memory/execution problems?

Your use case is a perfect example of Builder design pattern. Read more about here and oracle doc about builder. Also read why Builder pattern has an advantage over other creation pattern by Java legend Joshua which is discuss in his book, best practice of java
here.
Your converted class using Builder design pattern will look like below. Note that i assumed attr1 optional and attr2 and attr3 as mandatory.
class MyClass {
public static final int DEFAULT1 = 1;
public static final int DEFAULT2 = 2;
public static final int DEFAULT3 = 3;
// assume attr1 is optional
private int attr1;
// assume attr2,3 is mandatory
private int attr2;
private int attr3;
public MyClass(MyClassBuilder myClassBuilder) {
this.attr1 = myClassBuilder.attr1;
this.attr2 = myClassBuilder.attr2;
this.attr3 = myClassBuilder.attr3;
}
//Builder Class
public static class MyClassBuilder {
// required parameters
private int attr2;
private int attr3;
// optional parameters
private int attr1;
public MyClassBuilder(int attr2, int attr3){
this.attr2 = attr2;
this.attr3 = attr3;
}
public MyClassBuilder setAttr1(int attr1) {
this.attr1 = attr1;
return this;
}
public MyClass build(){
return new MyClass(this);
}
}
}
Now After that using below code, you can create the objects (with/without) optional param.
public class MyClassTest {
public static void main(String[] args) {
MyClass myClass = new MyClass.MyClassBuilder(10,20).build();
// without optional param
System.out.println("without optional param");
System.out.println("attr1 "+ myClass.getAttr1());
System.out.println("attr2 "+ myClass.getAttr2());
System.out.println("attr3 "+ myClass.getAttr3());
// with optional param
System.out.println("with optional param");
MyClass myClassWithAllParam = new MyClass.MyClassBuilder(10,20).setAttr1(5).build();
System.out.println("attr1 "+ myClassWithAllParam.getAttr1());
System.out.println("attr2 "+ myClassWithAllParam.getAttr2());
System.out.println("attr3 "+ myClassWithAllParam.getAttr3());
}
}
Output of which is below :-
without optional param
attr1 0
attr2 10
attr3 20
with optional param
attr1 5
attr2 10
attr3 20

Another name for it is Fluent Interface.
You just need to use with instead of set for method names. The set naming is kind of reserved for JavaBeans convention.

Esper: Grammatically defining a type with sub types?

I have to define the class below in ESPER so I'm able to reference the sub-types and internal arrays. I have to do it pragmatically. I don't care how:
UPDATE: The complete class:
public class IoTEntityEvent implements java.io.Serializable {
private IoTProperty[] Properties;
private String About;
IoTEntityEvent (){
this.About = null;
this.Properties = null;
}
public String getAbout() {
return About;
}
public void setAbout( String value){
this.About = value;
}
public void setProperties(int index, IoTProperty value) {
Properties[index] = value;
}
public IoTProperty getProperties(int index) {
return Properties[index];
}
public void setProperties( IoTProperty[] value) {
Properties = value;
}
public IoTProperty[] getProperties() {
return Properties;
}
}
This is the sub-class:
public class IoTProperty implements java.io.Serializable {
private Map<String,String>[] IoTStateObservation =null;
private String About = null;
IoTProperty (){
this.About = null;
this.IoTStateObservation = null;
}
public String getAbout() {
return About;
}
public void setAbout(String value) {
About = value;
}
public Map<String,String>[] getIoTStateObservation() {
return IoTStateObservation;
}
public void setIoTStateObservation( Map<String,String>[] value) {
IoTStateObservation = value;
}
public Map<String,String> getIoTStateObservation(int index) {
return IoTStateObservation[index];
}
public void setIoTStateObservation(int index, Map<String,String> value) {
IoTStateObservation[0] = value;
}
}
I tried like this :
eventNames[0] = "About";
eventType[0] = String.class;
eventNames[1] = "Properties";
eventType[1] = IoTProperty[].class;
epService.getEPAdministrator().getConfiguration().addEventType("type", eventNames, eventType);
This works but I can't access the sub-types. I also tried to define the sub type in similar manner. Can someone can explain how I suppose to do it?

What do you mean with "This works but I can't access the sub-types."
Tried like "select Properties[0].whatever" from type?

According to the Esper documentation:
Plain-old Java object events are object instances that expose event properties through JavaBeans-style getter methods. Events classes or interfaces do not have to be fully compliant to the JavaBean specification; however for the Esper engine to obtain event properties, the required JavaBean getter methods must be present or an accessor-style and accessor-methods may be defined via configuration.
In short, you need to create the JavaBean getters and setters in order to access your private members.

Thank you for the help. I found out how and is as following:
epService.getEPAdministrator().getConfiguration().addEventType("type",IoTEntityEvent.class);
Then the event should be send like this without any casting:
IoTValue[] va= {new IoTValue("0.62","2014-06-09T18:08:40.968Z","2014-06-09T18:08:40.968Z")};
IoTProperty[] pr = {new IoTProperty(va,"property")};
IoTEntityEvent event = new IoTEntityEvent(pr,"Entity");
epService.getEPRuntime().sendEvent(event);

Exchanging data between 2 methods in 2 different classes

Im quite new to Java and this might be a basic doubt. But please help.
I have a class as below:
public class EnterLeaveHandler implements IOtfHandler {
public void handle(java.lang.Object ... args) {
long time = (Long) args[0];
int func = (Integer) args[1];
int cpuid = (Integer) args[2];
int source = (Integer) args[3];
}
I have another class:
public class DefFunctionHandler implements IOtfHandler {
public void handle(Object... args) {
int stream = (Integer) args[0];
int func = (Integer) args[1];
String name = (String) args[2];
int funcgroup = (Integer) args[3];
int source = (Integer) args[4];
}
}
So like you can see..there are 2 different classes, which have the same method, but receive different data. I need to get an input from the user for the "String name" in DefFunctionHandler class, and I identify the given name with the name in the file that I have...then correlate it with other data in the method like funcgroup and func. The same func is there in the other class too. So I need to make a comparison between them to get the data in the other class like time, etc.
So the data in the methods can be compared to the data structure in C...how do I implement such a structure in Java? I read that structs are similar to classes in Java. But in my case, I have the data in methods and not classes. Please tell me how to solve this problem.

To Answer Your Original Question
Long story short, you can't access method variables externally. What you want to do is make those variables fields within the class. Putting them outside the method means they stick around after the method is done, and it means you can access them from outside.
public class EnterLeaveHandler implements IOtfHandler {
private long time;
private int func;
private int cpuid;
private int source;
// Please don't use varargs like this; read the whole answer!!
public void handle(Object ... args) {
time = (Long) args[0];
func = (Integer) args[1];
cpuid = (Integer) args[2];
source = (Integer) args[3];
}
}
Then you access them by creating getters and setters:
public long getTime() {
return time;
}
public void setTime(long t) {
time = t;
}
// etc...
HOWEVER, Some Suggestions...
Your code is... strange, to say the least. It's also very non-Java-like. As much as possible, you should try to avoid having multiple overriding methods that need different data. Also, you normally want to initialize your fields in the constructor, not in some other method.
It's not clear how much of the code you have access to, but if you're able to rewrite the interface, I would definitely do so. Object varargs in an interface is just weird. The reason for using an interface is so that you can call an interface method with identical parameters and, regardless of the object type underneath, something useful will happen. It defeats the point of the interface to have two implementations of the same method require totally different arguments. The following code demonstrates why this is:
IOtfHandler h1 = new EnterLeaveHandler();
IOtfHandler h2 = new DefFunctionHandler();
h1.handle(0, 0, 0, 0);
h2.handle(0, 0, 0, 0); // Crashes with ClassCastException!! :(
// And would also crash two lines later with ArrayIndexOutOfBoundsException
Much better to just make them different methods entirely.You know what variables you're expecting, so you should take advantage of that fact. Your method signatures would be far better off looking something like this:
public class EnterLeaveHandler implements IOtfHandler {
public void handle(long time, int func, int cpuid, int source) {
// Do things with your shiny new variables
}
public class DefFunctionHandler implements IOtfHandler {
public void handle(int stream, int func, String name, int funcgroup, int source) {
// Do things with your shiny new variables
}
}
As others have suggested, if the "real" method signatures are not identical, you shouldn't be using an interface. Better to use an abstract base class instead, to hold what little data is common between them:
abstract class IOtfHandler {
private int source;
private int func;
public void setSource(int source) {
this.source = source;
}
// etc
}
class EnterLeaverHandler extends IOtfHandler {
private long time;
// etc
}
class DefFunctionHandler extends IOtfHandler {
private String name;
// etc
}
Of course, if you set all the variables in the constructors, you may be able to add an abstract handle() method to the base class, since then that method should have the same signature, and take no arguments at all!
Final Result
So if we pull together all the changes I've talked about-- moving the method variables into fields, using getters and setters, using useful method signatures, using constructors, and using a base class instead of a misleading interface, we end up with something like this:
abstract class IOtfHandler {
private int source;
private int func;
public void setSource(int source) {
this.source = source;
}
public int getSource() {
return source;
}
public void setFunc(int func) {
this.func = func;
}
public int getFunc() {
return func;
}
// abstract handle method
abstract public void handle();
}
class EnterLeaverHandler extends IOtfHandler {
private long time;
private int cpuid;
// getters and setters
public void setTime(long time) {
this.time = time;
}
public long getTime() {
return time;
}
public void setCpuId(int cpuid) {
this.cpuid = cpuid;
}
public int getCpuId() {
return cpuid;
}
// constructor
public EnterLeaverHandler(long time, int cpuid, int source, int func) {
setTime(time);
setCpuId(cpuid);
setSource(source);
setFunc(func);
}
// handle method
public void handle() {
System.out.println("EnterLeaverHandler.handle()");
// Do whatever class-specific handling you might want to do in here.
}
}
class DefFunctionHandler extends IOtfHandler {
private String name;
private int funcGroup;
private int stream;
// getters and setters
public void setName(String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setFuncGroup(int funcGroup) {
this.funcGroup = funcGroup;
}
public int getFuncGroup() {
return funcGroup;
}
public void setStream(int stream) {
this.stream = stream;
}
public int getStream() {
return stream;
}
// constructor
public DefFunctionHandler(String name, int funcGroup, int stream, int source, int func) {
setName(name);
setFuncGroup(funcGroup);
setStream(stream);
setSource(source);
setFunc(func);
}
// handle method
public void handle() {
System.out.println("DefFunctionHandler.handle()");
// Do whatever class-specific handling you might want to do in here.
}
}
public class Main {
public static void main(String[] args) {
IOtfHandler h1 = new DefFunctionHandler("name", 0, 0, 0, 0);
IOtfHandler h2 = new EnterLeaverHandler(0, 0, 0, 0);
h1.handle();
h2.handle();
}
}

In order to make the variables class variables, all you have to do is move their declaration outside of the method. In other words, your code for the EnterLeaveHandler might look like this:
public class EnterLeaveHandler implements IOtfHandler {
long time;
int func;
int cpuid;
int source;
public void handle(java.lang.Object ... args) {
time = (Long) args[0];
func = (Integer) args[1];
cpuid = (Integer) args[2];
source = (Integer) args[3];
...
}
}

Create an abstract super class for your classes. Extend this with your classes and init the parameters in the handle call.
public abstract class AbstarctFunctionHandler implements IOtfHandler {
long time;
int func;
int cpuid;
int source
//add getters and setters, if you fancy
public boolean equals(AbstarctFunctionHandler obj){
//compare variables
return true;
}
}

You need to restructure your objects to have proper constuctors and setters/getters
This gives the benefit of protecting all your private variables and forcing other classes to adhere to your classe's "contract" by only allowing them to access it's inner variables via those setters/getters and constructor. Now you just instantiate the object, then use ti's methods to manipulate it.
Here is an example from your first example class:
public class EnterLeaveHandler implements IOtfHandler {
private long time;
private int func, cpuid, source;
public EnterLeavehandler(long time, int func, int cpuid, int source) {
this.time = time;
this.func = func;
this.cpuid = cpuid;
this.source = souce;
}
public long getTime() {
return this.time;
}
public void setTime(long time) {
this.time = time;
}
public int getFunc() {
return this.func;
}
public void setFunc(int func) {
this.func = func;
}
public int getCPUID() {
return this.cpuid;
}
public void setCPUID(int cpuid) {
this.cpuid = cpuid;
}
public int getSource() {
return this.source;
}
public void setSource(int source) {
this.source = source;
}
public void handle(long t, int f, int c, int s) {
this.setTime(t);
this.setFunc(f);
this.setCPUID(c);
this.setSource(s);
}
}

The best solution I could think of
1. is create a getter and setter
public void setName(String name) {
this.name = name;
}
public String getName() {
return name;
}
http://docs.oracle.com/javaee/6/tutorial/doc/gjbbp.html
2.create a wrapper method to do the comparsion prior to calling the individual method.
Hope this helps you.

Builder Pattern: which variant is preferred? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I was going through Effective Java book , and creating notes for my future reference ,
i came across Builder Pattern.
Well i understood what it is and how its suppose to be used.In the process i created a two example variations of the builder pattern.
I would need help in listing down the differences and the advantage each has?
Well i certainly noticed that , Example 1 exposes less methods , there by less restrictive and
more generic , there by allowing it to be used more flexibly.
Please point out other things i have missed?
Example 1
package item2;
/**
* #author Sudhakar Duraiswamy
*
*/
public class Vehicle {
private String type;
private int wheels;
interface Builder<T>{
public T build();
}
public static class CarBuilder implements Builder<Vehicle>{
private String type;
private int wheels;
CarBuilder createVehicle(){
this.type= "Car";
return this;
}
CarBuilder addWheels(int wheels){
this.wheels = wheels;
return this;
}
public Vehicle build(){
Vehicle v = new Vehicle();
v.type = type;
v.wheels = wheels;
return v;
}
}
public static class TruckBuilder implements Builder<Vehicle>{
private String type;
private int wheels;
TruckBuilder createVehicle(){
this.type= "Truck";
return this;
}
TruckBuilder addWheels(int wheels){
this.wheels = wheels;
return this;
}
public Vehicle build(){
Vehicle v = new Vehicle();
v.type = type;
v.wheels = wheels;
return v;
}
}
public Vehicle(){
}
public static void main(String[] args) {
//This builds a car with 4 wheels
Vehicle car = new Vehicle.CarBuilder().createVehicle().addWheels(4).build();
//THis builds a Truck with 10 wheels
Vehicle truck = new Vehicle.TruckBuilder().createVehicle().addWheels(10).build();
}
}
Example 2
package item2;
/**
* #author Sudhakar Duraiswamy
*
*/
public class Vehicle2 {
private String type;
private int wheels;
interface Builder<T>{
public T build();
public String getType();
public int getWheels() ;
}
public static class CarBuilder implements Builder<Vehicle2>{
private String type;
private int wheels;
public String getType() {
return type;
}
public int getWheels() {
return wheels;
}
CarBuilder createVehicle(){
this.type= "Car";
return this;
}
CarBuilder addWheels(int wheels){
this.wheels = wheels;
return this;
}
public Vehicle2 build(){
return new Vehicle2(this);
}
}
public static class TruckBuilder implements Builder<Vehicle2>{
private String type;
private int wheels;
public String getType() {
return type;
}
public int getWheels() {
return wheels;
}
TruckBuilder createVehicle(){
this.type= "Truck";
return this;
}
TruckBuilder addWheels(int wheels){
this.wheels = wheels;
return this;
}
public Vehicle2 build(){
return new Vehicle2(this);
}
}
public Vehicle2(Builder<? extends Vehicle2> builder){
Vehicle2 v = new Vehicle2();
v.type = builder.getType();
v.wheels = builder.getWheels();
}
public Vehicle2(){
}
public static void main(String[] args) {
//This builds a car with 4 wheels
Vehicle2 car = new Vehicle2.CarBuilder().createVehicle().addWheels(4).build();
//THis builds a Truck with 10 wheels
Vehicle2 truck = new Vehicle2.TruckBuilder().createVehicle().addWheels(10).build();
}
}

None of the above.
The first one doesn't allow building an immutable Vehicle, which is often why the Builder pattern is used.
The second example is a variation of the first one which allows getting information from the builder using additional getter methods. But those those methods aren't used anywhere, except in the Vehicle constructor, which has access to the builder fields directly. I don't see the point in adding them.
I see two more important things to improve:
The two builder types do exactly the same thing. There's no need for two types. A single one is sufficient.
What the createVehicle() method does should be done by the builder constructor. If you construct a CarBuilder, it's obviously to build a car, so the type of the vehicle should be set as soon as the builder is constructed. Here's how I would write it:
.
public final class Vehicle {
private final String type;
private final int wheels;
private Vehicle(Builder builder) {
this.type = builder.type;
this.wheels = builder.wheels;
}
public static Builder carBuilder() {
return new Builder("car");
}
public static Builder truckBuilder() {
return new Builder("truck");
}
public static class Builder {
private final String type;
private int wheels;
private Builder(String type) {
this.type = type;
}
public Builder addWheels(int wheels){
this.wheels = wheels;
return this;
}
public Vehicle build() {
return new Vehicle(this);
}
}
public static void main(String[] args) {
Vehicle car = Vehicle.carBuilder().addWheels(4).build();
Vehicle truck = Vehicle.truckBuilder().addWheels(10).build();
}
}

There is a third variant too, with less code:
Instead of having their own instance fields the builders could also mutate the state of Vehicle. Inner classes can write private members of their outer class:
class Vehicle {
private int wheels;
private Vehicle() {}
public static class Builder {
private boolean building = true;
private Vehicle vehicle = new Vehicle();
public Builder buildWheels(int wheels) {
if(!this.building) throw new IllegalStateException();
this.vehicle.wheels = wheels;
return this;
}
public Vehicle build() {
this.building = false;
return this.vehicle;
}
}
}
Since the fields are private and you allow it to be build only once (building flag), built Vehicle instances are still immutable to consumers even though the fields cannot be final anymore (no more realio-trulio immutability, see Eric's blog article which is on C# but the concepts are similar).
You need to be more careful as non-final fields do not have to be initialized during object construction (enforced by the compiler) and you must check the building state carefully. You do however save a full extra-copy of all instance fields. In general, this is useful if you have a rather large set of instance variables that are built with rather few methods, where each method builds a few fields at once.
I know this does not point out any advantages or drawbacks of your approaches. However, this approach can save a lot of extra code if you do not need the fields to be final.