What I've tried:
class TempDir {
public static void main (String[] args) {
System.out.println(System.getProperty("java.io.tempdir"));
}
}
I need to keep a script consistent with Windows and Linux, windows returns temp directory however, ubuntu returns null, I'm not sure why?
System.out.println(System.getProperty("java.io.tmpdir"));
Prints /tmp on my Ubuntu system, so it looks like you mispelled the property name.
Related
Is it still possible to use Java in Classic ASP (IIS 7.* / Windows) via Java Moniker as is demonstrated at http://cephas.net/blog/2004/03/15/scripting-in-asp-with-java/? (and http://thrysoee.dk/InsideCOM+/ch11f.htm and https://hq.lojcomm.com.br/java/Interop.class.asp).
I cannot make it work from IIS 8.5 (or from dektop VbScript) in my Windows 10 with Java 1.8.0_131 installed in C:\Program Files\Java.
I get all the time: error'800401e4' with no other clarifications in the first line:
set Java_Date = getObject("java:java.util.Date")
response.write( Java_Date.toString() )
and the same error comes if I try to use NetBeans-compiled custom class:
set Java_Greeter = getObject("java:omatestit.Hello")
public class Hello
{
public static void main(String[] args)
{
//do nothing - this will keep us from getting a compile error
}
public String SayHello()
{
return "Hello Geek";
}
}
which locates in:
"C:\Program Files\Java\jdk1.8.0_131\include\win32\TrustLib\omatestit\Hello.class"
Can anyone figure out what is wrong with previous settings?
I'm trying to get the username on Windows
public class Foo {
public static void main(String[] args) {
System.out.println(System.getProperty("user.name"));
}
}
It works with normal users, but when I do it with system account,
The value was different from the output of whoami command
Any ideas? I need to get the correct name with Java, and it's best without dependency jars
P.S I'm running CMD on a Windows 2008 R2 box
my first java program is
import java.io.*;
class pgm10a
{
public static void main(String args[])
{
pgm10b b=new pgm10b();
b.display();
}
void display()
{
System.out.println("A class");
}
}
it is saved in C:\NNK\pack1
the second program is
import java.io.*;
class pgm10b
{
void pgm10b()
{
pgm10a a=new pgm10a();
a.display();
}
void display()
{
System.out.println("Class B");
}
}
it is in C:\NNK\pack2
I want to run pgm10a but it keeps showing pgm10b not found exception. i have set the class path and compiled for both and both are compiled successfully. but when i try to run them it shows pgm10b not found.
Have a look at the syntax for the java command:
java [options] classname [args]
Anything after the class name is not an option to the java command—it is simply passed as is, in a String array, to the program’s main method.
You can solve your problem by changing your final command from this:
java pgm10a -cp C:\NNK\pack2
to this:
java -cp .;C:\NNK\pack2 pgm10a
The classpath is a sequence of directories, separated by ; when running in Windows (: on other operating systems), which tell the java command where to find compiled classes. If you only specify C:\NNK\pack2, Java will only be able to see classes in that directory. The period (.) refers to the current directory, so the above classpath is pointing to both the current directory (which contains pgm10a) and the pack2 directory (which contains pgm10b).
I ran into library loading problems after creating a jar from my code via maven. I use intelliJ idea on Ubuntu. I broke the problem down to this situation:
Calling the following code from within idea it prints the path correctly.
package com.myproject;
public class Starter {
public static void main(String[] args) {
File classpathRoot = new File(Starter.class.getResource("/").getPath());
System.out.println(classpathRoot.getPath());
}
}
Output is:
/home/ted/java/myproject/target/classes
When I called mvn install and try to run it from command line using the following command I'm getting a NullPointerException since class.getResource() returns null:
cd /home/ted/java/myproject/target/
java -cp myproject-0.1-SNAPSHOT.jar com.myproject.Starter
same for calling:
cd /home/ted/java/myproject/target/
java -Djava.library.path=. -cp myproject-0.1-SNAPSHOT.jar com.myproject.Starter
It doesn't matter if I use class.getClassLoader().getRessource("") instead. Same problem when accessing single files inside of the target directory instead via class.getClassLoader().getRessource("file.txt").
I want to use this way to load native files in the same directory (not from inside the jar). What's wrong with my approach?
The classpath loading mechanism in the JVM is highly extensible, so it's often hard to guarantee a single method that would work in all cases. e.g. What works in your IDE may not work when running in a container because your IDE and your container probably have highly specialized class loaders with different requirements.
You could take a two tiered approach. If the method above fails, you could get the classpath from the system properties, and scan it for the jar file you're interested in and then extract the directory from that entry.
e.g.
public static void main(String[] args) {
File f = findJarLocation("jaxb-impl.jar");
System.out.println(f);
}
public static File findJarLocation(String entryName) {
String pathSep = System.getProperty("path.separator");
String[] pathEntries = System.getProperty("java.class.path").split(pathSep);
for(String entry : pathEntries) {
File f = new File(entry);
if(f.getName().equals(entryName)) {
return f.getParentFile();
}
}
return null;
}
I have the following class in Java which prints "Hello World" in portuguese:
public class PrintUnicode {
public static void main(String[] args) {
System.out.println("Olá Mundo!");
}
}
I am using Eclipse, so I exported the project to a Runnable Jar File. After that, I went to cmd (Windows 7) and ran the generated jar file.
The result was:
Olß Mundo!
Is there an easy way to avoid this error?
Found the solution. Just change to:
public class PrintUnicode {
public static void main(String[] args) {
System.console().printf("Olá Mundo!");
}
}
The error with System.out happens because:
By default, Java encodes Strings sent
to System.out in the default code
page. On Windows XP, this means a
lossy conversion to an "ANSI" code
page. This is unfortunate, because the
Windows Command Prompt (cmd.exe) can
read and write Unicode characters. (source here)