I found some classes designed for debugging in package com.sun.jdi like VirtualMachine, but I can't use this because package seems not exist in Sun JDK7.
How to use this package?
BTW. lib/sa-jdi.jar isn't the same I want
According to this page, the VirtualMachine class that you linked to is part of the tools.jar file which is only distributed in a JDK (not a JRE). It says ...
"Update Note 2: The Attach API is in tools.jar, so you will need to add /lib/tools.jar in your CLASSPATH to compile and run the example on JDK 6."
... and the same advice would apply on (at least) JDK 7 as well.
Related
Im trying to use the HttpServer Class from com.sun package but i can't import it. It keeps saying: "The package com.sun is not accessible."
I've tried every solution i could find in other questions about this topic. I've added a rule to have access to it to my libraries. I changed my JDK to another installed JDK17. I don't know what to do anymore. It's for my college homework, so it would be cool to get it running.
Does someone have a clue?
my code problem:
the access rule:
my current used jdk:
You have a module-info.java so you are using Java modules. Consequently you need to say that you are using the jdk.httpserver module which contains com.sun.net.httpserver.HttpServer.
You do that by adding the line:
requires jdk.httpserver;
to your module-info.java. So something like:
module modulename
{
requires jdk.httpserver;
}
where modulename is the name of your module.
Alternatively delete the module-info.java file to stop using the module system.
All the documentation I've been able to find mentions the 'jre/lib/ext' folder but such does not exist on my JRE 13 installation.
I guess somewhere between Java 8 (where I can see the jars in jre/lib/ext) and Java 13, they moved but I've been unable to pinpoint when and how it was done.
Could someone please elaborate what's going on with new JRE's, in terms of where the extension classes reside currently?
The extension mechanism is gone with Java 9, not only moved [:-| , see the Important Changes and Information for Java 9:
The deprecated Extensions Mechanism has been removed. The runtime will refuse to start if ${java.home}/lib/ext exists or the system property java.ext.dirs is specified on the command line.
And also the Changes to the Installed JDK/JRE Image in JDK 9 Migration Guide:
In previous releases, the extension mechanism made it possible for the runtime environment to find and load extension classes without specifically naming them on the class path. In JDK 9, if you need to use the extension classes, ensure that the JAR files are on the class path.
I'm trying to do a few imports from com.apple.eawt (using Eclipse) like this:
import com.apple.eawt.AboutHandler;
import com.apple.eawt.AppEvent;
But I get "the import com.apple cannot be resolved" for each statement.
I've looked at other similar questions, and it seems people are saying it is a build path error. I tried the suggestion in one of the questions to add an accessibility rule like this:
But I still get the error even after restarting Eclipse. The other thing is that all of the questions I've seen are using MacOS, so I don't know if that makes a difference.
The com.apple.eawt package is a MacOS-specific package intended to permit java applications to work like native MacOS applications. You would only find this package in a JRE/JDK for the MacOS platform. You say you're building on Windows, which wouldn't have this package.
On top of that, beginning with Java 9 the com.apple.eawt and other Apple-specific packages are encapsulated and no longer accessible without taking special steps. Even if you were building on MacOS, you'd have to override the encapsulation to access the package.
JEP 272 describes a public API which is intended to be a cross-platform replacement for com.apple.eawt. If you're motivated, you may be able to port your program to the new API.
Further reading:
Migrating to JDK 9: Removed macOS-Specific Features
JDK-8048731 : JEP 272: Platform-Specific Desktop Features
JDK-8160437: com.apple.eawt.Application is not exported
I am having a doubt.
My understanding is that jdk has [ jre + development tools (Java, javac, debugger etc.) + source code (src.zip) ].
Now working of java compiler is nothing to do with the running of class file.
If I am compiling a .java file then from where the java compiler is importing the package?
I could find the packages under jre.
If I do not opt to install jre while installing jdk, does that mean I will not be able to compile the java file having import statement?
Please help.
First, as a minor remark, a statement like
import java.util.List;
just introduces an abbreviation, allowing you to use the simple word List later in your code instead of the full class name java.util.List. So it's not so much the import statement itself, but the usage of a class like java.util.List that needs some explanation.
You understand correctly that, to compile your java file, the compiler needs some information about every class you use, and it typically finds this information in some jar file containing that class.
Now, where is this jar file containing the java.util.List class that the compiler reads? You're correct, it comes from the JRE, from the rt.jar that's part of the system classpath (the Java compiler itself is a java program that needs the basic classes itself, so wherever you successfully run javac, you always have an rt.jar available).
If your source code used a class from some other library, you'd have to specify that library on the javac command line, using an option like -cp.
Jdk = JRE + other tools like you mentioned.
When you are compiling your java file and you are using java inbuild library then it uses rt.jar to resolve dependency i.e import statements.
You can refer below link for the difference
What is the difference between JVM, JDK, JRE & OpenJDK?
jre comes with many libraries in rt.jar one of which is com.sun.istack.internal*. I needed the documentation of com.sun.istack.internal.Nullable(which I found being used by google in its CacheBuilder) and first I thought was to go to docs.oracle.com to find its documentation and there I found nothing about it. Next went to source folder sourced with jdk and I didn't find com name entity in the said folder. Next I take a look at the jre7 release and take a look at all the packages and class and found no mention of Nullable there. Though SO had one mention of it, but nothing concrete. I am still puzzled where to get its documentaion and src if needed. I even looked legacy sun api documentation at oracle but nothing mentioned about it. where does oracle document there policy about ported packages and their being standard or not-standard.They must have documented it somewhere it is just that I'm taking too much of time to get there.
Please point me there.
EDIT: Actually the javax.annotation.Nullable is being used in google CacheBuilder and not com.sun.istack.internal.Nullable.
Also for someone who may face this issue: javax.annotation.Nullable is not part of Java SE as of now, and it is being ported in jsr305 jar. So if you are planning to use CacheBuilder or just going through its code, do add jsr305 jar in your class path, else eclipse get confuse and will point you to com.sun.istack.intenal.Nullable when ever you hover your cursor over Nullable.
Guava doesn't use com.sun.istack.internal.Nullable. Everything that is not documented in the official Java SE javadoc is internal code, and should not be used in applications.
You're probably looking for javax.annotation.Nullable, which is part of JSR305.
Here is a link to the source code:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/istack/internal/Nullable.java/
(This link may break in the future, but you should be able to find an equivalent using a Google search.)
The reason that you can't find the source code or javadocs in the standard JDK / JRE distributions is that this is a INTERNAL class. There is a long-standing Oracle / Sun policy of discouraging developers from writing code that is dependent on Java internal classes.
FWIW - this is just an annotation, and the meaning is pretty much what the class name implies.
UPDATE - Apparently, the real cause of this confusion is that you didn't include the JSR305 jar in your buildpath. It is a dependency for CacheBuilder. Eclipse classname completion is then doing its best ... but failing.
It is said that It's Oracle's intent that these classes be inaccessible at compile-time.
Below is my workaround in case adding a modern jar for those annotation is not allowed.
If using Gradle, add:
compileJava.options.compilerArgs << "-XDignore.symbol.file"
If using Ant, change the javac tag like:
<javac srcdir="src" destdir="${classes.dir}" classpathref="classpath" memoryinitialsize="512m" memorymaximumsize="1024m" fork="true">
<compilerarg line="-encoding utf-8 -XDignore.symbol.file"/>
<exclude name="test/**"/>
</javac>