I'm developing a quite big software for Android in Java (using Eclipse and ADT).
To support my development, I made an own command-line tool that does the following:
Loads and processes certain Java files (from the project of my developed software)
Outputs new Java files to a certain folder (so the input files are retained too) into my project
What the command-line tool does isn't relevant, its output is merely standard Java code (i.e. it's a code generator).
I would like that this command-line tool is automatically called during the build process. In other words, I want that when I'm finished with the manual coding and start the build process (e.g. by clicking "Run..."), the following happens:
The command-line tool is run
The files generated by the command-line tool are included in the build too (i.e. they are compiled exactly as if they were added and coded manually in the Eclipse project).
I'm pretty sure I have to add this program as a "Program" via to the Builder list of the project (see the attached screenshot). My questions:
What position to put it? Should it be the first?
What else do I need to do in order to meet the above requirements? I'm afraid that if the command line tool just writes the .java files to a folder, Eclipse will not see the newly generated files (as they are not added to its project file).
You are on the right track, and it will work fine given these conditions:
Your builder must be at the top, so it can modify the source files before the Java builder is running.
Your Java files must be generated into one of the existing "src" pathes of the project. Java files are not registered in the project, so if you put someting into a source folder of the project, it will be compiled. Eclipse tools like xtext and xtend work the same way.
The refresh option of your builder must be activated. Otherwise the workspace would not know that you created files (as your program works with java.io.File operations, thereby bypassing the workspace API for resources).
Related
I have some basic java knowledge and i decided to switch from Intellij to VS Code. I know how to compile and run a java file (which may use other imported .java files) from the terminal, but i want to run a java program using the run icon inside vs code.
I'm not a 100% sure, but i think that in order to run a java program inside vs code you need a extension. For this reason i downloaded the Java extension pack. Note that i already have installed the latest jdk on my computer.
After i installed the plugin, i could run the program using the "run without debugging"/clicking in the run icon. However, no .class files are produced. I control+h but there isnt any hidden folder that vs code may drop the .class files.
How does the program run in the first place?
How can i config vs code in order to compile the java files before running the one that has the main function?
Basically, when you run a java file normally, you compile it with javac and then run it with java (or something along those lines, there are many different variations of possible ways to do it). If you go ahead and try, it is possible to run java filename.java and skip the normal javac step. In the case of VSCode, it will differ based on what extensions you have, but some may run the code with a simple java filename.java and others may have different settings set. If you take a look at your extension preferences as well as your preferences for java by searching your settings, there may be an option, such as "Java Source Paths" enabled which changed where compiled files are saved by VSCode.
If your project is a folder containing Java source files. And no build tools(Maven/Gradle) are used.
If that is the case, you can trigger the command Java: Configure Classpath, then find the section output and then set a relative path to your workspace.
The output files are by default stored inside the workspace storage.
If after triggering the command, what you see is the native vs code setting page. Then try to search java.project.outputPath and then set a relative path to it.
I have made a GUI based project which consists of 1 main class, multiple Object classes, and resource files (.png and .txt). I have extracted the project as a .jar file (via eclipse) and used that to crease a .exe file (via launch4J). However, when I run the .exe file, it does not launch.
Is it because it does not know which class to run (since there is no manifest file)? What would be some possible fixes?
A manifest (or actually an AndroidManifest.xml) are files for Android systems.
While Android "looks and feels" like Java, it is actually another language. APK files are like a JAR, however, how they are processed and prepared is significantly different, since they are usually DEXed and bit flipped for multiples of 4, they can appear "real jar" for a program, but their instructions are rubish, and have no meaning when executed.
A JAR file is a "Java Archive", and that is another whole concept.
Supposing that the executable was sourced from a correct APK project, then the launch4j should have failed creating the *.exe.
Supposing that the executable was sourced from correct JAR project, then the main is executted (and if its blank, it runs to completion, and ends). It appears as doing nothing, but executes its instructions.
go to run configurations from run menu.---> select java application
---> select the project ---> select your main class ---> save the project ---> clean and build the application.
it seems like you haven't configured a main class for your project.
first of all sorry for my bad english. I have a question and I cant find an answer anywhere.
My Programm exports some loose *.java files withouth any entrypoint. The written API allows an CMD to be executed. Problem is, the CMD Order to start eclipse with parameters. My questions is is it possible to start eclipse 3.3-3.6 with a command line parameter to create a project. Creating a Workspace through -data c:\xxxx\myworkspace is no problem but since eclipse sees no files outside a project, i need to make one so i can put my java files into it and startup an remote debug after it. The Plan is to startup an external export java file, which starts eclipse with the defined workspace and a fresh project (with the exported java files) for usage.
Using Maven it's possible to create an Eclipse project and all kinds of useful stuff, http://maven.apache.org/guides/mini/guide-ide-eclipse.html gives at least a starting point
There are some tools like Maven or Ant plugins that create Eclipse projects from some structural information (e.g. the Maven plugin reads the pom.xml).
If your code is unstructured it might be hard to create a fully functional Eclipse project. You might be able to create a Java project and define its source path (in fact it's a simple XML file called .project - you could easily write one yourself) but any other information like additional dependencies etc. would have to be added manually.
Besides that, creating a simple project from existing sources isn't that hard in Eclipse. Why don't you just do it manually?
Background:
I'm doing machine learning research, and want to use the FANN library to construct neural networks. The source code is written in C, but I need it wrapped so that I can use it with a lot of Java classes we've created.
Question:
The website provides a link to an already well received wrapper software called fannj. Its dependencies is the FANN library source code and JNA. I've never done wrapping before so JNA is brand new to me. The github homepage for the code mentions "you must set the jna.library.path system property to the path of the FANN Library". I'm currently in the process of trying to do this in Eclipse on Mac OS X. A friend of mine mentioned to me earlier that it means I have to pass the location of the FANN library as argument to the virtual machine, but he only showed me how to do this via the shell. I never actually ran this command from the shell, because I wasn't sure how it would conflict with whatever configurations I do in Eclipse later.
How do I set the jna.library.path in Eclipse? The JNA directory is huge, and I don't know where the actual executable is. My friend suggested I modify its run configuration through use of the argument tab, but like I said I don't actually know where the executable is. All I have is the large uncompressed jar file. How can I go about getting it set up in Eclipse?
You don't set in an IDE, just insert in some piece of code that is called BEFORE JNA is called, something like this:
System.setProperty("jna.library.path", "path you need");
Where System is java.lang.System. As for what path you need it must be the path that contains compiled dynamically linked FAAN library (a *dll).
Or just forget that alltogether and dump FAAN (*dlls, *so..) into Windows/system32 (or other appropriate folder on system you use) and these dll's will be on default search path.
Two allow Eclipse to use JNA, all you need to do is to put two jar files in Eclipse's Java Build Path, jna.jar and platform.jar. That's it.
To do this for an individual project, right click on the project in the Package Explorer, click Properties (at the bottom), click Java Build Path on the left, then the Add External Jar files. Browse to the directory with your JNA files and add those two files.
I am coming to Java and Eclipse from a C#/Visual Studio background. In the latter, I would normally organize a solution like so:
\MyProjects\MyApp\MyAppsUtilities\LowerLevelStuff
where MyApp would contain a project to build a .exe, MyAppsUtilities would make an assembly DLL called by the .exe, and LowerLevelStuff would probably build an assembly containing classes used by the higher-level utilities DLL.
In Eclipse (Ganymede, but could be convinced to switch to Galileo) I have:
\MyProjects\workspace\MyApp
When I create my initial project. There is an option to put source and build files in same folder, but I have .java files created on a path that is reflective of my package hierarchy:
\MyProjects\workspace\MyApp\src\com\mycompany\myapp\MyApp.java
My question is this: when I create subprojects (is that the right Java/Eclipse term?) for .jar files that will be analogous to the above MyAppsUtilities and LowerLevelStuff assembly DLLs in .NET, can (should) I organize the folders equivalently? E.g.:
\MyProjects\workspace\MyApp\src\com\mycompany\myapp\myapputilities\MyAppsUtilities.java
What is the standard/right way to organize this stuff, and how is it specifcally done in the IDE?
Think of Java source code packages as one big hierarchical namespace. Commercial applications typically live under 'com.mycompany.myapp' (the website for this application might be 'http://myapp.mycompany.com' although this is obviously not always the case).
How you organize stuff under your myapp package is largely up to you. The distinction you make for C# between executable (.exe), DLL's and low-level classes does not exist in the same form in Java. All Java source code is compiled into .class files (the contents of which is called 'bytecode') which can be executed by a Java Virtual Machine (JVM) on many platforms. So there is no inherent distinction in high-level/low-level classes, unless you attribute such levels via your packaging. A common way of packaging is:
com.mycompany.myapp: main class; MyApp (with a main method)
com.mycompany.myapp.model: domain model classes; Customer, Order, etc.
com.mycompany.myapp.ui: user interface (presentation or view) code
com.mycompany.myapp.service: services within your application, i.e. 'business logic'
com.mycompany.myapp.util: helper classes used in several places
this suggests a standalone Java app, it might be different if it is a webapp using one of the many frameworks.
These packages correspond to a directory hierarchy in your project. When using Eclipse, the root of such a hierarchy is called a 'source directory'. A project can define multiple source directories, commonly a 'main' and a 'test' source directory.
Example of files in your project:
src/test/java/com/acme/foo/BarTest.java
src/main/java/com/acme/foo/Bar.java
lib/utilities_1_0.jar
And inside utilities_1_0.jar:
com/acme/foo/BarUtils.class
BarUtils.class this is a compiled java class, so in platform independent bytecode form that can be run on any JVM. Usually jarfiles only contain the compiled classes although you can sometimes download a version of the jar that also contains the source (.java) files. This is useful if you want to be able to read the original source code of a jar file you are using.
In the example above Bar, BarTest and BarUtils are all in the same package com.acme.foo but physically reside in different locations on your harddisk.
Classes that reside directly in a source directory are in the 'default package', it is usually not a good idea to keep classes there because it is not clear to which company and application the class belongs and you can get name conflicts if any jar file you add to your classpath contains a class with the same name in the default package.
Now if you deploy this application, it would normally be compiled into .class files and bundled in a .jar (which is basically a fancy name for a .zip file plus some manifest info).
Making a .jar is not necessary to run the application, but handy when deploying/distributing your application. Using the manifest info you can make a .jar file 'executable', so that a user can easily run it, see [a].
Usually you will also be using several libraries, i.e. existing .jar files you obtained from the Internet. Very common examples are log4j (a logging framework) or JDBC libraries for accessing a database etc. Also you might have your own sub-modules that are deployed in separate jarfiles (like 'utilities_1_0.jar' above). How things are split over jarfiles is a deployment/distribution matter, they still all share the universal namespace for Java source code. So in effect, you could unzip all the jarfiles and put the contents in one big directory structure if you wanted to (but you generally don't).
When running a Java application which uses/consists of multiple libraries, you run into what is commonly referred to as 'Classpath hell'. One of the biggest drawbacks of Java as we know it. (note: help is supposedly on the way). To run a Java application on the command line (i.e. not from Eclipse) you have to specify every single .jar file location on the classpath. When you are using one of Java's many frameworks (Maven, Spring, OSGi, Gradle) there is usually some form of support to alleviate this pain. If you are building a web application you would generally just have to adhere to its layering/deployment conventions to be able to easily deploy the thing in the web container of your choice (Tomcat, Jetty, Glassfish).
I hope this gives some general insight in how things work in Java!
[a] To make an executable jar of the MyApp application you need a JDK on your path. Then use the following command line in your compile (bin or target) directory:
jar cvfe myapp.jar com.mycompany.myapp.MyApp com\mycompany\myapp
You can then execute it from the command line with:
java -jar myapp.jar
or by double-clicking the jar file. Note you won't see the Java console in that case so this is only useful for applications that have their own GUI (like a Swing app) or that may run in the background (like a socket server).
Maven has a well thought out standard directory layout. Even if you are not using it Maven directly, you can think of this as a defacto standard. Maven "multi module" projects are a fair analogy to the .net multiple assembly layout that you described.
Typically you would create related/sub projects as different Projects in Eclipse.
There are two things you need to clarify before this question can be answered:
Which source code repository will you use?
Which build system will you use to automatically build artifacts outside of Eclipse?
The answers will strongly influence your options.
We have opted for "one Eclipse project pr component" which may be either a library or a finished runnable/executable jar. This has made it easy to automate with Hudson. Our usage of CVS is also easier, since single projects do not have multiple responsibilities.
Note, each project may contain several source folders separating e.g. test code from configuration from Java source. That is not as important as simplifying your structure.