Java - Solving WindowPeer warning - java

When I compile my below java code,
Window w = c instanceof Window ? (Window) c : SwingUtilities.getWindowAncestor(c);
WindowPeer peer = (WindowPeer) w.getPeer();
I'm getting below warning message:
warning: WindowPeer is internal proprietary API and may be removed in a future release
Any idea how to solve this issue?
I'm using JDK 1.6 and I tried 1.7 also.

Here are two ways to suppress the warning.
Suppressing the warning is not recommended, though, and the warning message text tells you why.
Approach #1 (the simplest) is to run
javac -XDignore.symbol.file ...
which will compile your program against Sun's internal rt.jar rather than the public-facing symbol file ct.sym.
Approach #2a is to run
javac -XDenableSunApiLintControl -Xlint:-sunapi ...
This still issues a "note" but not a warning.
Approach #2b is to suppress the warning and the note by writing
#SuppressWarnings("sunapi")
in the source code, but this still requires you to run javac as follows:
javac -XDenableSunApiLintControl ...

Related

Is there a dependency that is missing for this soot dependent app?

I try to run soot dependent app, using lots of jar files as dependencies in the compilation and every time a new error occurs.
The error I got at last is this:
[main] INFO soot.jimple.infoflow.android.SetupApplication - ARSC file parsing took 0.01102201 seconds
Exception in thread "main" java.lang.NoSuchMethodError: soot.Body.getUnits()Lsoot/PatchingChain;
at soot.jimple.infoflow.entryPointCreators.BaseEntryPointCreator.createEmptyMainMethod(BaseEntryPointCreator.java:165)
at soot.jimple.infoflow.entryPointCreators.BaseEntryPointCreator.createDummyMainInternal(BaseEntryPointCreator.java:123)
at soot.jimple.infoflow.entryPointCreators.BaseEntryPointCreator.createDummyMain(BaseEntryPointCreator.java:109)
at soot.jimple.infoflow.android.SetupApplication.createMainMethod(SetupApplication.java:622)
at soot.jimple.infoflow.android.SetupApplication.calculateCallbackMethods(SetupApplication.java:471)
at soot.jimple.infoflow.android.SetupApplication.calculateSourcesSinksEntrypoints(SetupApplication.java:401)
at soot.jimple.infoflow.android.SetupApplication.calculateSourcesSinksEntrypoints(SetupApplication.java:359)
at Appgraph.main(Appgraph.java:37)
I try to run it both in Java 11 and Java 8 but the same error occurs. The compilation and running commands I use are:
javac -cp ".:soot-4.1.0-jar-with-dependencies.jar:soot-infoflow-android.jar:soot-infoflow.jar:axml-2.0.jar:commons-io-2.6.jar:android.jar:guava-27.1-android.jar:jsr305-1.3.9.jar:dexlib2-2.3.4.jar:multidexlib2-2.3.4.r2.jar:failureaccess-1.0.1.jar:sootall-2.5.0.jar:soot-2.5.0.jar:soot.jar:soot-4.1.0-jar-with-dependencies.jar" Appgraph.java for the compilation command
java -Xmx2g -cp ".:soot-4.1.0-jar-with-dependencies.jar:soot-infoflow-android.jar:soot-infoflow.jar:axml-2.0.jar:commons-io-2.6.jar:android.jar:guava-27.1-android.jar:jsr305-1.3.9.jar:dexlib2-2.3.4.jar:multidexlib2-2.3.4.r2.jar:failureaccess-1.0.1.jar:sootall-2.5.0.jar:soot-2.5.0.jar:SourcesAndSinks.txt" Appgraph apks/3baea0cd661a580a84e4110b1a309942.apk . as the running command
I tried multiple versions of soot but no version got me past the above error.
Seems like you are trying to use a very old version of FlowDroid (soot-infoflow) together with a new version of Soot.
The mentioned method soot.Body.getUnits()Lsoot/PatchingChain; is part of Soot and has been changed in August 2018: https://github.com/Sable/soot/commit/25e145a694676a6ae786ebb44fcef51aa03b4cf5#diff-e17f2a0d88bf86133287578f02eb7483
Hence you need a version of FlowDroid that has been released after that date.

javac not displaying compiler errors?

