Given this Java interface in okhttp3.ws.WebSocketListener:
public interface WebSocketListener {
(...)
void onFailure(IOException e, Response response);
(...)
}
Kotlin assumes a signature like this:
override fun onFailure(e: IOException, response: Response) {
e.printStackTrace()
(...)
}
If I now start my app in Airplane mode, it attempts to connect to the web socket. The web socket can't connect and returns a 'null' response to 'onFailure()' - which is correct at this point. But Kotlin checks that the response is null and crashes my app even before it can print the exception stack trace.
So: How do I force Kotlin to assume '#Nullable' for anything that is not annotated?
The setting should be project-wide, not system-wide.
Several searches on Google gave no usable results. So I wonder whether I am the first one to encounter this issue and whether Kotlin is ready for use already.
Do I really need to convert the class back to Java?
When dealing with a java type having no nullability information, you
can work with it as either a nullable or a nonnull type. meaning in your case you can simply change the type of response to Response?.
override fun onFailure(e: IOException, response: Response?) {
e.printStackTrace()
(...)
}
From Kotlin in Action
sometimes Java
code contains information about nullability,
expressed using annotations. When this
information is present in the code, Kotlin
uses it. Thus #Nullable String in Java is
seen as String? by Kotlin, and #NotNull String is just String. The interesting question is what happens when the annotations aren’t
present. In that case, the Java type becomes a platform type in
Kotlin.
PLATFORM TYPES
A platform type is essentially a type for which
Kotlin doesn’t have nullability information; you can work with it as
either a nullable or a nonnull type. This means, just
as in Java, you have full responsibility for the operations you
perform with that type.
Related
I have a multi-module maven Springboot project in Java.
Resource classes are generated from yaml, so that, e.g.
type: object
required:
- myFlag
properties:
myFlag:
type: boolean
example: false
yields a resource class with a Boolean property
#JsonProperty("myFlag")
private Boolean myFlag;
My problem begins when I test ways someone could post this resource with wrong values (I expect success only when this field is posted with JSON yielding a boolean, e.g.
{
"main": "whatever",
"subpart": {
"myFlag": false
}
}
).
However, jackson evidently tolerates numbers instead of booleans. I'd like it not to. I have looked for tuning settings that might have a bearing on this, but didn't find any obvious ones (for example
spring.jackson.deserialization.accept-float-as-int=false
solved a related problem of parsing that was too lenient for our taste.) I tried setting several but haven't been able to get a HttpMessageNotReadableException exception -- the usual variety for these kinds of events -- to fire.
Incidentally, these exceptions fire as hoped for in unit tests such as:
#Test
public void post_with_Integer_instead_of_Boolean_yields_400_Status() throws Exception {
ResultActions resultActions = mockMvc
.perform(MockMvcRequestBuilders
.post(PATH)
.contentType(MediaType.APPLICATION_JSON_UTF8)
.content("{\"main\": \"whatever\", \"subpart\": {\"myFlag\": 123}}"));
resultActions.andExpect(status().is(400));
}
but, alas, not when the service is "really" running. This would seem to be a clue, but I haven't been able to figure out how to use it.
I'd be grateful for any pointers that would help me get a handle on this.
I'd like to ask something confuses me a lot. Here is the scenario, lets say I have a method preparePayload that takes some argument like messageType, destAddr etc. The duty of method is construct a fully payload (with headers, prefixes etc). Here is the problem, I want to return statusCode (which is enum, like STATUS_OK,STATUS_INVALID_DEST, STATUS_INVALID_MSG_TYPE etc.), and than respect to return status I'd like to implement my logic. But if there is no error (STATUS_OK), I need the prepared payload to move on. So my method should return eighter payload or status code.
In C language, simply sending payload buffer address as an argument to preparePayload method solves the problem perfectly. When the method returns, simply reading payload from the buffer address and moving on the application works. How can I implement this kind of logic in Java?
In addition, preparePayload method is just an example I gave, so the methods I implemented may return String, int[], some class object that I wrote etc. I mean, the type of object that method should return in success case may vary.
Any suggestion will very welcome.
Besides changing to exceptions, there is one more hackish way to allow for "input/output" parameters, like:
public ResultEnum preparePayLoad(List<PayLoad> toPrepare, ... other args) {
...
PayLoad newThing = ...
...
toPrepare.add(newThing);
return someEnum;
}
So, you could use such an approach to "emulate" the "C style"; but the more Java/OO would be
public PayLoad preparePayLoad(args) {
...
PayLoad newThing = ...
...
return newThing;
}
and to throw (checked or unchecked) exceptions for error situations.
The correct idiom in Java is to throw a checked exception (some will say unchecked is better, there is a slight controversy here).
The three important mechanisms you get is:
automatic propagation of error codes up the stack. If you do not handle some type of error in your code (don't check for it), it will get propagated up as an exception - you don't need layered checks (and avoid an error of returning an invalid result, quite common in C),
exceptions work as an "alternate return type", ensuring type safety for both correct results and the error messages (which are full objects - and can contain any number of useful information besides the code)
checked exceptions allow the compiler to check if all the important error statuses are handled in some way.
You can create a class, a wrapper, for example:
public class Result {
public enum Status {
STATUS_OK, STATUS_INVALID_DEST, STATUS_INVALID_MSG_TYPE
}
Status status;
String payload;
}
that will be returned by your method preparePayload. Then, when you call your method, you can do it like this:
Result result = preparePayload(args);
//better will be a switch with case for each possible status
if (result.state == Result.State.STATUS_OK)
//do what you want with payload
System.out.println(result.payload);
else
return;
I've got a simple class which get's validated using the boolean isValid() method, which works and of course the error message is at class/type level.
Here's my simple class:
public class NewPasswordDTO {
#NotNull
public String password;
#NotNull
public String confirmation;
#AssertTrue(message="Passwords must match.")
protected boolean isValid() {
return password.equals(confirmation);
}
}
But what I really want is something like that:
public class NewPasswordDTO {
#NotNull
#Equals("confirmation", message="...")
public String password;
#NotNull
public String confirmation;
}
So the error message would be set at field level and not at class/type level.
Is this possible somehow? Maybe using a custom Validator for that class?
Thanks in advance!
SOLUTION:
Thanks to Gunnar! I've just came up with a nice, universal solution :-). I simply used (means copy & paste) the code from Hibernates #ScriptAssert and ScriptAssertValidator and modified it slightly:
#ScriptAssert:
Add new String field(). (this is where the error message gets appended)
ScriptAssertValidator:
Inside the initialize method, make sure to also save the fieldName and message properties, because we need to access them in the next step
Add this snippet at the bottom of isValid method:
context.buildConstraintViolationWithTemplate(errorMessage)
.addPropertyNode(fieldName).addConstraintViolation();
Also add context.disableDefaultConstraintViolation(); somewhere inside the isValid method to not generate the default error message which else would get appended at class level.
And that's it. Now I can use it like that:
#FieldScriptAssert(lang="javascript", script="_this.password.equals(_this.confirmation)", field="password", message="...")
public class NewPasswordDTO { ... }
You either could use the #ScriptAssert constraint on the class (note that a constraint should always be side-effect free, so it's not a good idea to alter the state of the validated bean; instead you should just check whether the two fieldss match) or you implement a custom class-level constraint.
The latter also allows to point to a custom property path for the constraint violation, which it allows to mark the "confirmation" property as erroneous instead of the complete class.
Simple answer : It is not (unless you implement it) :http://docs.oracle.com/javaee/6/api/javax/validation/constraints/package-summary.html shows all annotation constraints.
Of course you could inject your string as a resource in your class by #producer and so on (which recently is discussed to be removed in jdk8), but you could not use this value for your assert. In reply to the comment:
This was asuming that the nature is a constant string which you would like to use as a string resource.And then of course it is possible to write your own class based on java.lang.string with a #Producer which is then #Inject - able. Though it is certainly not the way I personally would deal with constant strings.
If you’re using the Spring Framework, then as an alternative to the #ScriptAssert using a JSR 223 scripting, you can use the #SpELAssert that uses the Spring Expression Language (SpEL). The advantage is that it doesn’t need any JSR 223 compliant scripting engine which may not be available on some environments. See this answer for more information.
recently I found a function like this in a generic JSR245 portlet class:
public class MyGenericPortlet extends GenericPortlet {
#Override
public void processAction(ActionRequest rq, ActionResponse rs) throws PortletException{
String actParam = rq.getParameter("myAction");
if( (actParam != null) && (!("").equals(actParam))) {
try{
Method m = this.getClass().getMethod(actParam, new Class[]{ActionRequest.class, ActionResponse.class});
m.invoke(this, new Object[]{rq, rs});
}
catch(Exception e){
setRequestAttribute(rq.getPortletSession(),"error", "Error in method:"+action);
e.printStackTrace();
}
}
else setRequestAttribute(rq.getPortletSession(),"error", "Error in method:"+action);
}
}
How safe is such code? As far as I can see the following problems might occur:
A parameter transmitted from the client is used unchecked to call a function. This allows anyone who can transmit data to the corresponding portlet to call any matching function. on the other hand the function to be called must have a specific interface. Usually such functions are very rare.
A programmer might accidentaly add a function with a corresponding interface. As only public functions seem to be found this is no problem as long as the function is private or protected.
The error message can reveal information about the software to the client. This shouldn't be a problem as the software itself is Open Source.
Obviously there is some room for programming errors that can be exploited. Are there other unwanted side effects that might occur? How should I (or the developers) judge the risk that comes from this function?
If you think it is safe, I'd like to know why.
The fact that only public methods with a specific signature can be invoked remotely is good. However, it could be made more secure by, for example, requiring a special annotation on action methods. This would indicate the developer specifically intended the method to be an invokable action.
A realistic scenario where the current implementation could be dangerous is when the developer adds an action that validates that the information in the request is safe, then passes the request and response to another method for actual processing. If an attacker could learn the name of the delegate method, he could invoke it directly, bypassing the parameter safety validation.
I am using GWT-RPC to call an ANTLR grammar.
If the grammar fails, I create an object containing the errors/exceptions that were thrown by the grammar and return it to the client.
When I do this I get the exception:
com.google.gwt.user.client.rpc.SerializationException: Type 'org.antlr.runtime.NoViableAltException' was not included in the set of types which can be serialized by this SerializationPolicy or its Class object could not be loaded.
I have found that there is an identical class with the addition of a public no argument constructor (needed for GWT-RPC serialization) in the com.google.appengine.repackaged.org.antlr.runtime package.
How do I convert the org.antlr.runtime.NoViableAltException into a com.google.appengine.repackaged.org.antlr.runtime.NoViableAltException?
Do you need the exceptions themselves? I'd think not - you probably need the message or at most the stack trace. Since you're repackaging the exceptions anyway, just repack the needed strings and send those over the wire.
As an alternative for creating new Exceptions that can be serialized, I have made my Parser override the emitErrorMessage method from BaseRecognizer.
#members {
#Override
public void emitErrorMessage(String msg) {
// The original prints to stdout.
// You can do what you like with the message.
}
}
As Tassos suggested in his answer, I did not actually need the exception, just the message from it.