Can anyone enlighten me about the difference of getRealOneOfs and getOneOfs?
https://developers.google.com/protocol-buffers/docs/reference/java/com/google/protobuf/Descriptors.Descriptor.html#getOneofs--
Every proto3 optional field is placed into a one-field oneof, called a "synthetic" oneof, as it was not present in the source .proto file. The getOneOfs method will return all oneofs, including synthetic ones, whereas getRealOneOfs will exclude the synthetic oneofs.
More info here (in the Background section):
https://github.com/protocolbuffers/protobuf/blob/main/docs/implementing_proto3_presence.md
Related
In my company, we're starting to mix Kotlin with Java and found a curious scenario. When I place a Java annotation on a property parameter of a constructor in a Kotlin class, and use a non-existent reference as one of the annotation's parameters, IntelliJ visually indicates an error, but both its build (Ctrl+F9) and maven's build compile normally, without errors.
We're using Java 8 and Kotlin 1.4.20.
Here's the annotation, declared as a Java file:
#Retention(RetentionPolicy.RUNTIME)
#Target({ElementType.FIELD, ElementType.METHOD})
public #interface Required {
String scope() default "ABC";
}
And here's the Kotlin class using the annotation (class Abc does not exist):
data class Test(
// Compiles normally
#Required(scope = Abc.X)
val text: String
) {
// Compilation error
#Required(scope = Abc.X)
fun x() {
}
}
As mentioned in the code comments, the same annotation placed in a Kotlin function behaves as expected (that is, the code does not compile). An equivalent annotation declared as a Kotlin file also behaves as expected.
When the code is run, the scope variable assumes its default value, so there are no runtime errors.
I've already tried to:
Invalidate IntelliJ cache and restart.
Switch the annotation declaration from #Required(scope = Abc.X) to #field:Required(scope = Abc.X)
I also tried to replicate the behaviour in a brand new project without inheriting from the company's base maven project, but to no avail.
Honestly, I think there's a huge possibility that it is something related to the company's project. I know I haven't specified what my company uses and all the configuration (in fact, the question would get way too big if I did that), but I hope that even with just the basic problem someone may be able to help.
This is a Kotlin compiler bug: argument list is not analyzed for usage of Java annotation with #Target(FIELD) on Kotlin property.
For updates on this please follow the issue https://youtrack.jetbrains.com/issue/KT-33822.
I have created a Java client to interact with a SOAP webservice using Axis2 (1.7.6) as code generator. The problem is with some inputs the client is throwing an exception with the message:
org.apache.axis2.AxisFault: Invalid white space character (0x4) in text to output (in xml 1.1, could output as a character entity)
It seems the serialiser is hitting some chars considered invalid to XML spec. I have seen that problem around but no definitive answer or the fix. I'm not using Spring or any other dependency injection framework, it's a standalone application, so I need to configure the inners of Axis2 by hand.
Any ideas on how to fix/configure the client properly?
After some research I found this behaviour is due to one default setting of the lib Woodstox (Axis2 dependency), that uses the class com.ctc.wstx.api.InvalidCharHandler.FailingHandler as default implementation of the interface com.ctc.wstx.api.InvalidCharHandler, used inside com.ctc.wstx.sw.XmlWriter and invoked in the serialisation process. This means: when the component hits characters considered invalid to XML, it’ll throw an error.
Woodstox provides another implementation of the interface com.ctc.wstx.api.InvalidCharHandler, the one called com.ctc.wstx.api.InvalidCharHandler.ReplacingHandler that instead of throwing errors will replace those chars for something else. But how to do that?
The class com.ctc.wstx.stax.WstxOutputFactory inside Woodstox contains several configurations, one of them being the invalid char handler. Though, it's not configurable by some magic system wide property, instead, by the method com.ctc.wstx.stax.WstxOutputFactory#setProperty, that takes as arguments one string and one object.
So first, you'll have to extend that factory and set the property com.ctc.wstx.outputInvalidCharHandler with an instance of com.ctc.wstx.api.InvalidCharHandler.ReplacingHandler that takes as argument the char you want to replace the invalid ones with. Like this:
package my.package;
import com.ctc.wstx.stax.WstxOutputFactory;
public class MyWstxOutputFatory extends WstxOutputFactory {
public MyWstxOutputFatory() {
setProperty(
com.ctc.wstx.api.WstxOutputProperties.P_OUTPUT_INVALID_CHAR_HANDLER,
new com.ctc.wstx.api.InvalidCharHandler.ReplacingHandler(' '));
}
}
The second, trickiest and undocumented step is how to register your implementation as the factory Woodstox'll use. You'll have to create a file named META-INF/services/javax.xml.stream.XMLOutputFactory simply containing the name of your factory, in this case, the string:
my.package.MyWstxOutputFatory
Place this file in such a way it's included in your project's resulting jar. In my case I placed like: src/main/resources/META-INF/services/javax.xml.stream.XMLOutputFactory.
And you're done!
I've been checking ContextWrapper.java in android sdk and noticed that there are some methods which are annotated in javadoc by #remove. I assume, it is an indicator to give lint warnings in IDE but that'd be great to know exactly what it is and why they needed such as thing in the first place instead of removing completely.
/** #removed */
#Override
public SharedPreferences getSharedPreferences(File file, int mode) {
return mBase.getSharedPreferences(file, mode);
}
Like #hide, it causes Doclava (a Javadoc doclet Android uses to generate SDK documentation and API signature text files) to omit the annotated member from generated documentation and, if the -api flag is passed, from the generated API signature text file. If the -removedApi flag is also used, members annotated #remove will be included in the removed.txt signature file.
I created a simple project using Drools and Java basing on this tutorial. It worked perfectly, so I adapted it to what I wanted to do. My DRL files use mvel dialect (instead of Java dialect) and initializing takes place in rule "initial" inside DRL file. You can see this project (source code as well as libraries and DRL file) here. My DRL file looks more less like the following:
package omd
dialect "mvel"
declare ocenaKwalifikacji
value : Double
end
declare ocenaKandydata
value : Double
end
declare ocenaTestow
value : Double
end
declare ocenaRozmowy
value : Double
end
rule "ocenakandydata/1 "
when
$ocenaRozmowy : ocenaRozmowy(value==5.0000)
$ocenaKwalifikacji : ocenaKwalifikacji(value==5.0000)
$ocenaTestow : ocenaTestow(value==5.0000)
then
insert(new ocenaKandydata (5.0000))
System.out.println("ocenaKandydata setting to 5.0000)");
end
rule "ocenakandydata/2 "
when
$ocenaRozmowy : ocenaRozmowy(value==5.0000)
$ocenaKwalifikacji : ocenaKwalifikacji(value==4.0000)
$ocenaTestow : ocenaTestow(value==5.0000)
then
insert(new ocenaKandydata (5.0000))
System.out.println("ocenaKandydata setting to 5.0000)");
end
...
rule "ocenakandydata/64 "
when
$ocenaRozmowy : ocenaRozmowy(value==2.0000)
$ocenaKwalifikacji : ocenaKwalifikacji(value==2.0000)
$ocenaTestow : ocenaTestow(value==2.0000)
then
insert(new ocenaKandydata (2.0000))
System.out.println("ocenaKandydata setting to 2.0000)");
end
rule "initial"
when
then
/*DATA*/
insert(new ocenaKwalifikacji(5.0));
insert(new ocenaRozmowy(2.0));
insert(new ocenaTestow(2.0));
end
Everything works fine, but the package in the first line must be omd although all classes are in the com.sample package. When I changed the package name to com.sample, I got the following error:
Error creating field accessors for TypeDeclaration 'ocenaKandydata' for type 'ocenaKandydata'.
And now there is all the fun...
I created similar project for Android. I used the same code, but the libraries come from another example (the previous ones did put classes in java.* or javax.* packages, which is not allowed while programming for Android). You can see this project here. I put the psc-zatrudnienie-ocena_kandydata.drl file in the smartphone storage under /storage/emulated/0/drools/psc-zatrudnienie-ocena_kandydata.drl. When the package in the DRL file is pl.me.drools2tp (the same as all classes in Android app are placed in), I get following errors (similar to those ones above):
Error creating field accessors for TypeDeclaration 'ocenaKwalifikacji' for type 'ocenaKwalifikacji'
Error creating field accessors for TypeDeclaration 'ocenaKandydata' for type 'ocenaKandydata'
Error creating field accessors for TypeDeclaration 'ocenaTestow' for type 'ocenaTestow'
Error creating field accessors for TypeDeclaration 'ocenaRozmowy' for type 'ocenaRozmowy'
and when I change the package name in DRL file to something another, the errors are as following:
Class 'ocenaKwalifikacji' not found for type declaration of 'ocenaKwalifikacji'
Class 'ocenaKandydata' not found for type declaration of 'ocenaKandydata'
Class 'ocenaTestow' not found for type declaration of 'ocenaTestow'
Class 'ocenaRozmowy' not found for type declaration of 'ocenaRozmowy'
Could anybody give me some advice about this? What does exactly "field accessor for TypeDeclaration" mean? All the classes which are mentioned in declare part of the DRL file are also defined in Java, have value field and both getters and setters. The dekstop version uses Drools 5.3.0 (there is a huge sort of JAR files from http://download.jboss.org/drools/release/5.3.0.Final/ as it was said on TutorialsPoint site). There is also one question connected with mine: Integration of Drools (Expert System) with Android Projects
I will be very grateful for some help, tips or examples.
Best regards,
Peter.
BTW I use IntelliJ and Android Studio.
Do not compile with Java classes in com.sample and a DRL file in the same package with declare statements contradicting the Java classes.
From your question I assume that you have the same duplication of a class being declared in DRL in contrast or addition to some Java code.
Simply omit all the declare statements and stick with the Java classes or keep the declares and move the Java classes into another package.
BTW: make your class fields private.
I am writing a java annotation processor for java 7 source code.
And surely, I can use javax.annotation.processing.filer to help me generate the file under project directory automatically.
ex: annotation is #becare
public interface test {
#becare
int compare(int a, int b);
}
my annotation processor's job is when it detects the given annotation #becare, it will generate the file for me.
My Question is that if I remove the annotation from the previous code snippet, can I let annotation processor to be aware that and delete the file it just created?
Or is there any workaround to help me achieve this ?
Thanks in advance.
When you create the generated file you declare that it's linked to your 'test' interface like this:
Elements eltUtils = processingEnv.getElementUtils();
filer.createSourceFile("testGenerated", eltUtils.getTypeElement("test"));
When the source is deleted, the processor will remove generated file like javadoc says:
If there are no originating elements, none need to be passed. This information may be used in an incremental environment to determine the need to rerun processors or remove generated files. Non-incremental environments may ignore the originating element information.