In Eclipse, using the CCW plug-in, I want to load a clojure file into a REPL. The problem is that I have an import statement for one of my own java classes, but apparently it is not in my classpath.
(ns my-clj-ns
(:import [alg.gen Enumerator]))
Do I have to make jars out of every class that I want use/test in a Clojure REPL?
Currently, trying to load my clj into a REPL results in an error:
"Load file in Clojure REPL" did not complete normally. Please see the log for more information.
java.lang.NullPointerException
Any help would be greatly appreciated.
You can let leiningen compile these for you using,
:javac-options {:destdir "classes/"}
:java-source-path "src/main/java" ; location of Java source
options or manually compile them and move the class files to the classes/ directory. No need to create a jar.
When you're in the ccw repl, you can hit alt-e to see the stack trace. If you're getting a NullPointerException, I don't think its a classpath issue.
Your code looks fine to me.
I suspect the issue is with your Eclipse Java Build Path, which determines what Eclipse includes in the classpath for your application.
In particular, if your Java class is in a separate project, you will need to either add that project to the build path (right click on project / Properties / Java Build Path / Projects) or package it as a jar.
When you start to have more sophisticated build requirements, you may also want to start looking at Maven to handle this kind of thing for you. Maven is a pain to learn / set up in the first place but it pays of in the long run.
Leiningen is also a great tool to use but I personally don't use it for the following reasons:
It is great on the command line, but doesn't integrate so nicely with an Eclipse workflow
Maven is more widely used and better supported in the Java world
There is really nice guide if you want to learn how to do this.
https://github.com/technomancy/leiningen/blob/master/doc/MIXED_PROJECTS.md
But in gist, have a project definition like the following for Java source code.
(defproject megacorp/superservice "1.0.0-SNAPSHOT"
:description "A Clojure project with a little bit of Java sprinkled here and there"
:source-paths ["src/clojure"]
:java-source-paths ["src/java"])
Related
I am getting started with Jena and semantic technologies (I am taking a class on the topic). The lecturer recommends using Eclipse as IDE, but I would like to use Visual Studio Code. How can I import apache.jena? I would like to get information/error messages as you would with any other library.
I have had amongst VSCode's extensions, but did not find any support.
I include "import org.apache.jena.rdf.model.;" and get a "not found" error when I try to compile - unless I also include "-cp "/path/to/apacha/jena/on/my/computer/:." when compiling and running the program.
The goal is to be able to compile and run without having to include a path to the library and if possible, for VSCode to have an understand of the library (giving me warnings, suggestions, error messages osv.)
Use Java in VSCODE. You need to install the Extension Pack for Java, and the documentation contains more information.
Use VSCode to open the Java project folder, expand the project structure and display it on the JAVA PROJECTS panel.
Click the plus icon next to Referenced Libraries to add a .jar file reference. Of course you need to download the Jena library on your machine first.
Or use the following configuration in setting to add reference.
"java.project.referencedLibraries": [
"/path/to/jena/lib/*.jar"
]
I want to program in Java or other JVM languages like Scala, Kotlin, or Groovy. When I am programming on my projects, I only want to have import statements in my Java/Scala/Kotlin source files without the need to state the packages a second time in a Gradle/Maven build script. Instead I want to work as I would do in Python, i.e. have my import statements at the beginning of my source files and I am done.
The packages should then automatically included when I am compiling if all packages are installed in a central local package management system or otherwise get an error message telling me that I have to install a missing package. It should essentially work the same as for Python and PIP respectively.
Is a workflow like this possible preferably with Groovy or Maven?
Thanks in advance!
The closest I can think is Grape:
Grape is a JAR dependency manager embedded into Groovy. Grape lets you quickly add maven repository dependencies to your classpath, making scripting even easier. The simplest use is as simple as adding an annotation to your script:
#Grab(group='org.springframework', module='spring-orm', version='3.2.5.RELEASE')
import org.springframework.jdbc.core.JdbcTemplate
Like in this example:
#Grab('net.sourceforge.nekohtml:nekohtml:1.9.16')
def parser = new org.cyberneko.html.parsers.SAXParser()
def page = new XmlParser(parser).parse('https://news.google.com/nwshp?hl=zh-TW&tab=wn')
page.depthFirst().DIV.grep{ it.'#class'=='title' }.each {
println it.A.SPAN.text()
}
I can't judge the Groovy landscape since I don't have any experience there, but for developing Java or Scala applications this exact workflow is not possible as far as I know.
Regarding "I only want to have import statements..." I think the closest you can get is good Maven/Gradle/sbt integration in an IDE, like IntelliJ that automatically adds the desired library to your build system's configuration file when using the correct shortcut. It (at least) works for some Java libraries when you're dealing with a Maven project in IntelliJ.
And regarding your other wish to have packages automatically included when compiling: On the JVM there is the concept of the fat JAR (also called uber JAR), which is basically a JAR (Java archive) that contains all dependencies and is thus self-contained. Usually you can start the application contained in it with a single java command.
To build fat JARs you need to have the approriate plugin for your build system:
For Maven that would be the maven shade plugin, see https://maven.apache.org/plugins/maven-shade-plugin/
For sbt you can use the assembly plugin, see https://github.com/sbt/sbt-assembly
Gradle probably has something similar
A lot of Java frameworks also come with their own build plugins that make building such self-contained applications relatively simple (Spring Boot is one example, but only suitable for applications that on top of an HTTP server)
Hope this helps, althought it's not an accurate answer to your question. :)
So i have tried to find an answer but didn't manage to do it yet. What I'm trying to do is to write a Java code for example in Atom editor, and compile it on Atom itself, without the need of an integrated development environment. Same goes with adding classes to a project.
Is that possible?
Yes. That is how they wrote the first Integrated Development Environments. Although the compilation step is typically performed externally from the editor, if the editor can execute external programs then you can "integrate" compilation. Adding "classes" is a little more involved, in that it requires your "editor" to understand the packaging and structure of the files composing the classes - at that point you have an integrated development environment.
Yes it's possible with atom package build. To install the package Edit-->Preferences-->Install and type build and hit Enter. Then you should configure your custom build command as mentioned in official package website. You may just fill cmd: javac in yml file for example
You need to install a package that will compile. Atom is a hackable text editor but not really an IDE as you pointed out. That said there are a lot of packages for compiling and for working with java.
You can look at Build Tools Package for compiling. It looks like it will work for Java but there are many compilers in the package list.
I would search on their package site for the keyword "Java" to see what java packages you might want to use. Then do another search for "Compile" to see what compiler you might want to use if the build tool above doesn't work for you. You can search atom packages at https://atom.io/packages.
I wanted to try out the new feature of JMH by running it as Java Application in eclipse. I imported and built jmh-samples project. Compiled classes ended in /jmh-samples/target/generated-sources/annotations, there are several JARs in /target/ and running microbenchmarks.jar from command line works as usual.
However when I execute main I always get
No matching benchmarks. Miss-spelled regexp?
Any ideas? I am using version 0.3
jmh-dev# is a better way to communicate this with the developers.
Few things to try:
Hijacking Main is probably not a good idea. Use Java API instead, like this sample.
Use -v extra to debug the pattern matching: either the filter regexp is incorrect, or there are no benchmarks to run.
If the regexp is incorrect, fix it.
If there are no benchmarks to match against, then there is a chance resources are not generated and/or picked up properly. Make sure target/classes/ is also available on classpath.
Okay, so looks like by default jmh looks for generated classes under META-INF/Microbenchmarks, which maven build puts under root of the project. However root of the eclipse project is not on the classpath, so executing it in IDE results in "no benchmarks found".
I got it running following way:
mvn clean package (using external maven installation, not embded
in eclipse)
Right-click on jmh-samples project, select "Build
Path -> Use as a source folder"
You can now run any of the benchmarks from jmh-samples as Java Application in eclipse
On the downside you get like 1000+ "errors" in Problems view, since eclipse gets confused with auto-generated files, but oh well, at least it works.
I was also facing the same problem, and I followed the tutorial here. That solved the issue.
Below are the steps I took:
I used the code from the tutorial AS-IS to understand how it works.
Then I just did mvn clean and install
I saw all set of classes being created in target -> annotations -> <package path> -> generated
Then I ran the BenchmarkRunner main() class and this worked.
I have looked for an answer for this nearly every where that I can think of, but there doesn't seem to be any way to actually SEE what Eclipse "runs" to compile the projects (as it does need the JDK installed and visible to actually build). I ask because I imported a few jars into my project, and even though I've looked through all the javac documentation, I can't seem to figure out how to mimic it quite like Eclipse does. I really, really need to be able to compile on the command line in this case - Eclipse or any other IDE just isn't what is needed.
I started to look through the Eclipse source, and although this sounds lazy, I just became overwhelmed and figured I would ask here first, hoping someone else had the same question at one point.
Eclipse JDT does not require the JDK and does not use javac - it uses it's own compiler.
You can see the classpath by reading your project .classpath file. The various builders that are used to perform build operations (Java, or whatever the project builds) are listed in the .project file. (These are also listed in the project settings.)
It is possible to invoke Eclipse to build your project in headless mode, or write Ant scripts that can be executed both with the JDK and within Eclipse, or install Maven support for internal and external building. It is also possible to configure the project builders to rely only on external tools.
Look at these two articles.
http://www.eclipse.org/articles/Article-Builders/builders.html
http://www.eclipsepluginsite.com/builders-natures-markers.html
Look at your .classpath file and start building an ANT build.xml. You need to do this to be able to have consistent builds on a build machine anyways. It is unlikely that a build server would have eclipse installed on it anyways.
Maven is also another tool that is used for builds. In our shop we use Ant.
Have a look at ant4eclipse - this project allows for generating the appropriate ant data structures for invoking <javac> from the .classpath files and a projectSet.psf file.
By using this we can use Eclipse "natively" and bend ant to conform to Eclipse. The usual approach is the other way around.