I'm teaching my friend some Java, and we're running into issues trying to run the compiler on her Hello World program. The code had a pretty glaring error (Sysrem.out.println), but otherwise was totally valid Java, but for some reason the compiler didn't report the error. Here's what happened:
When we ran javac Hello.java in Windows Command Prompt, it printed out a blank line and then a new command prompt line, as if the operation had succeeded, but it clearly hadn't - a class file wasn't created, and of course the code had an error so we knew it wouldn't be successful.
When we ran javac -verbose Hello.java, it printed out the gory details of the class files it was loading, but then that was it. While it didn't end by saying it had written a class file, it also didn't print out the error.
After we fixed the error, the program compiled and ran without a problem, so it seems to be that javac just doesn't like printing out compiler errors.
What could be going on here, why isn't the compiler reporting this error like it should?
The complete code:
public class Hello {
public static void main(String[] args) {
Sysrem.out.println("Hello, world!");
}
}
The command prompt:
C:\Users\MyFriendsName\Documents>javac Hello.java
C:\Users\MyFriendsName\Documents>
What this actually boils down to is whether an empty file is a valid Java program. Surprisingly, it is!
Here is the grammar for a CompilationUnit ... which is the technical term that that JLS uses for a Java source file:
CompilationUnit:
OrdinaryCompilationUnit
ModularCompilationUnit
OrdinaryCompilationUnit:
[PackageDeclaration] {ImportDeclaration} {TypeDeclaration}
ModularCompilationUnit:
{ImportDeclaration} ModuleDeclaration
(Reference: JLS 7.3)
Note that the OrdinaryCompilationUnit element allows you to have a source file that consists of:
no package statement
no import statements
no type declarations
In other words, an empty file, or a file that just contains comments.
In short, if you tell javac to compile an empty file, it won't produce any compilation errors ... because it is "valid" Java source code file.
Well, I discovered the issue: Turns out my friend had never hit Save on her file after creating it, and in what I'm assuming is just some unintuitively-designed expected behavior, javac doesn't complain about being fed a blank file!
Here's exactly what happened:
Create the file
Write the buggy code but don't save the file
Attempt to compile the code and hit the issue described in my question
Correct the bug in the code and save the file
Compile and run the code without a problem

Quasar/Pulsar lein midje build errors on linux

