We Keep Coding

Gradle Cannot have abstract method

I'm developing a custom binary Gradle plugin, following the pattern shown here.
My extension, VersionInfoExtension is abstract with abstract methods, just like the BinaryRepositoryExtension in the documentation. My task is also abstract, with abstract methods for the parameters, like the LatestArtifactVersion in the documentation. When I test, I get the following error:
An exception occurred applying plugin request [id: 'com.example.version-info']
> Failed to apply plugin 'com.example.version-info'.
> Could not create an instance of type com.example.gradle.version.VersionInfoExtension.
> Could not generate a decorated class for type VersionInfoExtension.
> Cannot have abstract method VersionInfoExtension.jars().
What am I missing? Are there any good examples of making this work?

I'm using gradle 7.X and Kotlin.
The "Cannot have abstract method myPropertyName" error is reported when the method name is prefixed by "is":
abstract val isRegistered: Property<Boolean>
That was annoying to track down. The type doesn't seem to matter.
The solution was to remove "is" from the name.

The problem here seems to be the name of the abstract method.
All configurable methods must be bean-methods - this holds for both Extensions and Tasks.
So you should have used (assuming a java class):
abstract Property<String> getJars()
instead of
abstract Property<String> jars()

In addition to #Richard Sitze answer, in my case it was a custom setter function that was used in tests only (annotated with #TestOnly) was preventing generating the class.
I had declared serializable object as #Input
#get:Input
abstract val myPropertry : Property<MyObject>
#Test
fun setMyProperty(obj : MyObject){
//...
}
Somehow the name of the function interfered with generating the property setter along generation of the setter.

Android app cannot install

While developing an app in AIDE for Android I have come across this error. The app would compile successfully but wouldn't install, reporting this error:
Could not run the App directly as root. Consider disabling direct running in the settings.
WARNING: linker: app_process has text relocations. This is wasting memory and is a security risk. Please fix.
pkg: /storage/sdcard/AppProjects/MyProgram/bin/MyProgram.apk
Failure [INSTALL_FAILED_DEXOPT]
exit with 0
I researched what could cause this and mainly came across reasons like "certificate error, try resigning the package" and "setting a permission twice in the manifest" and other stuff, none of which have worked.

Your problem: Java thinks you define two methods with the same signature.
Java method signature definition: https://docs.oracle.com/javase/tutorial/java/javaOO/methods.html
method declarations have six components, in order:
1.Modifiers—such as public, private, and others you will learn about later.
2.The return type—the data type of the value returned by the method, or void if the method does not return a value.
3.The method name—the rules for field names apply to method names as well, but the convention is a little different.
4.The parameter list in parenthesis—a comma-delimited list of input parameters, preceded by their data types, enclosed by parentheses, ().
If there are no parameters, you must use empty parentheses.
An exception list—to be discussed later.
The method body, enclosed between braces—the method's code, including the declaration of local variables, goes here.
As you can see above, the specification of generic classes is NOT part of the java method signature. Therefore java detects two add-methods with the same signature.

I found where the problem resides. It was in some code which looked very much like this:
public class Builder<T extends Base> {
private final List<Def1> subDefs1 = new ArrayList<>();
private final List<Def2> subDefs2 = new ArrayList<>();
public Builder<T> add(final Collection<Def1> ds) {
subDefs1.addAll(ds);
return this;
}
public Builder<T> add(final Collection<Def2> ds) {
subDefs2.addAll(ds);
return this;
}
}
interface Base {}
final class Def1 implements Base {}
final class Def2 implements Base {}
I had these add methods, which both take a Collection of some kind. The problem must be something to do with Java's lacklustre generics and the dexing process, I guess...

Android - why do I get this lint error: "This class should be public (android.support.v7.internal.widget.ActionBarView.HomeView)"

This class should be public
(android.support.v7.internal.widget.ActionBarView.HomeView)
Issue: Ensures that classes registered in the manifest file are
instantiatable Id: Instantiatable
Activities, services, broadcast receivers etc. registered in the
manifest file must be "instantiatable" by the system, which means that
the class must be public, it must have an empty public constructor,
and if it's an inner class, it must be a static inner class.
This lint error with the Support Library - which occurs when I try to export my (unobfuscated) Android project - is also described in this SO question. But why does this error occur in the first place? (Is it a bug with the Support Library?)
The suggested advice in that question is to just disable/downgrade the lint message to a 'Warning', but is it perfectly safe/correct to do that (i.e., maybe that is papering over some cracks?) or is there a better solution?

"constructor has private access" error message

I'm working in Java and have come across an incredibly odd error. I have a very basic class as follows:
public class ClassA{
private static Logger log = Logger.getLogger(ClassA.class.getName());
private boolean trace;
public ClassA(){
trace = log.isTraceEnabled();
}
public void doSomething(){
//does stuff
}
}
I can use this class just fine within my current project. However, when I build, package, and install to my local repo (using Maven, no remote artifact repo set up), other projects cannot properly use this class because they cannot instantiate it. When I try anything like:
ClassA classA = new ClassA();
I get the following compilation error:
ClassA() has private access in [package].ClassA
I've decompiled the .jar in my local repo to ensure the constructor is present and is public - it is. I've also used the -U flag to force updates and the compilation continues to fail. What could be causing this error?

Maybe you have some other ClassA.class file somewhere in the classpath. Check all the jars used by the project that cannot call the constructor: one of them should contain an old version of your class.

My only thought is that you have a problem with your package. Make sure to define the package at the top of the source file for classA using the package keyword. When you call it ensure that the file is in include list with the include keyword. You could be running into the error because ClassA exists in some default package and that is what you are actually calling instead of calling your locally made ClassA class. The code you posted looks fine and you have already double checked to ensure the changes have taken effect in your repository.

//for those with Kotlin-Java mixed projects:
If the said file (With constructor) is in Kotlin and is being used in Java:
Instead of A a = new A(); //which causes the said error
Use A.INSTANCE. …

I have this error, where write "private", instead "public" for class constructor;

Eclipse warning: "<methodName> has non-API return type <parameterizedType>"

My co-worker and I have come across this warning message a couple times recently. For the below code:
package com.mycompany.product.data;
import com.mycompany.product.dao.GenericDAO;
public abstract class EntityBean {
public abstract GenericDAO<Object, Long> getDAO();
// ^^^^^^ <-- WARNING OCCURS HERE
}
the warning appears in the listed spot as
EntityBean.getDAO() has non-API return type GenericDAO<T, ID>
A Google search for "has non-API return type" only shows instances where this message appears in problem lists. I.e., there's no public explanation for it.
What does this mean? We can create a usage problem filter in Eclipse to make the message go away, but we don't want to do this if our usage is a legitimate problem.
Thanks!
EDIT: This warning doesn't have to do with the parameterization, as this declaration of getFactory() also results in the same warning:
public abstract class EntityBean {
protected DAOFactory getFactory() {
return DAOFactory.instance(DAOFactory.HIBERNATE);
}
}

Figured it out.
These classes (GenericDAO and DAOFactory as return types) and EntityBean were in different packages. One of the packages (the one containing EntityBean) was listed in the Export-Package: section of the manifest file, and the other package (DAOs) was not. The net effect is that the DAO classes were non-API and were being returned by an API type.
Thanks all, especially to JRL for orienting me in the right direction.

Have you looked at the following Eclipse docs: API rules of engagement and API Errors and Warnings Preferences ?