I am getting an error as "The package java.util is accessible from more than one module: error" while importing file in java.
It seems like you messed things up in your module path. The error message indicates that you depend on multiple java modules that all export the java package java.util.
This is also called split package, as some classes in this package might be loaded from one module the others from another module.
With the new Java module system introduced with Java 9 this is strictly forbidden.
java.util should only be present in java.base module and nowhere else.
If you need further information, please tell us how you built and try to run your application.
I am trying to do the same thing in Java 11 that could be done with -Xbootclasspath/p:path in pre java 9.
As a simple example I modified one of the valueOf methods of java.lang.Integer and compiled the project with:
javac --module-source-path=src/java.base --patch-module java.base=src/java.base -d mods $(find src -name '*.java')
I then ran a simple sample using:
java --patch-module java.base=<pathToMyModifiedJavaBaseClasses> -p lib -m my.moduleA/my.moduleA.Main
That worked an I'm seeing the modifications displayed (a simple print out I did from valueOf).
When I try, however, to do the same thing with java.lang.ClassLoader I get the following error when executing the program (compile works):
Error occurred during initialization of boot layer
java.lang.LinkageError: loader 'bootstrap' attempted duplicate class definition for java.lang.invoke.SimpleMethodHandle.
I do not even need to make changes in java.lang.ClassLoader. The sheer existence of that class in my patch folder seems to be provocing this error. (I only wanted to add a field though at the bottom of the class)
NOTE: I just figured that it works when the ClassLoader class is compiled with Eclipse. One of the few differences I know is that the Eclipse compiler does not seem to follow JEP 280 yet. But there are invokedynamic instructions in the bytecode resulting from javac as well, so I doubt that this is the problem.
You did already point into the right direction. It works when you compile the class with your current version of Eclipse, because that compiler does not follow JEP 280 yet, so it doesn’t use invokedynamic for string concatenation.
This does not imply that using invokedynamic in ClassLoader is problematic in general. It is only problematic in certain critical code paths executed during the bootstrapping of the java.lang.invoke package and apparently, this class does use string concatenation on this code path.
In case of javac, you can force the use of the old string concatenation code via the option
-XDstringConcat=inline. Looking into the bytecode of the ClassLoader.class as shipped with the JDK, it seems this class has been compiled with this option. In fact, looking at some samples, it seems the entire java.base module has been compiled with that option, in contrast to, e.g. java.desktop, whose classes use invokedynamic for string concatenation.
So the conclusion is, to patch classes in the java.base module (in OpenJDK and derivatives), compile them using the -XDstringConcat=inline option when using javac.
I have my old codebase which currently uses java8.
I am migrating my codebase to use jdk9-ea. But it looks like all the sun.font classes are now not available like the way they used to be earlier
error: package sun.font does not exist
More specifically i am using
CompositeFont
Font2D
FontDesignMetrics
FontManager
FontManagerFactory
SunFontManager
and more..
A feature of the module system is that it allows library developers to strongly encapsulate implementation details due to the new accessibility rules. In a nutshell, most types in sun.* and com.sun.* packages will no longer be accessible. This is in line with Sun and later Oracle stating that these packages are not meant for public consumption.
A workaround is to export these packages at compile and launch time with a command line flag:
--add-exports java.desktop/sun.font=ALL-UNNAMED
This exports the package sun.font from the module java.desktop to all modules including the unnamed module, which is the one that collects all classes on the class path.
I am developing an android app which process speech and I have speech basic project (dependency for android project) ready on JAVA so I compiled JAVA project in eclipse in JAVA 7 compiler and exported that java project as a runnable jar.
I put this jar into my android studio project's libs folder and by right clicking selected AS A library, I got build successful message. But when I try run the android project it gives me error saying,
FATAL EXCEPTION: main Process: in.automator.automator, PID: 4242
java.lang.NoClassDefFoundError: jar_filename.Storage.class_in_jar_file
but the said class is there in the jar file, the only doubtful thing is the mentioned class file looks something like this
import javax.sound.sampled.AudioFileFormat;
import javax.sound.sampled.AudioFormat;
import javax.sound.sampled.AudioFormat.Encoding;
import marf.util.InvalidSampleFormatException;
public class MARFAudioFileFormat extends AudioFileFormat {
....
...
....
}
It refers javax.sound.sampled, so possibly that might causing the problem.
I tried searching on the google for the problem but didn't got the solution which can resolve the issue. I tried everything.
I am using JRE 7 in android studio and exporting java project in Compiler & itself.
How to resolve this error?
Thanks in advance.
You are correct, the problem lies in the fact that the library you're trying to depend on, in turn depends on the javax package hierarchy. Android does not provide javax, so those classes don't exist at runtime (even though they do exist in your computer's JDK, so your compiler doesn't complain - it's basically the same as not having a particular DLL installed that a program on your PC needs).
The NoClassDefFoundError is being thrown on the class that first references the invalid class dependencies, which is probably what's confusing. That class may indeed actually exist in your jar, but it requires classes that don't exist in order to complete its definition - so in effect, your class is not fully defined.
The only way around this is to figure out a way to do whatever you're after, without the javax namespace. I have heard of a few attempts to try to port javax.* into Android, but they never end well - many of the javax classes end up boiling down to native calls, which also won't exist on Android.
I'm getting desperate with this Problem: I want to export/run my Android Application with one additional .jar I added to the buildpath. I'm sure I added it correctly, there are 5 other .jars included and they all work fine.
with this special one I get the mentioned error.
I've already tried everything that can be found in this question:
"Conversion to Dalvik format failed with error 1" on external JAR
and several other links google spat out. The main Problem is, I actually do not understand what the message I appended want's to tell me because if I add all the jars to a "normal" javaproject, it runs perfectly fine...
Developing on Android 4.0.3,
proguard 4.8,
adt 16.0.1.v201112150204-238534,
eclipse 3.7.1.r37
please help me
[2012-07-18 10:45:48 - myapp] Dx warning: Ignoring InnerClasses attribute for an anonymous inner
class (iaik.xml.crypto.XSecProvider$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced
by a compiler that did not target the modern .class file format. The
recommended solution is to recompile the class from source, using an
up-to-date compiler and without specifying any "-target" type options.
The consequence of ignoring this warning is that reflective operations
on this class will incorrectly indicate that it is not an inner
class.
...
...
[2012-07-18 10:45:48 - myapp] Dx warning: Ignoring InnerClasses attribute for an anonymous inner
class (iaik.xml.crypto.XSecProvider$2) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced
by a compiler that did not target the modern .class file format. The
recommended solution is to recompile the class from source, using an
up-to-date compiler and without specifying any "-target" type options.
The consequence of ignoring this warning is that reflective operations
on this class will incorrectly indicate that it is not an inner
class.
Ill-advised or mistaken usage of a core class (java.* or javax.*) when
not building a core library.
This is often due to inadvertently including a core library file in
your application's project, when using an IDE (such as Eclipse). If
you are sure you're not intentionally defining a core class, then this
is the most likely explanation of what's going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example, from a
non-Android virtual machine project. This will most assuredly not
work. At a minimum, it jeopardizes the compatibility of your app with
future versions of the platform. It is also often of questionable
legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine distribution,
as opposed to compiling an application -- then use the
"--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact building an
application, then be forewarned that your application will still fail
to build or run, at some point. Please be prepared for angry customers
who find, for example, that your application ceases to function once
they upgrade their operating system. You will be to blame for this
problem.
If you are legitimately using some code that happens to be in a core
package, then the easiest safe alternative you have is to repackage
that code. That is, move the classes in question into your own package
namespace. This means that they will never be in conflict with core
system classes. JarJar is a tool that may help you in this endeavor.
If you find that you cannot do this, then that is an indication that
the path you are on will ultimately lead to pain, suffering, grief,
and lamentation.
[2012-07-18 10:45:48 - myapp] Dx 1 error; aborting
[2012-07-18 10:45:48 - myapp] Conversion to Dalvik format
failed with error 1
This is how my project looks int he explorer:
The problem is that the jar you are including has a class in the java.* or javax.* namespace. dx does not allow this, as mentioned in the last big error message.
If you actually need these classes, you'll need to move them to a different package, using something like the jarjar tool. Otherwise, you'll need to remove them from the jar -- it may be possible to have proguard to remove them before everything gets dx'd, I'm not sure.
I faced the same problem, I finally resolved it by exporting my private library explicitly.
Like:
Project >> properties >> Java Build Path >> Libraries >> Add External Jars.
Note: Removed my all private libraries from libs folder. I know it is not correct but it worked for me.
Thanks,
Anil
Do as follows :
project
> properties
> java build path
> libraries
> remove all including android jars
Now, go the project browser, right click on the project you are working on, then
android tools
> fix project properties.
Do a clean and then build.
Just restart eclipse, and the error won't occur anymore
If you work on Win7 change this line:
call %java_exe% -jar "%PROGUARD_HOME%"\lib\proguard.jar %*
in proguard.bat file to this:
call %java_exe% -jar "%PROGUARD_HOME%"\lib\proguard.jar %1 %2 %3 %4 %5 %6 %7 %8 %9
proguard.bat is in:
[Android SDK Installation Directory]\tools\proguard\bin\proguard.bat
Edit:
I hope a combine of these help you:
1-Try to delete libraries projects from your project.
2-Try to export your project(as archive file),delete project and it's source from workspace and then import it again.
3-Try to remove your jars from path,do clean-build and then add them again to your project.
I had the same error when using my own obfuscated lib jar.
my log:
warning:Ignoring InnerClasses attribute for an anonymous inner class that doesn't come with an associated EnclosingMethod attribte.This class was probably prouduced by a compiler that did not target the morden .class file format...
And I solved it like this:before I obfuscate my jar,I added "-keepattributes EnclosingMethod" to the proguard.cfg(or proguard-project.txt in latest android adt version).
Agree with hasanghaforian. The easiest solution is to remove libraries project.
Right click your project->Properties->Java Build Path then remove Library Projects