I am trying to install Pulsar. I have lein version
idf#idf-Satellite-C55t-A ~/Documents/clojure/pulsar $ lein version
Leiningen 2.5.0 on Java 1.7.0_72 Java HotSpot(TM) 64-Bit Server VM
idf#idf-Satellite-C55t-A ~/Documents/clojure/pulsar $
I have JAVA_HOME set
idf#idf-Satellite-C55t-A ~/Documents/java/quasar $ echo $JAVA_HOME
/usr/lib/jvm/java-7-oracle
idf#idf-Satellite-C55t-A ~/Documents/java/quasar $
when I do a lein midje on the git cloned directory, I get a bunch of errors. Not sure what I am doing wrong? I suspect that is has to do with installing the java Quasar first correctly, but I am not certain.
idf#idf-Satellite-C55t-A ~/Documents/clojure/pulsar $ lein midje
...
above here no errors
QUASAR WARNING: Assertions enabled. This may harm performance.
Reflection warning, midje/util/ecosystem.clj:40:12 - call to java.io.File ctor can't be resolved.
Reflection warning, midje/clojure/core.clj:86:17 - reference to field hasRoot can't be resolved.
Reflection warning, midje/util/pile.clj:109:9 - call to contains can't be resolved.
Reflection warning, midje/config.clj:19:32 - call to contains can't be resolved.
Reflection warning, midje/emission/clojure_test_facade.clj:26:19 - reference to field toString can't be resolved.
Reflection warning, midje/parsing/util/file_position.clj:59:5 - reference to field getFileName can't be resolved.
Reflection warning, midje/data/metaconstant.clj:43:5 - reference to field getNamespace can't be resolved.
Reflection warning, midje/checking/checkers/chatty.clj:60:20 - call to java.lang.Error ctor can't be resolved.
Reflection warning, midje/checking/checkers/simple.clj:85:24 - reference to field throwable can't be resolved.
Reflection warning, midje/data/compendium.clj:60:38 - call to indexOf can't be resolved.
Reflection warning, midje/util/scheduling.clj:10:5 - call to cancel can't be resolved.
Reflection warning, dynapath/defaults.clj:13:52 - reference to field getURLs can't be resolved.
Reflection warning, dynapath/defaults.clj:27:28 - call to addURL can't be resolved.
Reflection warning, dynapath/util.clj:30:22 - reference to field getParent can't be resolved.
Reflection warning, midje/util/bultitude.clj:62:17 - reference to field canRead can't be resolved.
Reflection warning, midje/util/bultitude.clj:193:22 - call to replaceAll can't be resolved.
Reflection warning, midje/util/bultitude.clj:194:22 - call to replaceAll can't be resolved.
Reflection warning, clj_time/core.clj:577:10 - reference to field getDayOfMonth can't be resolved.
Reflection warning, midje/data/project_state.clj:25:18 - reference to field getName can't be resolved.
Reflection warning, midje/data/project_state.clj:26:28 - reference to field getName can't be resolved.
Reflection warning, midje/data/project_state.clj:49:24 - reference to field getPath can't be resolved.
Reflection warning, midje/data/project_state.clj:73:3 - reference to field lastModified can't be resolved.
Reflection warning, midje/repl.clj:103:12 - call to java.lang.Error ctor can't be resolved.
Reflection warning, midje/repl.clj:388:12 - reference to field getMessage can't be resolved.
Reflection warning, midje/repl.clj:391:50 - reference to field getMessage can't be resolved.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Reflection warning, co/paralleluniverse/pulsar/actors.clj:737:7 - call to co.paralleluniverse.actors.behaviors.Supervisor$ChildSpec ctor can't be resolved.
Exception in Fiber "fiber-10000001" java.lang.Exception: my exception
at co.paralleluniverse.pulsar.actors_test$eval9288$fn__9289$fn__9290$fn__9291$fn__9294.invoke(actors_test.clj:27)
at co.paralleluniverse.pulsar.InstrumentedIFn.invoke(InstrumentedIFn.java:32)
at co.paralleluniverse.pulsar.ClojureHelper.suspendableInvoke(ClojureHelper.java:183)
at co.paralleluniverse.pulsar.ClojureHelper$3.run(ClojureHelper.java:170)
at co.paralleluniverse.actors.PulsarActor.doRun(PulsarActor.java:90)
at co.paralleluniverse.actors.Actor.run0(Actor.java:667)
at co.paralleluniverse.actors.ActorRunner.run(ActorRunner.java:51)
at co.paralleluniverse.actors.Actor.run(Actor.java:236)
and more errors...
So I downloaded the git repo of Quasar. First installing the system gradle using apt-get, and ran gradle inside the quasar directory. This gives me a different error:
idf#idf-Satellite-C55t-A ~/Documents/java/quasar $ gradle
sonatype username or password not set
Download http://repo1.maven.org/maven2/ch/raffael/pegdown-doclet/pegdown-doclet/1.1.1/pegdown-doclet-1.1.1.pom
Download http://repo1.maven.org/maven2/org/pegdown/pegdown/1.2.1/pegdown-1.2.1.pom
Download http://repo1.maven.org/maven2/net/sourceforge/plantuml/plantuml/7968/plantuml-7968.pom
Download http://repo1.maven.org/maven2/org/parboiled/parboiled-java/1.1.4/parboiled-java-1.1.4.pom
Download http://repo1.maven.org/maven2/org/parboiled/parboiled-core/1.1.4/parboiled-core-1.1.4.pom
Download http://repo1.maven.org/maven2/org/ow2/asm/asm/4.1/asm-4.1.pom
Download http://repo1.maven.org/maven2/org/ow2/asm/asm-parent/4.1/asm-parent-4.1.pom
Download http://repo1.maven.org/maven2/org/ow2/asm/asm-tree/4.1/asm-tree-4.1.pom
Download http://repo1.maven.org/maven2/org/ow2/asm/asm-analysis/4.1/asm-analysis-4.1.pom
Download http://repo1.maven.org/maven2/org/ow2/asm/asm-util/4.1/asm-util-4.1.pom
Download http://repo1.maven.org/maven2/ch/raffael/pegdown-doclet/pegdown-doclet/1.1.1/pegdown-doclet-1.1.1.jar
Download http://repo1.maven.org/maven2/org/parboiled/parboiled-core/1.1.4/parboiled-core-1.1.4.jar
Download http://repo1.maven.org/maven2/org/ow2/asm/asm/4.1/asm-4.1.jar
Download http://repo1.maven.org/maven2/org/ow2/asm/asm-tree/4.1/asm-tree-4.1.jar
Download http://repo1.maven.org/maven2/org/ow2/asm/asm-analysis/4.1/asm-analysis-4.1.jar
Download http://repo1.maven.org/maven2/org/ow2/asm/asm-util/4.1/asm-util-4.1.jar
Download http://repo1.maven.org/maven2/org/parboiled/parboiled-java/1.1.4/parboiled-java-1.1.4.jar
Download http://repo1.maven.org/maven2/org/pegdown/pegdown/1.2.1/pegdown-1.2.1.jar
FAILURE: Build failed with an exception.
* Where:
Build file '/home/idf/Documents/java/quasar/build.gradle' line: 185
* What went wrong:
A problem occurred evaluating root project 'quasar'.
> Could not resolve all dependencies for configuration ':quasar-actors:markdownDoclet'.
> Artifact 'com.google.guava:guava:13.0.1#jar' not found.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: 13.114 secs
idf#idf-Satellite-C55t-A ~/Documents/java/quasar $
This looks like a legitimate test failure in the Pulsar project. Perhaps opening an issue on the github page will get things rolling. You do not need to build Quasar to use pulsar. ignore the slf4j logging errors if they don't bother you too much, or you can get rid of them easily with timbre

