'xxx' cannot be resolved (String, Scanner etc.) after importing files - eclipse

I took a backup of my workspace. Meanwhile I created another workspace in my pc after formatting for temprory purposes. So now I've imported everything from my hard disk to my pc from File -> Import. However nothing seems to be 'resolved'. Heres an example of the code:
package com.sarthak.main;
import java.util.Scanner;
public class Myfirstgame {
public static void main(String[] args) {
System.out.println("Welcome to Momo Land, a place full of horror and utter momoness ");
System.out.println("Enter Your Name: ");
Scanner input = new Scanner(System.in);
String name=input.nextLine();
MyGame game=new MyGame(name);
game.run();
}
}
Things like System.out.println , input game.run etc. can't be resolved for some reason.

Check if your Java libraries are referenced in the properties of your project. In most cases, it is the referencing problem when importing projects.

Create a new project and then just copy the code inside the files..This may solve your problem.

Related

Error: Could not find or load main class

When I run my program this says:
Error: Could not find or load main class Hello world
Every setting I did several times but I get the same result.
Win 8.1 64 bit
Path settings ok
eclipse jre setting ok
public class newproject1
{
public static void main(String[] args) {
System.out.println("Hello World! ");
}
}
Error: Could not find or load main class newproject1
I would guess that your Hello world class does not have a main method defined. The format is:
public static void main(String[] args)
{
//in here you put what you want the program to do
System.out.println("Hello World");
}
Today I just got "Error: Could not find or load main class" in Eclipse indigo. I don't know if your problem is the same or not. In my case my project code was a backup of the original and I named the backup folder as "x86 31 mayıs yedek". "mayıs" is turkish word and there are generally problems associated with turkish characters and their language settings in software. "ı" in the this word is special character in turkish language.
Simply, I removed the project from the eclipse, I changed the backup folder's name by removing any extra character which is not in english. Then I imported the project again, rebuild it and It worked. Hope this helps.
I had the same problem and after trying some different ways, finally solve my problem by setting again the workspace!
File-> Switch workspace-> other
and set it again!

How to read the source content-type from each Eclipse file?

I have an Eclipse project that contains several source files, with a bunch of different encodings: some files are UTF8, some others are ISO-8859-1, others more are windows-1252.
Moreover, there are files whose encoding is explicit (it can bee seen in each file Properties window) while that of others is Inherited from container.
I need to convert them to UTF8 - and I've already found I can use iconv for that - see my answer here for details -, but since they're more than one thousand, I can't convert them one by one: is there any programmatic way to get the encoding from the IDE or something similar?
I'm on Windows, I may do some shell scripting and / or write auxiliary software.
The charset setting of project file could be found in ${PROJECT_FOLDER}/.settings/org.eclipse.core.resources.prefs
Since there are so many files in your project. Create a simple Eclipse plugin could reduce the effort. Here are the steps:
Select Eclipse menu item New > Project... > Plug-in Project
Accept default values and goto last page, choose Hello, World template.
Open and edit plugin.xml, adding required plugin org.eclipse.core.resources in Dependencies page.
Edit SampleAction.java, refer the sample code below..
Create a Debug Configuration for execute Eclipse Application.
Start the eclipse and import your project.
Select menu item Sample Menu to invoke public void run(IAction action).
Sample code of Eclipse resource API:
//import org.eclipse.core.resources.*;
//import org.eclipse.core.runtime.*;
public void run(IAction action) {
final boolean keepHistory = true;
IProject project = ResourcesPlugin.getWorkspace().getRoot().getProject("yourProjectName");
project.accept(new IResourceVisitor() {
public boolean visit(IResource resource) {
IFile file = (IFile)resource;
try {
String charset = file.getCharset(true);
if (!"UTF-8".equals(charset)) {
InputStream is = file.getContents();
//convert to UTF-8 and save it
String str = new String(IOUtils.toByteArray(is), charset);
file.setContents(new ByteArrayInputStream(str.getBytes("UTF-8")), true, keepHistory, null);
//remove charset setting
file.setCharset("UTF-8", null);
}
} catch (Throwable e) {
//log error... maybe process later via project.getFile(new Path(projectRelativePath))
Activator.getDefault().getLog().log(new Status(IStatus.INFO, Activator.PLUGIN_ID,
file.getProjectRelativePath().toString(), e));
}
return false;
}
}, IResource.DEPTH_INFINITE, IResource.FILE);
}

Changing working directory in Scala [duplicate]

