I use evosuite 1.0.1 for automated test case generation for several open source projects. I use java 1.8 on a unix platform (ubuntu 14.04).
Is there a way to use wildcards for dependencies in the -projectCP tag?
Some of my projects depend on a huge number of libraries and this could save me heaps of time. If you have a solution for either terminal or ant build script (no IDE) I would be very thankful!
It is (currently) not possible to use wildcards in -projectCP. A workaround is to use first the -setup option to create the classpath (in which using wildcards is possible) on a configuration file on disk, and then run EvoSuite without -projectCP (as the CP will be taken by the previously generated file). For more info, look at the documentation on http://www.evosuite.org/documentation/commandline/
Related
I'm just about starting to learn Java. Reading about, I installed Netbeans.
Running Apache Netbeans IDE 11.2.
The Java version is 13.0.2.
I'm promptly follow the Quickstart guide on the netbeans website.
File>>New project>> Java >> Java Application.
Errhmm, I don't have this 'Java' option. All I have is
So what's the difference between Java & Java with Maven/Cradle/Ant . At this point in time, I intend to start with basics of Java programming and then move on from there. SO which option am I meant to be starting with? If I'm missing Java, how can I add it ? Going through the installation procedures didn't give me any option to choose from.
p:s - this is all running on Mac OS Catalina
You can start with any of Java with ... option. I use Java with Ant option.
Maven, Gradle, Ant are build-tool addons i.e. they provide additional support if you intend to use any of these as your build tool.
When you choose Java with Ant option, it will let you create, compile, debug and run your Java programs without requiring anything additional. After using this option, you will get an interface as shown in the screenshot given below:
Maven, Gradle and Ant are build tool which allows you to compile, unit test, package and (if you like) even deploy your Java applications (they do support other languages btw).
I suggest you to start with one of those (Maven is very popular and probably a little bit easier than the others) instead of relying on your Java IDE specific features.
Once you master a build tool you can change IDE (IntelliJ is also a very good option ;-)) and will still work as before. You also find plenty of resources and help (like Stackoverflow) if you need hit some problems.
Best of luck!
I'm writing some code that uses the Subversion (SVN) Java bindings (JavaHL) directly (where JavaHL comprises native libraries and a thin Java wrapper). On Linux (Ubuntu 12.04) this is no problem: package libsvn-java installs the native libraries and \usr\share\java\svn-javahl.jar, so i just reference the latter and away I go.
On Windows, I know of no such clean packaging of the pair (JAR + native libraries) together. I was aware that SlikSVN contains a JavaHL implementation, but installing that seems only to install the native libraries (which it does put on the PATH). Is there anything that gives a clean package of the two? (If SlikSVN does package the JAR, it's in no place I expect, and a search of the whole drive finds nothing...)
As a workaround, I built the JAR file manually (details below which may be useful for people). But it seems that the 'match' of Java wrapper and native libraries is very precise: when I built a JAR from later SVN source code (instead of that matching my exact SlikSVN SVN version) as a test, I got fatal errors in the native code (EXCEPTION_ACCESS_VIOLATION). Perhaps I was unlucky but, if it is pretty sensitive, I'll need to provide a JAR library for every potential version of SlikSVN (and thus SVN) that users might install (or restrict their SlikSVN choices, or have some prone-to-error auto-build process which would need them to install a JDK). All bad options :-(
Manual Workaround (Bad!)
I had SlikSVN 1.8.10: svn --version reports version 1.8.10-SlikSvn-1.8.10-X64.
So I got the Java wrapper source from the tagged SVN release. (You can also get it from the
main site's source downloads.)
svn export http://svn.apache.org/repos/asf/subversion/tags/1.8.10/subversion/bindings/javahl/src
Compiling this (there are no dependencies) into a JAR, and using that, worked fine with the SlikSVN native libraries.
P.S. I know that I could use SVNKit to avoid having to do this, but I'm doing this precisely so as not to rely on SVNKit for licensing reasons (plus the JavaHL API is fine and reasonably high-level anyway, and there are other reasons to prefer using the 'official' native JavaHL implementation).
The WANdisco binaries should have JavaHL in them.
http://www.wandisco.com/subversion/download
Been a while since I used them myself (don't typically use Windows). But WANdisco has tools that depend on JavaHL so I can't imagine the Windows binaries are missing JavaHL.
[Question author edit to complete detail]
You need to install the (Windows) Subversion client (not SmartSVN), and make sure you check the box to add it to the Windows PATH. This stores the 'paired' JAR in the install directory (along with the native libraries). However, WANDisco only provide a 32-bit install (see this forum post) so this won't work on 64-bit Windows. In addition, the JAR only includes the Apache versions of the API, which were added for Subversion 1.7. If you're using the legacy org.tigris.subversion.javahl package API for compatibility with pre-1.7 SVN clients, you still need to build the JAR manually.
I am working on a Java test project using Cassandra for persistence and Achilles as my client API for Cassandra. Also, for testing purposes I am running Gradle builds on this project in Drone.io.
The Achilles library depends on Java 7, which is one of the possible types of builds for Drone.io, but since this is a Gradle build, it is necessary to make it a Groovy build. According to this official doc page, it should still be possible to use Java 7 inside the Groovy JVM with just an additional command in the build script in order to change from the default 1.6 JVM:
sudo update-java-alternatives -s java-1.7.0-openjdk-amd64
However, after adding that line to the build instructions, I get the following error messages from the Drone.io build log:
update-alternatives: error: no alternatives for mozilla-javaplugin.so.
update-java-alternatives: plugin alternative does not exist: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
This is apparently a frequent error for which I managed to Google a number of solutions.
My problem is that all of these solutions involve installing plugins and/or adding entries to the sources list, which doesn't seem to be very straightforward in the Drone.io virtual machine.
One solution was running sudo update-alternatives --install /usr/lib/mozilla/plugins/mozilla-javaplugin.so mozilla-javaplugin.so /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/libnpjp2.so 1 (I updated the path from the original solution in order to reflect the VM's directory structure) to install the missing lib, but there is no libnpjp2.so file at this location in the VM.
Has anyone had better luck using Java 7 in Groovy/Gradle builds in Drone.io or has any idea of a workaround?
The best way to use Gradle with drone.io (and even in general) is via the Gradle Wrapper. This works with any drone.io build type, so you can simply select Java 7.
There is Java tool (it is called Mallet)
http://mallet.cs.umass.edu/download.php
which I want to use in my .NET project.
To convert this tool to .NET library at first I've tried to build it in single .jar file using Apache Ant. I've done everything corresponding to instructions at link above.
Download Developer Release from Mercurial repository.
Download Apache Ant, install JDK, set JAVA_HOME var to use Apache Ant.
Using Ant I've built single mallet.jar file.
And then I would to convert mallet.jar to .NET library using IKVMC.
When converting, I've got a lot of warnings such as:
Warning IKVMC0108: not a class file "cc/mallet/util/tests/TestPriorityQueue$1.cl
ass", including it as resource
(class format error "51.0")
Despite of these warnings, mallet.dll was created. But when I try to reference to it from my .NET project, it looks "empty". It has not any classes or namespaces. I don't forget to reference to IKVM.OpenJDL.Core.
And this is unusual that I can't find any same problems in Google.
I think that problem is in warnings. And I have never worked with Ant and I don't understand all process exactly.
The class format version 51 was introduced with Java 7.
IKVM most likely doesn't support that version yet and the file name you quote (cc/mallet/util/tests/TestPriorityQueue$1.class) points at an anonymous inner class of TestPriorityQueue that certainly is needed for the library to work correctly.
My suggestion: compile Mallet using an older JDK or at least using the -source and -target switches set to 6 (to ensure that it's compile for Java 6).
FYI v8.1 (currently in RC) of IKVM supports Java 8:
http://weblog.ikvm.net/2015/08/26/IKVMNET81ReleaseCandidate0.aspx
http://sourceforge.net/p/ikvm/mailman/message/34502991/
I'm maintaining a perl script which runs an automated install of our base server software. One of the new requirements is to install the Inline::Java module.
Our usual strategy of installing using Yum seems to fall down as there's no Inline::Java available in yum. I can't find an RPM release for it so can't install as an RPM. The only options seem to be installing through CPAN or shipping the tar and having a step which identifies the SDK location and runs 'perl Makefile.PL J2SDK=; make; make install'.
Instinctually I think that's a little shaky for an automated install, I've had problems with CPAN installs failing in the past and I don't really want to have to make on a live server, but I can't think of a better option.
The other option I considered was just shipping the .pm file, placing it in a user defined directory and using 'use lib' to define that as a location but due to the way Inline::Java works I don't think this is possible, it needs the location of the InlineJavaServer and such too.
Does anyone have a better solution or an opinion on which of the ones proposed above is the best?
You could build your own perl-Inline-Java package and put it in a private yum repository, or even contribute it to Fedora/EPEL.
Inline::Java will look for InlineJavaServer.jar and the other files it needs in the same location as the Inline/Java.pm file. Copying the whole distribution from the install directory on one machine and copying it to another machine (with the same architecture) isn't as crazy as it sounds. If you only have a few different systems (not all linux, 32 bit vs 64 bit, perl 5.6 vs perl 5.10, etc.), it is tractable to make a separate package for each system.
There is some install-time configuration in Inline::Java, including specifying the default Java installation to use. But this (and other default configurations) can always be overridden with environment variables like PERL_INLINE_JAVA_J2SDK (see the Inline::Java perldoc for the complete list). You could package Inline::Java with your own custom module, say,
MyCompany::InlineJavaConfig, that can set the appropriate environment variables before the Inline::Java module gets loaded in each script.
There's some other install-time configuration like whether to configure JNI and other native support. It might be a little dicier to copy the files that support these features from one machine to another. But I can't think of any reason off-hand that it wouldn't work.