Can someone please explain the following
How was the first JDK release unit Tested? Since Junit came after Java how did they do it?
Are the current releases using Junit to test the JDK API?
Regards
The JDK is tested , at least now, using jtreg . I am not aware of any usage of JUnit to test the JDK.
Unit testing is a concept and a practice. It is not a package or specific implementation thereof (although it was admittedly popularised by JUnit).
I don't know what's the Sun, Oracle :-), standard is for testing. I'm sure it's pretty thorough though. Bear in mind there is more than on JDK publisher.
I imagine that the very first JDKs (pre Java 1.0) were tested using a harness implemented using other technologies; e.g. C, shell scripting, and so forth.
Certainly Java unit testing was done in Java well before JUnit came along. I remember using a framework developed in-house at DSTC in the late 1990s, and the GNU Classpath project used a framework called Mauve. Java test frameworks are not rocket science.
Related
I am curious to understand how Java tests its APIs. Let's say,I am interested in the class ConcurrentHashMap, will there be any unit tests for this class? If so, is it available for public?
When you say "Java" you probably mean the Java Development Kit (JDK), which comes as OracleJDK and OpenJDK (OracleJDK is essentially OpenJDK with a few extras). OpenJDK is open-source; and the source code for all of its projects can be found here:
http://hg.openjdk.java.net/
In particular, here is a browsable version of the jdk7 project directory.
I am curious to understand how Java tests its APIs. Let's say,I am interested in the class ConcurrentHashMap, will there be any unit tests for this class? If so, is it available for public?
Yes, for a list of all jdk7 tests look in jdk7/jdk/test.
If you are interested in ConcurrentHashMap tests, look in jdk7/jdk/test/java/util/concurrent/ConcurrentHashMap:
NOTE: The JDK tests may look a bit awkward because it does not use JUnit, it uses JTreg.
Any class packaged inside jdk like ConcurrentHashMap is tested and you don't need to worry almost all the cases. If you implementing a well defined interfaces then there are test cases available which can run against your API and check whether it's complacency. In addition if you define a new API which you will expose, you have to write your test cases using JUnit or TestNg. Here the purpose of your test cases should be checking whether your API giving expected results. If you cover all the combination of using your API then you can identify when there is a regression.
Offtopic : Integration testing suppose to test the whole project when all the components are integrated.
[Update] If you really need to test ConcurrentHashMap you can use a sample project which uses ConcurrentHashMap, please keep in mind that you better choose multi-thread project.
You probably won't be able to get the source (and thus the testing code) for Oracle's Java. However, since OpenJDK theoretically follows the same specifications for behavior as Oracle Java (at least for all the parts of it that I'm familiar with), you could perhaps use their unit tests to test your library. The source for OpenJDK's jdk8 can be browsed here (see the test directory for tests), and you can find other versions of java at their main page.
However, as Erranda points out, you should really ask yourself if you want to test the existing libraries. They are probably more thoroughly tested than anything you'll end up writing already, and unless you want to recompile Java from source after finding an issue (which could lead to compatibility problems), what good would finding a bug in the libraries do?
Context
Basically, I have a library that is used in several applications running on java 6, java 7 and now java 8.
The library also has a dependency on a creepy (yet very useful) third party library (which I won't name) - a library that doesn't care a lot about forward-compatibility. The aforementioned applications also make heavy use of this third party library but are not always able to update to the latest version. I'm used to it, so I have a lot of "if" in my code dealing with silly things.
Problem
Today I stumbled upon an annoying problem: some method in the third party library has a different behavior when running in java 7 and earlier than when running in java 8 and later.
My unit tests were designed to cover this part of my code and would have spotted the bug if they were run with the correct java / library combination.
Question 1
How can I integrate nicely in the maven build lifecycle and run my tests sequentially with java 6, java 7 and java 8? (which implies failing if any test fails with any jvm)
Question 2
Same as above but adding another sequential run with each "supported" version of the third party library ?
(which means, to be clear, that, if I "support" version 6.11, 6.12, 6.13 and 6.14 of this lib with all 3 java versions, I will run 4*3=12 times my unit tests)
i have similar problem. i created a library that should be tested against different versions (all available in maven central) of other library and (but that's less important) jvm.
my conclusions: doing this only in maven will be veeeery cumbersome and hard, if not impossible. you will also have to encode environment/system dependencies into your build tool
as suggested, most integration servers support matrix tests. you can use it also to manually provide every single version (if you know them upfront) of library you need to test against. the library part should be doable much easier in gradle (but still no out-of-the-box support).
regarding number of tests: yes will have to run x * y times. if your code is big think about isolating the part that uses other library and run only this small part x times for each jvm - it will be a bit faster. also you can run those tests in parallel
ps: i'm thinking about writing a gradle plugin or at least a proof-of-concept build. but i don't think it will be soon. but i'm open for other contributors :)
I want to change the JDK version 1.5.15 to 1.6.29. If I do this, will any problems occur in an existing application that was developed under JDK 1.5.15?
Technically that shouldn't be a problem. But I would have a bad feeling doing this without enough test coverage. There was a project in my company were they were also changing to a newer java version (don't remember which one). Everything seems to be fine but after some time a few bugs were rising. It turned out that one developer illegally relied on the order of a Collection class. The bug was caused by a changed implementation.
Take a look at the Java SE 6 Compatibility with J2SE 5.0 document. It should be ok, but please go through the incompatibilities section just in case.
Try to compile your code with new JDK(1.6.9) classpath than you are fine no need to change anything.
If code change require follow some online JDK 1.5 to 1.6 migration tutorials already available.
You will have to test this. It probably is possible to compile and run your application with JDK1.6, but some behavior might have changed in a subtle way. An example of such a change between JDK1.6 and JDK1.7 I recently encountered is posted here on StackOverflow. Although the project compiled just fine, testing (unit tests, integration tests and manual testing) revealed some issues which weren't caught by the compiler
No i don't think it will create any Problem.
I'm going to give a talk about using Java and Scala together and I want to investigate some projects (large and small) which contains Java and Scala code.
If you know links to correspondent projects post them here.
This page on the Scala wiki is a good starting point...
The various scala testing frameworks come to mind. They all have some integration with JUnit or TestNG
Gimd is one example of small project: http://code.google.com/p/gimd/
Although development stalled for a while because I'm busy with other duties it already contains some examples of Scala<->Java integration. Notably:
unit tests are written using junit
Gimd is using JGit (library in Java) as underlying layer
While working on Gimd I found that using Java from Scala is mostly easy and seamless the contrary is not always true. It's not really a fault of Scala as it's simple manifestation that Java is a less expressive language.
Unfortunately I don't know any open source project but I have worked on very large projects over the last few years that have java and scala interacting and my experience has been mostly very positive. If I had one piece of advice it would be to use scala-javautils. It's a life saver and is far better than the scala jcl code. Before we started using it trying to get some interactions involving collections was heart-breaking. However I'm led to believe 2.8 will solve this.
In general I find the interactions between scala and java very close to using one language.
Is there any solution through which I can convert java'a higher application, created in netbeans IDE 6.5.1, into lower version of java version 5.
If you have the source code, which I assume you do, this might be easy or difficult depending on the code.
Java 6 made few language changes over Java 5. The only one that springs to mind is you can put #Override on implementations of an interface.
The bigger issue is whether you use any of the API differences, of which there are several. I think JDBC has some major differences, which you may or may not use.
These issues may be big or small. It's really hard to say without knowing anything about your app. Generally speaking though they should be small.
Otherwise you should mostly just be able to recompile it with a Java 5 compiler.
If you don't have the source code it's still doable but you just need to disassemble it first and fixing any issues may be tedious.
You can simply try to recompile it for Java 5. As no language-changes are made between version 5 and 6 you can only run into problems, if you use APIs added or enhanced with the version-upgrade.
If you have the source, you could use backported libraries and code rewrite. There is a tool called Retroweaver which can convert 1.5 code to 1.4, but I doubt It works for 6 to 5.
there is an option somewhere to tell Netbeans to generate GUI with non-Java 6 classes. It is documented somewhere, sorry I don't remember. I've already switched to Netbeans 6.7 (RC3).
Check also usages of Desktop API, #Override in implementing interface methods, etc.
It is a good practice to build with a JDK5 in a CI server (like hudson).