There are several differences between HashMap
and Hashtable
in Java:
Hashtable
is synchronized, whereas HashMap
is not. This makes HashMap
better for non-threaded applications, as unsynchronized Objects typically perform better than synchronized ones.
Hashtable
does not allow null
keys or values. HashMap
allows one null
key and any number of null
values.
One of HashMap's subclasses is LinkedHashMap
, so in the event that you'd want predictable iteration order (which is insertion order by default), you could easily swap out the HashMap
for a LinkedHashMap
. This wouldn't be as easy if you were using Hashtable
.
Since synchronization is not an issue for you, I'd recommend HashMap
. If synchronization becomes an issue, you may also look at ConcurrentHashMap
.
Java is always pass-by-value. Unfortunately, when we deal with objects we are really dealing with object-handles called references which are passed-by-value as well. This terminology and semantics easily confuse many beginners.
It goes like this:
public static void main(String[] args) {
Dog aDog = new Dog("Max");
Dog oldDog = aDog;
// we pass the object to foo
foo(aDog);
// aDog variable is still pointing to the "Max" dog when foo(...) returns
aDog.getName().equals("Max"); // true
aDog.getName().equals("Fifi"); // false
aDog == oldDog; // true
}
public static void foo(Dog d) {
d.getName().equals("Max"); // true
// change d inside of foo() to point to a new Dog instance "Fifi"
d = new Dog("Fifi");
d.getName().equals("Fifi"); // true
}
In the example above aDog.getName()
will still return "Max"
. The value aDog
within main
is not changed in the function foo
with the Dog
"Fifi"
as the object reference is passed by value. If it were passed by reference, then the aDog.getName()
in main
would return "Fifi"
after the call to foo
.
Likewise:
public static void main(String[] args) {
Dog aDog = new Dog("Max");
Dog oldDog = aDog;
foo(aDog);
// when foo(...) returns, the name of the dog has been changed to "Fifi"
aDog.getName().equals("Fifi"); // true
// but it is still the same dog:
aDog == oldDog; // true
}
public static void foo(Dog d) {
d.getName().equals("Max"); // true
// this changes the name of d to be "Fifi"
d.setName("Fifi");
}
In the above example, Fifi
is the dog's name after call to foo(aDog)
because the object's name was set inside of foo(...)
. Any operations that foo
performs on d
are such that, for all practical purposes, they are performed on aDog
, but it is not possible to change the value of the variable aDog
itself.
For more information on pass by reference and pass by value, consult the following SO answer: https://stackoverflow.com/a/430958/6005228. This explains more thoroughly the semantics and history behind the two and also explains why Java and many other modern languages appear to do both in certain cases.
Best Answer
Full disclosure, I work on the team that write the Java tooling for TFS so take this answer as appropriately biased :-)
As far as TFS is concerned - all code is created equal. It's just bytes in files that it checks in to version control. Like all SCM systems it doesn't care what language the files are written in.
Microsoft provide a full, rich TFS Plug-in for Eclipse (called Team Explorer Everywhere). This provides full source control, work item tracking, build, sharepoint, reports access etc into TFS from Eclipse based IDE's. It's written in 100% Java and talks directly to the web services exposed by TFS.
In addition we also provide a cross-platform command line client for TFS so that you can talk to TFS from the command line on your operating system of choice (Mac, Linux, Solaris, HP-UX, Aix etc all fully supported).
Finally, if you have tools written in Java that want to talk to TFS then they can make use of the TFS SDK for Java which is the full API that we used to create the Eclipse integration and cross-platform command line client but packaged up with samples and snippets and ready for you to redistribute with your applications.
When it comes to build you have a couple of choices. If you want to stick with your current build server then it is likely that this already supports talking to TFS (all the popular open source build servers do). In addition to that, Microsoft provide the TFS Build Extensions which allow you to run Ant or Maven based builds on the Team Foundation Build server. The build results (along with any warnings or errors) are published back into TFS along with any JUnit test data if you execute JUnit tests as part of your build. Also you get to create and manage the build definitions in the Eclipse IDE and have one place to manage access to them etc.
So - the level of support for Java is very high and Microsoft has shown consistent investment in this area. We recently shipped some TFS 2010 Power Tools for Eclipse and we've also been shipping preview releases of Team Explorer Everywhere 11 alongside Team Foundation Server 11 (we're the same team inside the company).
To import history from SVN, that's the same as importing history from any SCM tool into TFS (or TFS into any SCM tool). You have a couple of options. You can take a snapshot and cut over at a particular point (such as a release) or you can migrate history. To Migrate history from SVN there are some partner solutions available including one from Timely Migration that I've seen a lot of customers have success with.
Hope that helps.