warning when i am generating .jar

I have this warning:
warning: Supported source version 'RELEASE_6' from annotation processor
org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor' less than -source
'1.7'
Note: Creating non-static metadata factory ...
Note: Found Option : eclipselink.canonicalmodel.use_static_factory, with value: false
Note: Optional file was not found: META-INF/orm.xml continuing with generation.
Note: Optional file was not found: META-INF/eclipselink-orm.xml continuing with
generation.
Note: Found Option : eclipselink.canonicalmodel.use_static_factory, with value: false
Note: Optional file was not found: META-INF/orm.xml continuing with generation.
Note: Optional file was not found: META-INF/eclipselink-orm.xml continuing with
generation.
warning: The following options were not recognized by any processor:
'[eclipselink.canonicalmodel.use_static_factory]'
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning
Copying 5 files to E:\NetBeansProjects\votaciones\build\classes
compile:
Created dir: E:\NetBeansProjects\votaciones\dist
Copying 1 file to E:\NetBeansProjects\votaciones\build
Copy libraries to E:\NetBeansProjects\votaciones\dist\lib.
Building jar: E:\NetBeansProjects\votaciones\dist\votaciones.jar
To run this application from the command line without Ant, try:
java -jar "E:\NetBeansProjects\votaciones\dist\votaciones.jar"
jar:
BUILD SUCCESSFUL (total time: 8 seconds)
what happen?
It says build was successful. The first warning is saying you use Java 7(1.7) where the source supports Java 6 (1.6). The second waring is a consequence of the first one. If your application works, i dont think there is any problem. If it doesnt work, try using java 1.6 or get the updated versions that support java 1.7.

How to catch 'Unsupported major.minor version' error?

I understand the issue regarding this type of error. I would like my program to be able to detect the java version running and provide a more elegant message to the user rather than the somewhat cryptic 'Exception in thread "main" bla bla bla' message. I can detect the Java version running, but it appears that my program never gets far enough to run my checking code.
In short... how can my program catch this error, present a message and exit gracefully?
This exception is throwing from ClassLoader, so I could suggest you write your own version of ClassLoader which will backtrace such errors.
UPD: More specifically you can try to override method defineClass, catch there such exception and wrap it in convenient way.
UPD-2: As I mentioned in comments, and as us2012 reformulated my idea (thanks to him), you have to compile your classloader with a -target that is guaranteed to be lower than the user's VM version
So it's java.lang.UnsupportedClassVersionError. It is (evidently a descendant of the Error class in Java) which subclasses java.lang.ClassFormatError which in turn subclasses java.lang.LinkageError (which is a direct subclass of java.lang.Error)). This error is thrown in the cases when the JVM (Java Virtual Machine) attempts to read a class file and finds that the major and minor version numbers in the particular class file are not supported. This happens in the cases when a higher version of Java Compiler is used to generate the class file than the JVM version which is used to execute that class file.
This is quite easier to understand – how can the compiler have the information at the time of compilation about which version of JVM would be used execute the compiled class file? It can't, right? So is the case with other errors as well. This is the reason why all the Errors are unchecked.
Why you even give user the chance to see this error message! This as you say "cryptic" message will only be emitted out when you are using an earlier version of JVM to execute the class file than the corresponding version of compiler you used to compile the source code. Now, why would you do that?

Categories

Resources