How can I change the current working directory from within a Java program? Everything I've been able to find about the issue claims that you simply can't do it, but I can't believe that that's really the case.
I have a piece of code that opens a file using a hard-coded relative file path from the directory it's normally started in, and I just want to be able to use that code from within a different Java program without having to start it from within a particular directory. It seems like you should just be able to call System.setProperty( "user.dir", "/path/to/dir" ), but as far as I can figure out, calling that line just silently fails and does nothing.
I would understand if Java didn't allow you to do this, if it weren't for the fact that it allows you to get the current working directory, and even allows you to open files using relative file paths....
There is no reliable way to do this in pure Java. Setting the user.dir property via System.setProperty() or java -Duser.dir=... does seem to affect subsequent creations of Files, but not e.g. FileOutputStreams.
The File(String parent, String child) constructor can help if you build up your directory path separately from your file path, allowing easier swapping.
An alternative is to set up a script to run Java from a different directory, or use JNI native code as suggested below.
The relevant OpenJDK bug was closed in 2008 as "will not fix".
If you run your legacy program with ProcessBuilder, you will be able to specify its working directory.
There is a way to do this using the system property "user.dir". The key part to understand is that getAbsoluteFile() must be called (as shown below) or else relative paths will be resolved against the default "user.dir" value.
import java.io.*;
public class FileUtils
{
public static boolean setCurrentDirectory(String directory_name)
{
boolean result = false; // Boolean indicating whether directory was set
File directory; // Desired current working directory
directory = new File(directory_name).getAbsoluteFile();
if (directory.exists() || directory.mkdirs())
{
result = (System.setProperty("user.dir", directory.getAbsolutePath()) != null);
}
return result;
}
public static PrintWriter openOutputFile(String file_name)
{
PrintWriter output = null; // File to open for writing
try
{
output = new PrintWriter(new File(file_name).getAbsoluteFile());
}
catch (Exception exception) {}
return output;
}
public static void main(String[] args) throws Exception
{
FileUtils.openOutputFile("DefaultDirectoryFile.txt");
FileUtils.setCurrentDirectory("NewCurrentDirectory");
FileUtils.openOutputFile("CurrentDirectoryFile.txt");
}
}
It is possible to change the PWD, using JNA/JNI to make calls to libc. The JRuby guys have a handy java library for making POSIX calls called jnr-posix. Here's the maven info
As mentioned you can't change the CWD of the JVM but if you were to launch another process using Runtime.exec() you can use the overloaded method that lets you specify the working directory. This is not really for running your Java program in another directory but for many cases when one needs to launch another program like a Perl script for example, you can specify the working directory of that script while leaving the working dir of the JVM unchanged.
See Runtime.exec javadocs
Specifically,
public Process exec(String[] cmdarray,String[] envp, File dir) throws IOException
where dir is the working directory to run the subprocess in
If I understand correctly, a Java program starts with a copy of the current environment variables. Any changes via System.setProperty(String, String) are modifying the copy, not the original environment variables. Not that this provides a thorough reason as to why Sun chose this behavior, but perhaps it sheds a little light...
The working directory is a operating system feature (set when the process starts).
Why don't you just pass your own System property (-Dsomeprop=/my/path) and use that in your code as the parent of your File:
File f = new File ( System.getProperty("someprop"), myFilename)
The smarter/easier thing to do here is to just change your code so that instead of opening the file assuming that it exists in the current working directory (I assume you are doing something like new File("blah.txt"), just build the path to the file yourself.
Let the user pass in the base directory, read it from a config file, fall back to user.dir if the other properties can't be found, etc. But it's a whole lot easier to improve the logic in your program than it is to change how environment variables work.
I have tried to invoke
String oldDir = System.setProperty("user.dir", currdir.getAbsolutePath());
It seems to work. But
File myFile = new File("localpath.ext");
InputStream openit = new FileInputStream(myFile);
throws a FileNotFoundException though
myFile.getAbsolutePath()
shows the correct path.
I have read this. I think the problem is:
Java knows the current directory with the new setting.
But the file handling is done by the operation system. It does not know the new set current directory, unfortunately.
The solution may be:
File myFile = new File(System.getPropety("user.dir"), "localpath.ext");
It creates a file Object as absolute one with the current directory which is known by the JVM. But that code should be existing in a used class, it needs changing of reused codes.
~~~~JcHartmut
You can use
new File("relative/path").getAbsoluteFile()
after
System.setProperty("user.dir", "/some/directory")
System.setProperty("user.dir", "C:/OtherProject");
File file = new File("data/data.csv").getAbsoluteFile();
System.out.println(file.getPath());
Will print
C:\OtherProject\data\data.csv
You can change the process's actual working directory using JNI or JNA.
With JNI, you can use native functions to set the directory. The POSIX method is chdir(). On Windows, you can use SetCurrentDirectory().
With JNA, you can wrap the native functions in Java binders.
For Windows:
private static interface MyKernel32 extends Library {
public MyKernel32 INSTANCE = (MyKernel32) Native.loadLibrary("Kernel32", MyKernel32.class);
/** BOOL SetCurrentDirectory( LPCTSTR lpPathName ); */
int SetCurrentDirectoryW(char[] pathName);
}
For POSIX systems:
private interface MyCLibrary extends Library {
MyCLibrary INSTANCE = (MyCLibrary) Native.loadLibrary("c", MyCLibrary.class);
/** int chdir(const char *path); */
int chdir( String path );
}
The other possible answer to this question may depend on the reason you are opening the file. Is this a property file or a file that has some configuration related to your application?
If this is the case you may consider trying to load the file through the classpath loader, this way you can load any file Java has access to.
If you run your commands in a shell you can write something like "java -cp" and add any directories you want separated by ":" if java doesnt find something in one directory it will go try and find them in the other directories, that is what I do.
Use FileSystemView
private FileSystemView fileSystemView;
fileSystemView = FileSystemView.getFileSystemView();
currentDirectory = new File(".");
//listing currentDirectory
File[] filesAndDirs = fileSystemView.getFiles(currentDirectory, false);
fileList = new ArrayList<File>();
dirList = new ArrayList<File>();
for (File file : filesAndDirs) {
if (file.isDirectory())
dirList.add(file);
else
fileList.add(file);
}
Collections.sort(dirList);
if (!fileSystemView.isFileSystemRoot(currentDirectory))
dirList.add(0, new File(".."));
Collections.sort(fileList);
//change
currentDirectory = fileSystemView.getParentDirectory(currentDirectory);

Where do you find the JDBCProvider Interface?

As part of my ongoing JDBC/Oracle saga, I solicited the help of one of our Java/JDBC experts and after receiving some more input via my last question "For JDBC in XPages, how does the server know the connection information?" we imbarked on creating a plugin for my ojdbc14.jar file. We got the plugin created and tried to complile it. It complained that it could not find the JDBCProvider Interface. My question is where do I find this? Is this part of the Extension Library files on the Server or is this something completely different?
As always, any help will be greatly appreciated.
Thanks,
MJ
You'll want to pick com.ibm.commons.Extension in the Extension Point dialog, and then set the type as com.ibm.commons.jdbcprovider. Set the class to your JDBC driver provider class (named com.ZetaOne.JDBC.drivers.DB2.DB2DriverProvider for example) which i've provided sample code for below that looks like this (customized to your particular driver, etc)
package com.ZetaOne.JDBC.drivers.DB2;
import java.sql.Driver;
import java.sql.SQLException;
import com.ibm.commons.jdbc.drivers.IJDBCDriverAlias;
import com.ibm.commons.jdbc.drivers.JDBCProvider;
public class DB2DriverProvider implements JDBCProvider {
public DB2DriverProvider() {
{
public Driver loadDriver(String className) throws SQLException {
if(classNmae.equals(com.ibm.db2.jcc.DB2Driver.class.getName())) {
return new com.ibm.db2.jcc.DB2Driver();
}
return null;
}
}
Assuming you've done everything else needed for the plugin, you should be able to export / create your update site and install the driver.
BTW, you'll be able to read how to setup & deploy and use the JDBC package in ExtLibX in our upcoming book "XPages Extension Library: A Step by Step Guide to the Next Generation of XPage Controls" - available on amazon pre-order at http://www.amazon.com/XPages-Extension-Library-Step---Step/dp/0132901811
Hope this helps.

ZXing-1.7 Sample implementation issue

I recently started a small project in which I wanted to use zxing. I downloaded the sources from here. I was able to successfully build the core and the javase jars.
When I tried to code along the sample provided here I ran into a problem I do not quite understand. So far the code looks like this:
public static void main(String[] args)
{
Reader reader = new MultiFormatReader();
ImageIcon imageIcon = new ImageIcon(SOMEPATH);
Image image = imageIcon.getImage();
BufferedImage buffImage = new BufferedImage(
image.getWidth(null),
image.getHeight(null),
BufferedImage.TYPE_INT_RGB);
Graphics2D g = buffImage.createGraphics();
g.drawImage(image, null, null);
LuminanceSource source = new BufferedImageLuminanceSource(buffImage);
BinaryBitmap bitmap = new BinaryBitmap(new HybridBinarizer(source));
}
As you can see this is pretty much the same code as presented in the DevelopersNotes. But the code will not compile. The error message is:
Type mismatch: cannot convert from BufferedImageLuminanceSource to LuminanceSource
Does somebody know what I am missing?
Edit:
My imports are currently looking like this:
import java.awt.Graphics2D;
import java.awt.Image;
import java.awt.image.BufferedImage;
import javax.swing.ImageIcon;
import com.google.zxing.BinaryBitmap;
import com.google.zxing.LuminanceSource;
import com.google.zxing.MultiFormatReader;
import com.google.zxing.Reader;
import com.google.zxing.client.j2se.BufferedImageLuminanceSource;
import com.google.zxing.common.HybridBinarizer;
I added the core.jar as well as the javase.jar to my project. Both I compiled using ant leaving the buildfiles as downloaded.
That's all correct. You must have some funny business in your imports. Those types are certainly compatible.