ToolProvider.getSystemJavaCompiler() always returning null using jdk - java

I read all the posts regarding this problem and no solution works for me, I get always null.
I use JRE and put the tools.jar in the lib directory, added it to the build path but when I want to jump to declaration Eclipse wants to jump into rt.jar (?) what I totally don't understand.
Could that be the reason that I get only null? How can I configure that correctly?
What are the criteria for getSystemJavaCompiler() to return null?
Preferences screenshot

JRE is the Java Runtime Environment. It doesn't have a compiler, and therefore you're getting a null. If you use a full-fledged JDK, you'd get a non-null result.

I found a workaround for my problem. First I used the jre again. I put the tools.jar in the lib directory of the application.
ToolProvider.getSystemJavaCompiler() return null.
This is the workaround to get the JavaCompiler:
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
if (compiler == null){
try {
Class<?> javacTool = Class.forName("com.sun.tools.javac.api.JavacTool");
Method create = javacTool.getMethod("create");
compiler = (JavaCompiler) create.invoke(null);
} catch (Exception e) {
throw new AssertionError(e);
}

Related

Google Guava getTopLevelClasses returns empty set

I've been searching around all over the internet to no avail. I am attempting to use Guava to get all the classes in a package of mine, but it is not behaving as intended. It always returns an empty set, making it impossible to do anything with the given results. Could there be a problem with System Variables, or some other road-block?
Here is some of my code.
String packageName = "me.travja.package";
ImmutableSet<ClassPath.ClassInfo> root = null;
try {
System.out.println(ClassPath.from(getClass().getClassLoader()));
root = ClassPath.from(getClass().getClassLoader()).getTopLevelClasses();//.getTopLevelClassesRecursive(packageName);
} catch (IOException e) {
e.printStackTrace();
}
for (ClassPath.ClassInfo info : root) {
System.out.println(info.getPackageName() + " -- " + info.getSimpleName());
}
It never hits the last sout because it's empty, but the one that prints the classpath prints 'com.google.common.reflect.ClassPath#33571c14' which isn't super useful. But to my knowledge, shouldn't that resemble more of my application's directory?
Thank you for your help with this. It's been bugging me for too long.
EDIT: I did some digging around. It seems that it works as intended if my file path doesn't contain a Space. I read a little that this used to be a problem with Guava in older versions, but I even tried using Maven and shading the latest version of Guava. Is there any way to fix this, or do I just have to be cautious that my file path never has a space in it?
After doing some more digging, one of the other dependencies that I was using had shaded an older version of Guava and that is what my code was using. As a result, it was broken. I used a decompiler so I could manually shade the ClassPath class from a newer Guava into my own code, and imported that. Works flawlessly now.

New value added to Java Enum not available during debug

I am having the following problem:
I have an Enum that was originally declared with 5 elements.
public enum GraphFormat {
DOT,
GML,
PUML,
JSON,
NEO4J,
TEXT {
#Override
public String getFileExtension() {
return ".txt";
}
};
Now I need to add an additional element to it (NEO4J). When I run my code or try to debug it I am getting an exception because the value can't be found in the enum.
I am using IntelliJ as my IDE, and have cleaned the cache, force a rebuild, etc.. and nothing happens. When I look at the .class file created on my target folder, it also has the new element.
Any ideas on what could be causing this issue ?
I found my problem and want to share here what was causing it. My code was actually for a Maven plug-in which I was pointing to another project of mine to run it as a goal. However the pom.xml of my target test project was pointing to the original version of the plug-in instead of the one I am working on, and that version of course is outdated and does not include the new value. Thank you.

Cannot find CatalogManager.properties

My servlet app uses XML catalogs.
First I used org.apache.xml.resolver.tools.CatalogResolver.
It finds its configuration file CatalogManager.properties under WEB-INF/classes/.
Then I tried the same thing with com.sun.org.apache.xml.internal.resolver.CatalogManager, the version which comes with the JDK.
It doesn’t work:
Cannot find CatalogManager.properties
The spec says that this file must be somewhere on the CLASSPATH, and I suppose it is.
What should I do?
Actually, it should work, the code is the same, just repackaged:
propertyFileURI = CatalogManager.class.getResource("/"+propertyFile);
InputStream in =
CatalogManager.class.getResourceAsStream("/"+propertyFile);
if (in==null) {
if (!ignoreMissingProperties) {
System.err.println("Cannot find "+propertyFile);
// there's no reason to give this warning more than once
ignoreMissingProperties = true;
}
return;
}
What to do? Try debugging, set the breakpoint und see why it does not work.
Why do you need CatalogManager.properties anyway? If you don't, you could disable the error message with the system property xml.catalog.ignoreMissing.

How to detect that code is running inside eclipse IDE

How to detect that code is running inside eclipse IDE
I am not aware of a generic way to get this kind of information.
One suggestion:
When you start a Java program (or a web server) inside Tomcat, simply add an argument that will indicate that this program is launched by Eclipse.
You can do that by opening the "Open Run Dialog" ("Run" menu), then select your type of application and add in the "Arguments" tab a -DrunInEclipse=true.
In your Java code, you can check the value of the property:
String inEclipseStr = System.getProperty("runInEclipse");
boolean inEclipse = "true".equalsIgnoreCase(inEclipseStr);
This way, if the program is not running inside Eclipse (or unfortunately if you forgot to set the property) the property will be null and then the boolean inEclipse will be equal to false.
Although I agree that having the code detecting a single IDE as the dev env is not an optimal solution, the following code works.
Like others proposed, using a flag at runtime is better.
public static boolean isEclipse() {
boolean isEclipse = System.getProperty("java.class.path").toLowerCase().contains("eclipse");
return isEclipse;
}
1) Create a helper method like:
public boolean isDevelopmentEnvironment() {
boolean isEclipse = true;
if (System.getenv("eclipse42") == null) {
isEclipse = false;
}
return isEclipse;
}
2) Add an environment variable to your launch configuration:
3) Usage example:
if (isDevelopmentEnvironment()) {
// Do bla_yada_bla because the IDE launched this app
}
Actually the code is not being run inside Eclipse, but in a separate Java process started by Eclipse, and there is per default nothing being done by Eclipse to make it any different than any other invocation of your program.
Is the thing you want to know, if your program is being run under a debugger? If so, you cannot say for certain. You CAN, however, inspect the arguments used to invoke your program and see if there is anything in there you do not like.
If your workspace matches some pattern like "/home/user/workspace/Project" you can use the code below:
Boolean desenv = null;
boolean isDevelopment() {
if (desenv != null) return desenv;
try {
desenv = new File(".").getCanonicalPath().contains("workspace");
}
catch (IOException e) {
e.printStackTrace();
}
return desenv;
}
A more generic and precise way, that can be used on any IDE would be loop at:
ManagementFactory.getRuntimeMXBean().getInputArguments()
looking for "-Xdebug" || (starting with) "-agentlib:jdwp=".
I came with this from #saugata comment here.
This is excellent if you want to throw a conditional exception preventing the application from simply exiting. Use a boolean like "ideWait" and add it to Eclipse watch expressions as ideWait=false, so whenever you stop at that throw, and "drop to frame" you can continue debugging happily (I mean it!)
I don't think there is any way to do this. But what I would suggest is just a command line argument such as 'debug'. Then in your main method just do
if (args.length > 0 && args[0].equalsIgnoreCase("debug")) {
// do whatever extra work you require here or set a flag for the rest of the code
}
This way you can also get your extra code to run whenever you want just by specifiying the debug parameter but under normal conditions it will never execute.
This might work if your alternative execution work flow provides a different set of dependencies:
boolean isRunningInEclipe = false;
try {
Workbench.getInstance();
isRunningInEclipe = true;
} catch (NoClassDefFoundError error) {
//not running in Eclipse that would provide the Workbench class
}
You could detect if you're inside a JAR or not, as per Can you tell on runtime if you're running java from within a jar?
Eclipse will run your app from the classes/ dir, whereas most of your end users will be running the app from a JAR.
System.out.println("Is my parent eclipse[.exe]? " +
ProcessHandle.current()
.parent()
.flatMap(parent -> parent.info().command())
.orElse("")
.matches("^.*eclipse(\\.exe)?$"));
You may try something like this:
if (ClassLoader.getSystemResource("org/eclipse/jdt/core/BindingKey.class")!=null){
System.out.println("Running within Eclipse!!!");
} else {
System.out.println("Running outside Eclipse!!!");
}

