Cannot access java lang thread

Issue

I thought it would be fun and informative to learn more about static code analysis by implementing my own custom linter. I’ve been trying to declare the below dependencies:

dependencies "com.android.tools.lint:lint-api:30.1.2" compileOnly "com.android.tools.lint:lint-checks:30.1.2" > 

But Gradle is giving an error that these dependencies cannot be resolved. After digging some, I found that MavenCentral and Google have seemingly different versioning for these libraries, with Google being the version described in the code snippet above and MavenCentral having version 25.3.0 as the latest version. If I swap out the version numbers for those described on MavenCentral, the dependencies can be resolved by Gradle but my custom linter code is completely highlighted in red and gives an error

Cannot access 'java.lang.Object' which is a supertype of my_custom_linter. Check your module classpath for missing or conflicting dependencies 

There are many SO posts regarding this error, and the few that have been resolved were resolved by using the most recent version of an available dependency, which in my case circles back to the first error described in this post.

Project level build.gradle :

buildscript < repositories < google() >dependencies < classpath "com.android.tools.build:gradle:7.0.4" classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.6.10" >> plugins < id 'com.android.application' version '7.1.2' apply false id 'com.android.library' version '7.1.2' apply false id 'org.jetbrains.kotlin.android' version '1.6.10' apply false id 'org.jetbrains.kotlin.jvm' version '1.6.10' apply false >task clean(type: Delete)

plugins < id 'java-library' id 'org.jetbrains.kotlin.jvm' >java < sourceCompatibility = JavaVersion.VERSION_1_7 targetCompatibility = JavaVersion.VERSION_1_7 >dependencies < compileOnly "org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.6.10" compileOnly "com.android.tools.lint:lint-api:25.3.0" compileOnly "com.android.tools.lint:lint-checks:25.3.0" >jar < manifest < attributes("Lint-Registry": "com.example.lint_checks.LintRegistry") >> 

plugins < id 'com.android.application' id 'org.jetbrains.kotlin.android' >android < compileSdk 32 defaultConfig < . >buildTypes < . >compileOptions < sourceCompatibility JavaVersion.VERSION_1_7 targetCompatibility JavaVersion.VERSION_1_7 >kotlinOptions < jvmTarget = '1.7' >buildFeatures < viewBinding true >> dependencies

pluginManagement < repositories < gradlePluginPortal() google() mavenCentral() >> dependencyResolutionManagement < repositories < google() mavenCentral() >> rootProject.name = "Custom Linter" include ':app' include ':lint-checks' 

InputTypeDetector.kt (custom lint class):

/* Entire class highlighted by IDE with error message: Cannot access 'java.lang.Object' which is a supertype of 'com.example.lint_checks.InputTypeDetector'. Check your module classpath for missing or conflicting dependencies */ class InputTypeDetector: LayoutDetector() < companion object < @JvmStatic internal val ISSUE_MISSING_INPUT_TYPE = Issue.create( briefDescription = "Specify inputType attribute to get proper keyboard shown by system.", explanation = "You should specify an inputType for each EditText so that you can get the proper keyboard to be shown by system.", category = Category.USABILITY, priority = 8, severity = Severity.ERROR, implementation = Implementation( InputTypeDetector::class.java, Scope.ALL_RESOURCES_SCOPE ) ).addMoreInfo("https://developer.android.com/training/keyboard-input/style") >override fun getApplicableElements(): Collection? < return listOf( SdkConstants.EDIT_TEXT, "androidx.appcompat.widget.AppCompatEditText", "android.support.v7.widget.AppCompatEditText" ) >override fun visitElement(context: XmlContext, element: CoroutineContext.Element) < if (!element.hasAttribute(SdkConstants.ATTR_INPUT_TYPE)) < // Check if the element has the `android:inputType` attribute context.report( issue = ISSUE_MISSING_INPUT_TYPE, // The issue that we defined above location = context.getLocation(element), message = ISSUE_MISSING_INPUT_TYPE.getExplanation(TextFormat.TEXT) ) >> > 

UPDATE: I’ve verified the lint-api and lint-checks jar files are in the external libraries directory of my project. Gradle has resolved and downloaded these dependencies when requesting version 25.3.0. Why am I getting the error about accessing java.lang.Object and checking my classpath?

I have been following this tutorial

Solution

It’s not clear to me, which dependency resolution repositories you have configured as you don’t provide your settings.gradle file. So I’ll assume that you have configured the following there:

dependencyResolutionManagement < repositories < google() mavenCentral() >> 

Now, while version 25.3.0 of lint-api and lint-checks exists, it has dependency declarations that make it unsuitable for being used as a compile-time dependency. So I’ve upgraded the version to 26.6.4:

 compileOnly "com.android.tools.lint:lint-api:26.6.4" compileOnly "com.android.tools.lint:lint-checks:26.6.4" 

That brings in all required dependencies. But there was still one issue with your InputTypeDetector implementation: the visitElement method signature is wrong in that it uses CoroutineContext.Element as the type of element . It should be org.w3c.dom.Element , though:

 override fun visitElement(context: XmlContext, element: org.w3c.dom.Element) < // … >

With these changes, I could successfully build your lint-checks project (tested with Gradle 7.4.2).

Responding to your comment: I’m afraid, I can’t reproduce the error with your code. Note, however, that I made a few modifications that might make a difference:

