I have a class with the fields "deletionDate" and "experiationDate" which could both be undefined, what would mean that the object is whether deleted nor has an expiration date.
My first approach was:
private Date deletionDate = null; // null means not deleted
Having the book "Clean Code" in mind I remember to better use expressive names instead of comments. So my current solutions is:
private static final Date NEVER = null;
private Date deletionDate = NEVER;
I could user a wrapper class around Date, but that would complicate JPA mapping.
What do you think of it? How would you express "never"?
well never is never, not the 1/1/2999.
I would stay with your 1st solution. a Null date means it has not yet happened.
maybe you can wrap it with something like :
boolean isNeverDeleted(){
return deletionDate == null;
}
You can think about null date as "not available" or "not applicable". If that's the case "NO DATE" is fine for "never".
Don't subtype Date only for a very exquisite style requirement.
A better option is to add semantic to your model object. If your have a Thing object with a deletionDate property you can do:
class Thing
+ deletionDate
+ isNeverDeleted: boolean { return deletionDate == null; }
and it will be practical and documentative, both in the class and in your client code:
if(myThing.isNeverDeleted())
I consider null appropriate. It clearly indicates "not set".
Depending on how complicated you want to get, though, you could have a Enum and have some state like 'NeverExpires' as the 'UserState' (or whatever it is you're representing). This is probably preferable, but could be uselessly complex, depending on what your system.
Let the default value be treated as "never"
I would just choose a far-future date as the value for the constant NEVER. Then to check for deletion/expiry, just compare against NEVER.
I would not use Date but timestamps, using -1 for never and 0 for immediately;
public static final long IMMEDIATE = 0;
public static final long NEVER = -1L;
private long expires = NEVER;
interpretation of the attribute should be in a getter, like:
public boolean isExpired() {
return (NEVER == expires) ? false : (expires < System.currentTimeMillies());
}
Deletion follows the same pattern.
Update I know that 0 and -1 are valid timestamps, but as expiration and deletion of files and other resources rarely (never say never :-)) happen in 1970 or before, it is a useful constant, imho.
Related
I really like the addition of records in Java 14, at least as a preview feature, as it helps to reduce my need to use lombok for simple, immutable "data holders". But I'm having an issue with the implementation of nullable components. I'm trying to avoid returning null in my codebase to indicate that a value might not be present. Therefore I currently often use something like the following pattern with lombok.
#Value
public class MyClass {
String id;
#Nullable String value;
Optional<String> getValue() { // overwrite the generated getter
return Optional.ofNullable(this.value);
}
}
When I try the same pattern now with records, this is not allowed stating incorrect component accessor return type.
record MyRecord (String id, #Nullable String value){
Optional<String> value(){
return Optional.ofNullable(this.value);
}
}
Since I thought the usage of Optionals as return types is now preferred, I'm really wondering why this restriction is in place. Is my understanding of the usage wrong? How can I achieve the same, without adding another accessor with another signature which does not hide the default one? Should Optional not be used in this case at all?
A record comprises attributes that primarily define its state. The derivation of the accessors, constructors, etc. is completely based on this state of the records.
Now in your example, the state of the attribute value is null, hence the access using the default implementation ends up providing the true state. To provide customized access to this attribute you are instead looking for an overridden API that wraps the actual state and further provides an Optional return type.
Of course, as you mentioned one of the ways to deal with it would be to have a custom implementation included in the record definition itself
record MyClass(String id, String value) {
Optional<String> getValue() {
return Optional.ofNullable(value());
}
}
Alternatively, you could decouple the read and write APIs from the data carrier in a separate class and pass on the record instance to them for custom accesses.
The most relevant quote from JEP 384: Records that I found would be(formatting mine):
A record declares its state -- the group of variables -- and commits
to an API that matches that state. This means that records give up a
freedom that classes usually enjoy -- the ability to decouple a
class's API from its internal representation -- but in return, records
become significantly more concise.
Due to restrictions placed on records, namely that canonical constructor type needs to match accessor type, a pragmatic way to use Optional with records would be to define it as a property type:
record MyRecord (String id, Optional<String> value){
}
A point has been made that this is problematic due to the fact that null might be passed as a value to the constructor. This can be solved by forbidding such MyRecord invariants through canonical constructor:
record MyRecord(String id, Optional<String> value) {
MyRecord(String id, Optional<String> value) {
this.id = id;
this.value = Objects.requireNonNull(value);
}
}
In practice most common libraries or frameworks (e.g. Jackson, Spring) have support for recognizing Optional type and translating null into Optional.empty() automatically so whether this is an issue that needs to be tackled in your particular instance depends on context. I recommend researching support for Optional in your codebase before cluttering your code possibly unnecessary.
Credits go to Holger! I really like his proposed way of questioning the actual need of null. Thus with a short example, I wanted to give his approach a bit more space, even if a bit convoluted for this use-case.
interface ConversionResult<T> {
String raw();
default Optional<T> value(){
return Optional.empty();
}
default Optional<String> error(){
return Optional.empty();
}
default void ifOk(Consumer<T> okAction) {
value().ifPresent(okAction);
}
default void okOrError(Consumer<T> okAction, Consumer<String> errorAction){
value().ifPresent(okAction);
error().ifPresent(errorAction);
}
static ConversionResult<LocalDate> ofDate(String raw, String pattern){
try {
var value = LocalDate.parse(raw, DateTimeFormatter.ofPattern(pattern));
return new Ok<>(raw, value);
} catch (Exception e){
var error = String.format("Invalid date value '%s'. Expected pattern '%s'.", raw, pattern);
return new Error<>(raw, error);
}
}
// more conversion operations
}
record Ok<T>(String raw, T actualValue) implements ConversionResult<T> {
public Optional<T> value(){
return Optional.of(actualValue);
}
}
record Error<T>(String raw, String actualError) implements ConversionResult<T> {
public Optional<String> error(){
return Optional.of(actualError);
}
}
Usage would be something like
var okConv = ConversionResult.ofDate("12.03.2020", "dd.MM.yyyy");
okConv.okOrError(
v -> System.out.println("SUCCESS: "+v),
e -> System.err.println("FAILURE: "+e)
);
System.out.println(okConv);
System.out.println();
var failedConv = ConversionResult.ofDate("12.03.2020", "yyyy-MM-dd");
failedConv.okOrError(
v -> System.out.println("SUCCESS: "+v),
e -> System.err.println("FAILURE: "+e)
);
System.out.println(failedConv);
which leads to the following output...
SUCCESS: 2020-03-12
Ok[raw=12.03.2020, actualValue=2020-03-12]
FAILURE: Invalid date value '12.03.2020'. Expected pattern 'yyyy-MM-dd'.
Error[raw=12.03.2020, actualError=Invalid date value '12.03.2020'. Expected pattern 'yyyy-MM-dd'.]
The only minor issue is that the toString prints now the actual... variants. And of course we do not NEED to use records for this.
Don't have the rep to comment, but I just wanted to point out that you've essentially reinvented the Either datatype. https://hackage.haskell.org/package/base-4.14.0.0/docs/Data-Either.html or https://www.scala-lang.org/api/2.9.3/scala/Either.html. I find Try, Either, and Validation to be incredibly useful for parsing and there are a few java libraries with this functionality that I use: https://github.com/aol/cyclops/tree/master/cyclops and https://www.vavr.io/vavr-docs/#_either.
Unfortunately, I think your main question is still open (and I'd be interested in finding an answer).
doing something like
RecordA(String a)
RecordAandB(String a, Integer b)
to deal with an immutable data carrier with a null b seems bad, but wrapping recordA(String a, Integer b) to have an Optional getB somewhere else seems contra-productive. There's almost no point to the record class then and I think the lombok #Value is still the best answer. I'm just concerned that it won't play well with deconstruction for pattern matching.
I write this getter/setter to list from Eclipse source menu:
public Date getDate() {
return date;
}
public void setDate(Date date) {
this.date = date;
}
And Sonar reporting two issues:
Return a copy of "date" & Store a copy of "date"
with the explanation
"Mutable members should not be stored or returned directly"
and a example code:
public String [] getStrings() {
return strings.clone();}
public void setStrings(String [] strings) {
this.strings = strings.clone();}
I think if my Date is null, it will throw a NullPointerException. Then I've changed my code to:
public Date getDate() {
if (this.date != null) {
return new Date(this.date.getTime());
} else {
return null;
}
}
public void setDate(Date date) {
if (date != null) {
this.date = new Date(date.getTime());
} else {
this.date = null;
}
}
And now marks other issue:
"Assigning an Object to null is a code smell. Consider refactoring".
I've searched in internet and set or return a new array is not a solution for me, I want to preserve my list to null if the setter param is null to overwrite an existing previous list.
I've the same problem for List, and I want to return/preserve null instead of a new ArrayList for an empty List. And in this case, the setter marks one more issue:
"Return an empty collection instead of null.".
What is the solution for this issue?
If you are in Java 8 and do not want to handle empty date, then maybe usage of Optional would help you.
Edit: Example of your "POJO" class
public class Toto {
public Optional<Date> myDate;
public Optional<Date> getMyDate() {
return this.myDate;
}
public void setMyDate(final Date myDate) {
this.myDate = Optional.ofNullable(myDate);
}
}
Example of code usage:
Toto toto = new Toto();
toto.setMyDate(null);
System.out.println("Value is null ? " + toto.getMyDate().isPresent());
System.out.println("Value: " + toto.getMyDate().orElse(new Date()));
Try to change the toto.setMyDate(...) with concrete date value to see what happen.
If you don't know what is Optional or how to use it, you can find plenty of examples.
BUT : This is only a way to solve your violation issue and i totally agree with Brad's remark, Optional are not intent to be used as a type, but more like a contract for potential empty / null returns.
In general, you should not correct your code in a bad way just to fix a violation, if the violation is not correct. And in your case i think you should just ignore the violation (as most of Sonar's one unfortunatly)
If you really want to use Java 8 and Optional in your code, then you POJO class would be like this (usage of Optional as a contrat on the getter only)
public class Toto {
public Date myDate;
public Optional<Date> getMyDate() {
return Optional.ofNullable(this.myDate);
}
public void setMyDate(final Date myDate) {
this.myDate = myDate;
}
}
This way,
You bean stay serializable (Optional is not)
You still enable your "client" code to have the choice on how to behave to empty / null value of your property
Configure your Sonar violation as a false positive as it is what you want instead of changing your code
Generally, while using static analysis tools to verify the code is valuable, you should not blindly fix every warnings which popups on you. You need to analyze the issue which is triggered and check if it really applies in your context.
Now to address the issues you are mentioning
Return a copy of "date" & Store a copy of "date"
This seems to be valid one. It is good practice to be defensive and not expose mutable state via getters/setters. So creating a defensive copy in getter/setter should be done. This can be done the way you did it, or by using new Java Time API, which provides immutable objects.
Assigning an Object to null is a code smell. Consider refactoring
IMO dubious one. The issue is raised by PMD plugin (which is the tool analyzing the code, SonarQube is displaying the report). Issue is raised by this rule http://pmd.sourceforge.net/pmd-4.3.0/rules/controversial.html#NullAssignment , as you can see it is in controversial category. I don't think there is anything wrong with your code, and proper action might be to ignore this warning and mark the issue as "won't fix". You can also configure your SonarQube to not use this particular rule in your Quality Profile setting.
Return an empty collection instead of null.
You did not provide the code which is triggering it, but this seems to be a valid piece of advice. It is generally better to return empty collections rather than nulls.
You don't have to explcitly set null in your setter, just use the value being passed in like this...
public void setDate(Date date) {
if (date != null) {
this.date = new Date(date.getTime());
} else {
this.date = date;
}
}
Personally I would never allow null values into my Value objects where ever possible, but that is just my opinionated coding style.
My advice to anyone is to prefer immutable value objects where you set all the values in the constructor and don't allow nulls in. This style may not be appropriate for all 3rd party libraries that expect the java bean getter/setters so be aware where it can be used effectively to simplify your code.
Edit
If the above code still gives you the warning and you must have the "property is not set yet" functionality, another approach is to define a "null object" like this
public static final Date NO_DATE = new Date(Long.MIN_VALUE);
public void setDate(Date date) {
this.date = (date == null) ? NO_DATE : new Date(date.getTime());
}
Users of this class can refer to the NO_DATE object like this, which still makes for readable code
if(toto.getDate() != NO_DATE) ...
Or encapsulate this into another method so it's used like this
if(toto.hasDate()) ...
Of course this doens't add much benefit over the Java 8 Optional approach from #kij but it does work with any version of Java
I have a class which is used to get transfer data from the one application to another and then also to update if changes were made.
public class Data {
private String name;
private String number;
private String info;
... getters/setters...
}
Let's say name and number will be updated if you change them but e.g. info is not. What's the best way to tell programmers in the future that this is intended so they can recognize it immediately?
Update:
It's encoded as a JSON file and when I get it back I don't care about the info field anymore. It could be empty
You can create your custom annotation, specific to your application. If you are using any framework like Hibernate you can use #transient.
Probably not the correct way, but if you are just talking about "informing" other programmers, you could simply put the transient keyword on your info field.
But of course, that would be really "informal"; as it would probably not at all affect how your framework is dealing with your fields.
I would use serialisation combined with the transient keyword
What is object serialization?
import java.io.*;
import java.util.*;
// This class implements "Serializable" to let the system know
// it's ok to do it. You as programmer are aware of that.
public class SerializationSample implements Serializable {
// These attributes conform the "value" of the object.
// These two will be serialized;
private String aString = "The value of that string";
private int someInteger = 0;
// But this won't since it is marked as transient.
private transient List<File> unInterestingLongLongList;
There's no indication in your file that name or number are being persisted.
If you are going to put behavior into the file in some durable way, this isn't just a file, it's a representation of an object, where data and the related behavior live as one. Write a method clarifying the intent.
public boolean isStorable() {
boolean isOk = true;
isOk &= (name != null && name.length() > 0);
isOk &= (number > 0);
return isOk;
}
Makes it clear that not every one of these items contribute to being able to store the object, and that not every value within these items contribute to a valid storage state.
It also makes it clear that this object permits invalid states within its private data. That's a code smell that could indicate a design flaw. Perhaps you should look into whether that is a design flaw, and if it is, then fix it.
Start here https://docs.oracle.com/javaee/6/tutorial/doc/bnbpz.html
Almost any programmer seing a POJO like this will know that behaviour is what you explained....
#Table(name = "data")
public class Data {
#Id
#Column(name = "name")
private String name;
#Column(name = "number")
private String number;
private String info;
... getters/setters...
}
UPDATE: It's encoded as a JSON file and when I get it back I don't care about the info field anymore. It could be empty
Below is my Interface -
public interface IDBClient {
public String read(ClientInput input);
}
This is my Implementation of the Interface -
public class DatabaseClient implements IDBClient {
#Override
public String read(ClientInput input) {
}
}
Now I have a factory which gets the instance of DatabaseClient like this -
IDBClient client = DatabaseClientFactory.getInstance();
....
Now I need to make a call to read method of my DatabaseClient which accepts the ClientInput parameter and below is the class for the same. This class was not written by me so that is the reason I am having a question on this and I am pretty much sure this is the wrong way of doing it.
public final class ClientInput {
private Long userid;
private Long clientid;
private Long timeout_ms = 20L;
private boolean debug;
private Map<String, String> parameterMap;
public ClientInput(Long userid, Long clientid, Map<String, String> parameterMap, Long timeout_ms, boolean debug) {
this.userid = userid;
this.clientid = clientid;
this.parameterMap = parameterMap;
this.timeout_ms = timeout_ms;
this.debug = debug;
}
}
So when customer make a call to read method of DatabaseClient, they will create the ClientInput parameter like this and then use the factory to get the Instance of DatabaseClient and then call the read method accordingly.
Map<String, String> paramMap = new HashMap<String, String>();
paramMap.put("attribute", "segmentation");
ClientInput input = new ClientInput(109739281L, 20L, paramMap, 1000L, true);
IDBClient client = DatabaseClientFactory.getInstance();
client.read(input);
Problem Statement:-
So my first question is does the userid, clientid, timeout_ms should be Long object or just simply long in ClientInput class?
Second question I have is, it might be possible that customer can pass wrong information such as negative user ids, negative client id, negative timeout value etc etc.. Then where I should do this validation? Should I do this validation check in the constructor of ClientInput class or at some other place? What's the better way of doing this and how should I do the validation?
long is a primitive, which must have a value. Simple.
Long is an object, so:
it can be null (meaning whatever you like, but "unknown" is a common interpretation)
it can be passed to a method that accepts an Object, Number, Long or long parameter (the last one thanks to auto-unboxing)
it can be used as a generic parameter type, ie List<Long> is OK, but List<long> is not OK
it can be serialized/deserialized via the java serialization mechanism
Always use the simplest thing that works, so if you need any of the features of Long, use Long otherwise use long. The overhead of a Long is surprisingly small, but it is there.
I don't think there's a single correct answer. A few suggestions:
The biggest difference I see between long and Long in this context is that Long may be null. If there's a possibility you might have missing values, the Long object will be helpful as null can indicate missing values. If you're using primitives, you'll have to use some special value to indicate missing, which is probably going to be a mess. Speed or size is not likely to be an issue unless you're planning on making an array of a million of these things and then serializing.
My preference for validation logic is to throw some sort of custom ValidationException at the point at which the thing could fail. If you're just creating these things with a constructor, the simplest thing would be just to validate there, e.g.
public ClientInput(Long userid, Long clientid, Map<String, String> parameterMap, Long timeout_ms, boolean debug) throws ValidationException {
if (userid == null) throw new ValidationException("UserId is required");
...etc, etc...
}
Ultimately, the ValidationException is only useful if you can catch it at a point where you can do something useful with it - echo it back to a user or whatever.
1 Long is the object orientated counter part of long. The difference is as follows, and it applies to Float to float, Integer to integer etc.
long is a primitive type, while Long is a Java class (and so it will inherit Object).
long must be assigned with a valid number, while Long can be null
long instances can't use the benefits of OO, while instances of Long are real Java objects
Long is a serializable so it will be very useful when doing file, database or network IO
long is more efficient than Long considering memory space and processing speed
If you are doing heavy calculations, use primitive types. Otherwise if you're concerning more about design, the object counter parts will be very useful.
2 Since you are not using any frameworks if I'm observing correctly, I suggest you make an interface like Validated with a method bool validate(). And every time you try to put a input into the database call validate in advance.
1) Use Long if you need to treat the value as an object. Use long otherwise; it's more efficient.
2) Judgement call, really. Putting it deeper means you're going to check even when the value is coming from a source you trust, but that may catch errors in other code. Putting it closer to the user input means you lose that deep sanity-check (and may need to check in more than one place) but avoids spending time checking things you've already checked. What's best depends on how you plan on using/enhancing this code in the future.
As Long is wrapper class privimitive type long and Long is a class, which indicate its instance could be null. In my perspective use wrapper class is better than primitive type because there could have null state in it, which could tells us more information.
In addition, wrapper class will automatically initialized with 0, it is good for lazy using.
For data validation, I think you'd better do it in controller rather than DAO, then have a good method to handle this or alert user to modify them!
The advantage of the Long class is that the value can be null. In your case, if no Long ID is supplied, if you quickly detect this with something like..
public ClientInput(Long userid, Long clientid, Map<String, String> parameterMap, Long timeout_ms, boolean debug) {
if (userid == null) {
throw new IllegalArgumentException("userid is null");
}
To your second question, you could place your ID validation in the constructor as well. This ensures that if the ID is null or invalid, a ClientInput can never be created. But there is no "best" answer for where you put this validation, it depends on the structure of the rest of your code, but ideally you want to catch such things as early as possible.
public ClientInput(Long userid, Long clientid, Map<String, String> parameterMap, Long timeout_ms, boolean debug) {
if (userid == null || userid < USER_ID_MIN || userid > USER_ID_MAX ) {
throw new IllegalArgumentException("userid is invalid");
}
Another option is to accept the userid parameter as a Long, testing it for null, but then store it as a private, primitive long, once you know its valid.
I try to keep Bean objects as simple as possible, which would mean handling validation elsewhere - either in a separate Validator class or in a validate() method. The general algorithm is the same:
validateInputParametres()
readDb()
I would do something like:
final ClientInput input = new ClientInput(109739281L, 20L, paramMap, 1000L, true);
validate(input); // throw/handle exceptions here
final Map<String, String> paramMap = new HashMap<String, String>();
paramMap.put("attribute", "segmentation");
final IDBClient client = DatabaseClientFactory.getInstance();
client.read(input);
People forgot to mention that long cannot be used in logical comparison because its contains string in it, simple logical conditions wont work like == ,!= , >, < to do this you have to use compareTo() function that comes with Long object class.
E.g. eng, spa, ita, ger
I could iterate all locales and compare the codes, but I wonder whether there is a more elegant & performant way to achieve this....
Thanks a lot for any hints :)
I don't know if there's an easy way to convert the 3-letter to the 2-letter versions, but in a worse case scenario, you could create a Map of them, like so:
String[] languages = Locale.getISOLanguages();
Map<String, Locale> localeMap = new HashMap<String, Locale>(languages.length);
for (String language : languages) {
Locale locale = new Locale(language);
localeMap.put(locale.getISO3Language(), locale);
}
Now you can look up locales using things like localeMap.get("eng");
Edit: Modified the way the map is created. Now there should be one object per language.
Edit 2: It's been a while, but changed the code to use the actual length of the languages array when initializing the Map.
You can use constructor Locale(String language), where language is the 2 letter ISO-639-1 code. I think the easiest way to convert ISO-639-2 to ISO-639-1 would be to create HashMap<String,String> constant.
Some modified code from my project, which has a similar requirement. We have our own historical timezone format so we can't use standard libraries.
public class MyProjectTimeZoneFactory {
private static Map timeZoneDb;
/**
* Set up our timezone id mappings; call this from any constructor
* or static method that needs it.
*/
private static void init() {
if(null == TimeZoneDb) {
timeZoneDb = new HashMap(); // Maybe a TreeMap would be more appropriate
timeZoneDb.put(" ","GMT+00");
timeZoneDb.put("EAD ","GMT+10");
timeZoneDb.put("JST ","GMT+9");
// etc.
}
}
public static TimeZone getTimeZone(String id)
throws CommandFormatException {
init();
TimeZone tz;
if(timeZoneDb.containsKey(id)) {
tz = TimeZone.getTimeZone((String)timeZoneDb.get(id));
} else {
throw new CommandFormatException("Invalid Timezone value");
}
return tz;
}
}
You could argue that it would be better to have the map in configuration rather than code - perhaps in a properties file. That may be true - but do remember the Pragmatic Programmers' rule 'Your not going to need it'.