com.fasterxml.jackson.datatype.joda.ser.DateTimeSerializer#DateTimeSerializer(JacksonJodaDateFormat format, int shapeOverride)
I can't figure out the meaning of shapeOverride. Could not find proper information on the internet about it. So what does it mean, what is it for?
This is a hint to Jackson to tell it what the fields "shape" is. Shape is basically data type. I don't know if you have ever serialized a Joda object and got an array before, but this is basically shape.
Is it an Array, String, or Timestamp?
The override is any non-0 value. So if you provide 0 you will get the default, and the default is ARRAY.
So pass the following based on how you want to serialize your data:
No Override = 0
STRING = 1
TIMESTAMP = 2
ARRAY = 3
You can see their explination in com.fasterxml.jackson.datatype.joda.ser.JodaDateSerializerBase
public abstract class JodaDateSerializerBase<T> extends JodaSerializerBase<T>
// need contextualization to read per-property annotations
implements ContextualSerializer
{
private static final long serialVersionUID = 1L;
// // Since 2.9
protected final static int FORMAT_STRING = 1;
protected final static int FORMAT_TIMESTAMP = 2;
protected final static int FORMAT_ARRAY = 3;
protected final JacksonJodaDateFormat _format;
protected final SerializationFeature _featureForNumeric;
/**
* Shape to use for generic "use numeric" feature (instead of more specific
* JsonFormat.shape).
*
* #since 2.9
*/
protected final int _defaultNumericShape;
/**
* Marker set to non-0 if (and only if) property or type override exists.
*
* #since 2.9
*/
protected final int _shapeOverride;
Related
I cannot seem to figure out in my service integration why my instantiation of the class of another service returns null even when I can see the class in the jar in the library.
Please see my code here:
public class OAuthFacadeClientImpl implements OAuthFacadeClient {
/**
* oauth facade
*/
private OAuthFacade supergwOauthFacade;
/** LOGGER */
private static final Logger LOGGER = LoggerFactory.getLogger(OAuthFacadeClientImpl.class);
#Override
public AccessTokenRevokeResult revokeToken(String merchantId, String userId,
String scope) {
AccessTokenRevokeRequest revokeRequest = new AccessTokenRevokeRequest();
revokeRequest.setAccessToken(userId);
revokeRequest.setClientId(merchantId);
revokeRequest.setExtRequestId(scope);
LogUtil.info(LOGGER, "revokeRequest value = " + revokeRequest);
AccessTokenRevokeResult revokeResult = supergwOauthFacade
.revokeToken(revokeRequest.getClientId(), revokeRequest.getAccessToken(),
revokeRequest.getExtRequestId());
SALResultChecker.checkAndAssert(revokeResult);
return revokeResult;
}
/**
* Setter method for property <tt>oAuthFacade</tt>.
*
* #param oAuthFacade value to be assigned to property miniAppQueryFacade
*/
public void setOAuthFacade(OAuthFacade oAuthFacade) {
this.supergwOauthFacade = oAuthFacade;
}
}
Breakpoints of my code upon debugging
You basically need to instantiate an object of type OAuthFacade prior to using this method revokeToken(...) and feed that reference using your setter method (e.i., setOAuthFacade(...)) so that supergwOauthFacade will not point to nothing and avoid getting NullPointerException. Good LUCK
Let's say I have an object that represents an electrical circuit.
public class Circuit
{
private int? resistance;
private int? current;
private int? voltage;
}
Given that current = voltage/resistance I can calculate the unknown property if I know the other two.
My first thought was that naturally the relationship between the properties should be built into the object. So that when setting any of the properties an unknown can be autofilled if the other two are known. This would work fine until a situation arises where all properties are set and one needs to be modified resulting in confusion over which of the other two properties should be modified to enforce the relationship. The other properties I suppose would need to be set to null at this point.
Is having setters with side effects like this viewed as acceptable practice? Are there other ways of enforcing such a relationship?
Further info
This is a simplified representation. The resistance could also be determined by inputting wire length and diameter and a resistance constant, I could also have wattage and phase. I am working in a databound scenario and have to persist the state of the object. As the number of properties increases and their relationship to one another gets more complex my setters get a little out of control.
You shouldn't set the current property in the resistance or voltage setter. Instead simply calculate the value in the current getter.
public class Conductor
{
private int? resistance;
private int? current() { return voltage/resistance; }
private int? voltage;
}
Your actual problem is that your assumption is wrong: A conductor in a circuit is not defined by its resistance, current and voltage, but only any two of them: The third one (regardless which) is implied by the values of the others. Therefore, you only need two attributes to describe a fully determined state of your conductor. Lets take resistance and voltage for simplicity. Then, to enforce the relationship between current and voltage, you could write:
public class Conductor
{
private float resistance;
private float voltage;
public void setVoltage( float voltage )
{
this.voltage = voltage;
}
public float getVoltage()
{
return voltage;
}
public float getCurrent()
{
return getVoltage() / getResistance();
}
public void setCurrent( float current )
{
this.voltage = current * getResistance();
}
public void setResistance( float resistance )
{
this.resistance = resistance;
}
public void setResistance( float current, float voltage )
{
setResistance( voltage / current );
}
public float getResistance()
{
return resistance;
}
}
For any further setters, such as setting the conductor's resistance based on wire length, diameter and a resistance constant, you won't require any new attributes (!) but only the setters themselves:
public void setResistance( float constant, float diameter, float length )
{
this.resistance = constant * length / ( 2 * Math.PI * diameter * diameter );
}
Same is true for further getters:
public float getResistanceConstant( float diameter, float length )
{
return ( getResistance() * ( 2 * Math.PI * diameter * diamter ) ) / length;
}
If you nevertheless need to store diameter as an attribute, you should derive a class Wire from Conductor, since not every conductor's resistance is defined by it's length, diameter and resistance constant, but only those of wires. But remember: Again, you won't need to store all the three values as arguments, but only two of them - the third one's value is already implicitly defined, since you got the resistance as an attribute.
One method of my class need fresh copy of some array for internal stuff, so I should write something like that:
public void FrequentlyCalledMethod {
int[] a = new int[100];
....
But because method is frequently called and because content of the array doesn't make sense (it will be replaced anyway) and because array is big enough i want to optimize and write something like that:
private int[] a = new int[100];
public void FrequentlyCalledMethod {
....
Assuming that method is called 100 times per second I will save about 100 * 100 * sizeof(int) bytes of heap memory every second.
The problem is that now class declaration is "dirty". It contains in field the information that only one method needs. Having too much such fields will make class very "unreadable" as "normal" fields will be mixed with "perfomance optimizations" field.
What can I do? Or I should just choose either perfomance or readablity? Can I have both somehow?
No your class declaration is not dirty. Class declaration is dirty only when you mangle its public interface. And this is a private field. Private fields are used for this.
If you are too worried about the too many private variables then try using small classes. If a method needs 3 private variables you can create a class with those 3 variables and store the object as private filed in current class.
class A{
private int a;
private int b;
private int c;
public int get_num(){
return a+b+c;
}
}
you can use this,
class B{
private int a;
private int b;
private int c;
public int get_num(){
return a+b+c;
}
}
class A{
private B b;
public int get_num(){
return b.get_num();
}
}
If the first case, the array inside FrequentlyCalledMethod is referenced using a local variable, so it will be garbage-collected when the method ends: there's no heap over-usage in that scenario.
However, if you declare your array as a member attribute; the array instance will persist for all your parent-object life, even if the method FrequentlyCalledMethod is called or not.
In conclusion, if you wanna preserve heap-space and make your program more memory efficient go with local attributes and avoid instance variables in your particular case.
If I had a class with immutable members in Java, I would do this:
class MyClass {
private final String name;
private final int id;
myClass(String name, int id) {
this.name = name;
this.id = id;
}
String getName() { return name; }
int getId() { return id; }
}
In Progress-4GL, you'd typically see something like this: (Please, no lectures on Hungarian Notation. I hate it too, but it's very common in the Progress community, so it's something I just live with.)
CLASS MyClass :
DEFINE VARIABLE mcName as CHARACTER NO-UNDO.
DEFINE VARIABLE miId as INTEGER NO-UNDO.
CONSTRUCTOR PUBLIC MyClass(INPUT ipcName AS CHARACTER,
INPUT ipiId AS INTEGER):
ASSIGN mcName = ipcName
miId = ipiID.
END. /* constructor(char,int)*/
END CLASS. /* MyClass */
I was told in that in Progress 10.2B, they added the ability to make constants/final variables. However, I am unable to find any reference to it anywhere. In my Architect (version 10.2A) I do see that FINAL is considered a keyword. But the documentation behind it simply eludes me.
And if you've ever tried to search for Progress documentation, you know my dilemma.
How can I do immutable variables in Progress 10.2B? Are there any gotchyas I need to be aware of?
Thanks!
EDIT 1 I found documentation on FINAL. It appears to only apply to classes and methods. My current approach is
CLASS ImmutableString :
DEFINE PRIVATE VARIABLE mcValue AS CHARACTER NO-UNDO.
CONSTRUCTOR PUBLIC ImmutableString(INPUT ipcValue AS CHARACTER) :
ASSIGN mcValue = ipcValue.
END.
METHOD PUBLIC CHARACTER getValue() :
RETURN mcValue. /* Is a defensive copy required? */
END METHOD.
END CLASS.
You could also create a public property with a public "GET" and a private "SET":
DEF PUBLIC PROPERTY Value AS CHAR NO-UNDO
GET.
PRIVATE SET.
CONSTRUCTOR PUBLIC ImmutableString(INPUT ipcValue AS CHARACTER) :
Value = ipcValue.
END.
That's a little less code and does the same thing.
EDITED to change the property name to match the original poster's example.
While viewing Evans' project on sample DDD project, I notice that in the Cargo entity, Evans uses tracknumber which is an value object. Why he didn't chooses plain string tracknumber instead chooses value object for identity? Here is snippet from Evans:
public class Cargo implements Entity<Cargo> {
private TrackingId trackingId
}
public final class TrackingId implements ValueObject<TrackingId> {
private String id;
/**
* Constructor.
*
* #param id Id string.
*/
public TrackingId(final String id) {
Validate.notNull(id);
this.id = id;
}
A couple of things that would achieve:
Encapsulates the logic that the Tracking ID should not be null
Encapsulates the logic that the Tracking ID should not change once set.
With a plain string, the Cargo object would have to be aware of these rules. Using the Value Object approach means the TrackingId maintains these rules about itself.