We Keep Coding

Add jena library to netbeans

I want to add the Jena library to Netbeans. When I visit http://www.apache.org/dist/jena/ to download Jena library there are two folders: binaries/ and source/. I don't really know whether I should download binary files or source files. In the binary folder there are also so many files some with extension .zip, .tar.gz, .tar.gz.asc etc...
Which one do I use?
Secondly, in the online tutorials, they say that only jar files need to be added. In one of the folders I downloaded (apache-jena-2.10.1.zip) jar files are present in lib, lib-src and src-examples.
Do I have to go in every folder and individually add it to library?
What about the other folders: bat, bin, java-docs? What am I supposed to do with them?
Kindly explain as comprehensively and clearly as possible, as I am new to this field with little knowledge about this stuff.

By the sound of it you want apache-jena-2.10.1.tar.gz or apache-jena-2.10.1.zip, which are different packagings of the same content -- the jena libraries, their dependencies, documentation and command line tools. asc, md5, and sha1 are present so that downloaders can check the integrity of the revelvant download.
So the zip you have is what you need. For working with jena you only need the jars in lib/. lib-src/ contains the jena source, and may be useful in netbeans if you want to look up the implementation of jena (for example when debugging).
java-docs/ contains a copy of the jena javadoc: the jena api documentation which is also available online.
bin/ provides command line tools for unix users. bat/ is the equivalent for windows users.
In the long run I recommend using netbeans with maven (see this answer for a quick guide). With maven libraries are downloaded as needed, so you don't need to manually locate the jena distribution and extract the libraries.

Detect current app version

When I was working with XCode and iOS, there was a simple way to check the application's current version by reading the plist.
Is there a similar way to do this in Java?

XCode stores that version value in a resource file that is distributed with your application. In Java the equivalent would be your Manifest file, which is packed inside your JAR/WAR/EAR archive.
A Manifest file is just a metadata text file named MANIFEST.MF that stores some standard key/value pairs which are recognized by many tools and that is packaged inside a special folder named META-INF inside your java archive.
To get the Manifest file for your own JAR this question would give you some clues. Once you have your own Manifest instance then use either one of the next options to get that version value.
This way to get the Specification Version:
Manifest mf = .... // get the manifest file
String specVersion = mf.getAttribute("Specification-Version");
This way to get the Implementation Version:
Manifest mf = .... // get the manifest file
String specVersion = mf.getAttribute("Implementation-Version");
More info regarding the JAR manifests can be found here.
EDIT:
If you are getting null values for any of those properties that means that they haven't been configured in your MANIGEST.MF file. That's easy to check: unzip your JAR file (JAR files are just ZIP files with a different extension name) and go the META-INF folder to find the MANIFEST.MF file, since it's a text file you can print its contents to the console, if there is a Specification-Version or Implementation-Version attribute defined there and you are still getting null values then you might be loading a manifest file from a different JAR.
FOR THE RECORD:
To get that attributes in your Manifest file you would need to configure your build tool to do so. Maven would do it automatically (you can customize it though), with Ant you will need to use a specific Ant Task, with Eclipse you will need go through its docs (same with any other IDE).

As Alonso says, in Java, your code isn't automatically assigned a build version by the compiler. Java leaves that up to the build tool that your compiler is run by, e.g. ant or maven. If your app isn't using the manifest file, which is often the case, but using instead a version number suffix, e.g. my_app_1.2.3.jar then you could do this to get the jar name:
Class.getProtectionDomain().getCodeSource().getLocation()

If it has a GUI and the main purpose1 is 'update' use Java Web Start to deploy it.
For displaying the version to the user I would store the version number in the manifest of each Jar of the app., and show the Implementation-Versions in a JTable at run-time.
As an aside, to get better answers, put aside what you are trying to 'do' and instead name the 'feature' you are trying to achieve. The latter can be expressed as the application feature you would like to offer the user. It might be something like 'Can be expanded with plug-ins', 'Has free auto-upgrade for 24 months', 'Whiter, brighter, more suds'..

Is it possible for a Java JAR file to damage your system and how can you check what it's doing?

I want to evaluate a software solution where multiple people have submitted JAR files to perform a task on Windows.
Is it possible to check whether the JAR file performs any additional unwanted behaviors besides those it claims to perform on your machine?

First, you can use a JVM set with SecurityManager to do run your application in a way that it can have limited access to sensitive functions.
You can also set up a "sandbox" so the jar cannot have permissions outside of the sandbox... you could use chroot or a similar tool in a linux/unix environment.