• I had to add a missing import in LintRegistry.kt :
  import com.android.tools.lint.detector.api.CURRENT_API
• I have removed .idea/ before importing your project into Android Studio.
• For security reasons, I have removed the gradle/ , gradlew and gradlew.bat files. Then I added a fresh Gradle Wrapper of the same version (7.4.2).

Could you maybe try to do the same and import the project afresh to see if that maybe fixes it? Another thing worth trying to rule out issues with Android Studio: see if building from the command line works, e.g., with ./gradlew lint-checks:build .

Источник

Ошибка: Exception in thread “main” java

Если вы сталкивались с ошибками Exception in thread “main”, то в этой статье я расскажу что это значит и как исправить ее на примерах.

При работе в среде Java, типа Eclipse или Netbeans, для запуска java-программы, пользователь может не столкнуться с этой проблемой, потому что в этих средах предусмотрен качественный запуск с правильным синтаксисом и правильной командой.

Здесь мы рассмотрим несколько общих java-исключений(Exceptions) в основных исключениях потоков, которые вы можете наблюдать при запуске java-программы с терминала.

Исключение в потоке java.lang.UnsupportedClassVersionError

Это исключение происходит, когда ваш класс java компилируется из другой версии JDK и вы пытаетесь запустить его из другой версии java. Рассмотрим это на простом примере:

package com.journaldev.util; public class ExceptionInMain < public static void main() < System.out.println(10); >>

Когда создаётся проект в Eclipse, он поддерживает версию JRE, как в Java 7, но установлен терминал Jawa 1.6. Из-за настройки Eclipse IDE JDK, созданный файл класса компилируется с Java 1.7.

Теперь при попытке запустить эту версию с терминала, программа выдает следующее сообщение исключения.

pankaj@Pankaj:~/Java7Features/bin$java com/journaldev/util/ExceptionInMain Exception in thread "main" java.lang.UnsupportedClassVersionError: com/journaldev/util/ExceptionInMain : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) at java.lang.ClassLoader.defineClass(ClassLoader.java:615) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

Если запустить версию Java1.7, то это исключение не появится. Смысл этого исключения – это невозможность компилирования java-файла с более свежей версии на устаревшей версии JRE.

Исключение java.lang.NoClassDefFoundError

Существует два варианта. Первый из них – когда программист предоставляет полное имя класса, помня, что при запуске Java программы, нужно просто дать имя класса, а не расширение.

Обратите внимание: если написать: .class в следующую команду для запуска программы – это вызовет ошибку NoClassDefFoundError. Причина этой ошибки — когда не удается найти файл класса для выполнения Java.

pankaj@Pankaj:~/CODE/Java7Features/bin$java com/journaldev/util/ExceptionInMain.class Exception in thread "main" java.lang.NoClassDefFoundError: com/journaldev/util/ExceptionInMain/class Caused by: java.lang.ClassNotFoundException: com.journaldev.util.ExceptionInMain.class at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

Второй тип исключения происходит, когда Класс не найден.

pankaj@Pankajs-MacBook-Pro:~/CODE/Java7Features/bin/com/journaldev/util$java ExceptionInMain Exception in thread "main" java.lang.NoClassDefFoundError: ExceptionInMain (wrong name: com/journaldev/util/ExceptionInMain) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:791) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:480)

Обратите внимание, что класс ExceptionInMain находится в пакете com.journaldev.util, так что, когда Eclipse компилирует этот класс, он размещается внутри /com/journaldev/util. Следовательно: класс не найден. Появится сообщение об ошибке.

Исключение java.lang.NoSuchMethodError: main

Это исключение происходит, когда вы пытаетесь запустить класс, который не имеет метод main. В Java.7, чтобы сделать его более ясным, изменяется сообщение об ошибке:

pankaj@Pankaj:~/CODE/Java7Features/bin$ java com/journaldev/util/ExceptionInMain Error: Main method not found in class com.journaldev.util.ExceptionInMain, please define the main method as: public static void main(String[] args) Exception in thread "main" java.lang.ArithmeticException

Всякий раз, когда происходит исключение из метода main – программа выводит это исключение на консоль.

В первой части сообщения поясняется, что это исключение из метода main, вторая часть сообщения указывает имя класса и затем, после двоеточия, она выводит повторно сообщение об исключении.

Например, если изменить первоначальный класс появится сообщение System.out.println(10/0) ; Программа укажет на арифметическое исключение.

Exception in thread "main" java.lang.ArithmeticException: / by zero at com.journaldev.util.ExceptionInMain.main(ExceptionInMain.java:6)

Методы устранения исключений в thread main

Выше приведены некоторые из распространенных исключений Java в потоке main, когда вы сталкиваетесь с одной из следующих проверок:

1. Эта же версия JRE используется для компиляции и запуска Java-программы.
2. Вы запускаете Java-класс из каталога классов, а пакет предоставляется как каталог.
3. Ваш путь к классу Java установлен правильно, чтобы включить все классы зависимостей.
4. Вы используете только имя файла без расширения .class при запуске.
5. Синтаксис основного метода класса Java правильный.

Средняя оценка 2.1 / 5. Количество голосов: 16

Спасибо, помогите другим — напишите комментарий, добавьте информации к статье.

Видим, что вы не нашли ответ на свой вопрос.

Напишите комментарий, что можно добавить к статье, какой информации не хватает.

Источник