What is the best way to detect whether an application is launched by Webstart

As it was made clear in my recent question, Swing applications need to explicitly call System.exit() when they are ran using the Sun Webstart launcher (at least as of Java SE 6).
I want to restrict this hack as much as possible and I am looking for a reliable way to detect whether the application is running under Webstart. Right now I am checking that the value of the system property "webstart.version" is not null, but I couldn't find any guarantees in the documentation that this property should be set by future versions/alternative implementations.
Are there any better ways (preferably ones that do not ceate a dependency on the the webstart API?)
When your code is launched via javaws, javaws.jar is loaded and the JNLP API classes that you don't want to depend on are available. Instead of testing for a system property that is not guaranteed to exist, you could instead see if a JNLP API class exists:
private boolean isRunningJavaWebStart() {
boolean hasJNLP = false;
try {
Class.forName("javax.jnlp.ServiceManager");
hasJNLP = true;
} catch (ClassNotFoundException ex) {
hasJNLP = false;
}
return hasJNLP;
}
This also avoids needing to include javaws.jar on your class path when compiling.
Alternatively you could switch to compiling with javaws.jar and catching NoClassDefFoundError instead:
private boolean isRunningJavaWebStart() {
try {
ServiceManager.getServiceNames();
return ds != null;
} catch (NoClassDefFoundError e) {
return false;
}
}
Using ServiceManager.lookup(String) and UnavailableServiceException is trouble because both are part of the JNLP API. The ServiceManager.getServiceNames() is not documented to throw. We are specifically calling this code to check for a NoClassDefFoundError.
Use the javax.jnlp.ServiceManager to retrieve a webstart service.
If it is availabe, you are running under Webstart.
See http://download.java.net/jdk7/docs/jre/api/javaws/jnlp/index.html
As you mentioned, checking the System property as follows is probably the cleanest way:
private boolean isRunningJavaWebStart() {
return System.getProperty("javawebstart.version", null) != null;
}
In a production system I have used the above technique for years.
You can also try to check to see if there are any properties that start with "jnlpx." but none of those are really "guaranteed" to be there either as far as I know.
An alternative could be to attempt to instantiate the DownloadService us suggested by Tom:
private boolean isRunningJavaWebStart() {
try {
DownloadService ds = (DownloadService) ServiceManager.lookup("javax.jnlp.DownloadService");
return ds != null;
} catch (UnavailableServiceException e) {
return false;
}
}
Of course that does have the downside of coupling your code to that API.
I have no real experience with Java web start other than looking at it a few years back.
How about start your application with a parameter that you define than you set when the app is started via Java web start.
If you want to pass in arguments to your app, you have to add them to the start-up file (aka JNLP descriptor) using or elements.
Then check to see if these properties are set.
Again this is a suggestion I have not coded for JWS and it may not be this easy.
You can check whether the current classloader is an instance of com.sun.jnlp.JNLPClassLoader (Java plugin 1) or sun.plugin2.applet.JNLP2ClassLoader (Java plugin 2). Despite the "applet" package, an applet using JNLP with the Java plugin 2 uses another classloader, sun.plugin2.applet.Applet2ClassLoader. It works with OpenJDK too.

Categories