1. You could use software from Sysinternals:
http://technet.microsoft.com/en-us/sysinternals/bb842062
You can see is program's writing or deleting something from hard drive with HardMon, or monitor any changes with RegMon... Check out their website, they have much programs and you can monitor practically everything!
2. Or you could install Sandboxie:
http://www.sandboxie.com/
and then run you program within sandbox ("virtual filesystem"). When you run a program inside of sandbox, you can see what files did the program make, and the best thing is that any changes that the program did will be undone when it exists, so it can't harm your system. :)
3. Also, you could try to decompile JAR file:
http://www.google.hr/search?sourceid=chrome&ie=UTF-8&q=java+decompiler

Yes and No. By default java programs can do the same things any native program on your system can do. This includes deleting and replacing any file it can access, depending on your operating system and your user privileges this may affect system critical files.
It is possible to restrict what java applications can do, applets and webstart programs usually are secured this way. Alternatively you can run any program as a different/restricted user or in a sandbox to limit the damage it can do.
If you do not trust the library/program always run it in one of the restricted environments mentioned above. It may crash if it does something it should not do, but it will be unable to do any damage.

I tried the solution from jensign.com and it looks like it restricts almost everything. The .jar application that I used to test wasn't even able to download a website. However I'm not an expert at this stuff so I can't tell if it is a 100% safe solution.
The JAR'd application can be launched under fully restrictive sandbox conditions (very similar to Java applet default security sandboxing):
java -jar -Djava.security.manager PropsFrame.jar
cite from jensign.com

Try a decompiler, like Java Decompiler:
http://jd.benow.ca/
It decompiles the .jar file, and shows you the source, though keep in mind it might be copyrighted:
By the way, why don't you ask for them to submit the source code as well, instead of just the .jar files?
Basically, .jar files are like souped-up zip files, and I believe even WinRAR can open .jar files. A quote from their site:
Java Archive File (a compressed file
for applets and related files) (.JAR)
Short for Java Archive, a file format
used to bundle all components required
by a Java applet. JAR files simplify
the downloading of applets since all
the components (.class files, images,
sounds, etc.) can be packaged into a
single file. Additionally, JAR
supports data compression, which
further decreases download times.
JAR file support is the same as ZIP
file support. JAR = ZIP + manifest.
The Microsoft VM supports uncompressed
and compressed JAR levels 0 and 1, but
not signed JAR.
WinRAR provides basic operations for
JAR files created by other tools: view
contents, extract files, show comments
and archive information.
You can use the convert function to
convert .jar files into .rar format.
You do not need to have any external
programs to handle these formats.
After extracting with WinRAR, you can view the source by following this link as an alternate method to JD.

overwrite java class in jar

I have class called org.jbpm.task.Comment in my jbpm.jar.
However, this it's a CR1 version and there is a bug in the class that I would like my application to overwrite.
Is it fine just to have a class in my project under com.jbpm.task called Comment and everywhere even in other jars it will refer to mine?

JAR files are just ZIP files. Use a tool like WinZip to extract all the files from the JAR, replace the .class file with yours, recreate the ZIP file using e.g. WinZip, rename it to .jar, overwrite the original JAR file.
If you don't have the original source to the .class file you need to correct, then use a Java decompiler to produce .java source for the class. It will lack comments etc present in the original, but it will be sufficient to correct errors (e.g. incorrect null checking, as I had a few times in some products.)

I would suggest using a Zip utility like 7zip to open the jar file and replace the class in the jar file the the latest one.

Well the behavior is not guaranteed. Sometime back I had a bad experience because of that. Check out the below SO thread. If you are targeting differnt JVM implementation then it could be a problem.
Xerces behaving differently on SUN JRE v1.5 and IBM J9 v1.5

You would have to make sure that your jar is loaded before bpm.jar. In some JREs jars are in the same location are loaded in alphabetic order.

Including Source in Archive File

I was considering including the source code in my archive file (EAR, JAR, WAR) so we could see what the deployed application looks like.
This will obviously make the archive much bigger. Does the size of the archive file affect performance on the application server at all? Is this a good idea or not?

Here's another solution to your problem which can come instead (of putting the sources in the .jar) or in addition to it: Specify the source control revision id to the .jar. You can specify it in the manifest file or in a properties file.
The source control revision id is the current id associated with the root of your project on the source control system. It is readily available in SVN, Git and most modern source control systems. In older systems (CVS) you must first create a (named) tag probably by using current date and time (to ensure uniqueness). The revision number will let you to retrieve from the source control the exact snapshot from which the archive was obtained, so when you fix bugs you'll be fixing them on the correct sources.
This technique will allow you to save space - you won't need to ship the whole source directory.
However, it is still a good idea to specify this number even if the sources are included in the archive simply because it unanimously specifies the point in history where the archive was created. Manually comparing the sources in the archive with those in the source control is a pain.

It does affect the performance to the extent that there are more entries in the archive's index but that won't be too bad and you'll put the source in its own subdirectory. Or you can just make a source archive and shovel it around with the other files. That would be my choice. Of course if this is a GPL distribution, you'll have to be explicit about where the source is located.