What is Scala?

Scala is a modern, statically-typed language
designed to run on the Java platform. It's commonly perceived as an "evolutionary
Java" and with good reason: Scala adds powerful features while significantly reducing
Java's verbosity. It is a highly practical language in that it offers a very straightforward
migration path for developers on existing platforms: Java developers will feel right
at home with Scala, and a .NET developers will not have to give up on a lot of the
advantages C# has over Java.

For organizations with a preexisting codebase Scala offers an excellent balance between
power and feature set, as well as perfect interoperability with existing Java code:
although you certainly don't have to, you can freely use familiar libraries
without a hitch, call into existing code and, for the most part, use your existing
tool-chain with little or no impact.

Why did we pick Scala?

As mentioned above, Scala offers a very compelling migration path from an existing
Java codebase. When we were setting up the new R&D center at newBrandAnalytics,
we were already serving paying customers via a complex codebase. A complete rewrite
was out of the question as we had contractual obligations, and we had to keep improving
the existing product in order to maintain the competitive edge; it became very clear
that we needed to maintain the existing codebase and refactor it incrementally.

An additional data point was that our core team members were highly experienced with
Java development and quite comfortable with the platform; we also had a distinct preference
for statically typed languages, which ruled several alternatives (particularly Clojure)
right out. Scala seemed like a great compromise in that it allowed us to maintain
and extend the existing codebase while enjoying advanced language features and improved
veracity at little or no risk to the product itself.

How should I "sell" Scala to my boss?

"Safe" choice with proven track record: Scala is not an entirely
new language, and has reached a maturity tipping point at 2.8; over the last two years
the language has been gaining significant momentum, and has a number of strong advocates
and success stories, including Twitter, Foursquare, LinkedIn and a whole
host of others.

Scala as a better Java: You don't have to go all-in on Scala's advanced
feature set, but can instead think of Scala as an improved Java with type inference,
closures, advanced collection framework, traits and pattern matching; these features
alone will increase your developers' happiness by an order of magnitude, and productivity
will see a corresponding improvement.

Less code ⇒ less bugs: Scala code is far more concise than corresponding
Java code, an helps the developer focus on the "what" instead of the "how". The resulting
code is usually much shorter, clearer and simpler, which in turn helps lower bug count.

Helps hire better engineers: Great engineers not only love working
with the latest technologies, but also love practical, incremental improvements to
well-respected technologies. Merely saying "we use Scala" will help attract the sort
of seasoned, reliable and professional engineers that you most want to hire.

Where does Scala put you at risk?

Learning curve: Although Scala largely derives from Java, it's a
whole new language with a lot of features that takes time to master. Don't expect
your developers to be productive from day one; instead, provide opportunities for
experimentation and encourage iterative development (and yes, give your developers
time and mandate to throw away badly written early code and redo their work if necessary).
There is actually a lot of material on Scala and an active and vibrant community;
specifically, your developers can easily find help (and answers) on StackOverflow.

Rough edges: Scala is fairly new, and consequently a lot of things
that you take for granted with Java are not as mature or robust with Scala. IDE support
is a moving target: Eclipse and IntelliJ IDEA both have actively developed Scala plugins
and both have occasional issues (spurious error highlighting, lackluster performance,
wonky debuggers). The common build tools support Scala, but don't play as nicely;
for example, only the native build tool (sbt) support incremental compilation. Even
the compiler itself is not entirely bug-free, although these are getting very rare
indeed. Bottom line: expect occasional problems, and be patient while working around
them; even better, encourage your engineers to participate in the community,
file bugs and even offer patches where possible.

Production characteristics: While it runs on the JVM, Scala is not Java;
there are subtle differences that you should be aware of when maintaining large-scale
or highly-available software. Scala generates a great deal of synthetic code, which
puts additional pressure on the PermGen space; synthetic stack frames may also exhibit
significantly increased stack usage. Scala also creates a lot of intermediate objects
at runtime, which results in added eden generation churn. You may want to profile
your applications and tune the GC accordingly.

What's the bottom line?

Scala is fantastic. Our team at newBrandAnalytics is remarkably happier with Scala
despite the occasional hitches, and I doubt any of us will consider going back to
Java given the option. As long as you keep in mind that on the bleeding edge you
may get cut, I definitely recommend taking the plunge, with contractors and die-hard
traditional enterprises the possible exceptions.

Scala In Practice: A Case Studyhttp://www.tomergabel.com/PermaLink,guid,b8d6056d-cdf8-49a7-ac8c-d4424a965720.aspxhttp://www.tomergabel.com/ScalaInPracticeACaseStudy.aspx
Thu, 02 Aug 2012 07:20:42 GMT<p>
This post attempts to summarize and clarify a lecture given at the <a href="https://www.facebook.com/botzia">Botzia</a> (Israeli
Java user group) meeting on May 3rd, 2012. You can view the presentation in its entirety
on SlideShare:
</p>
<p style="text-align: center;">
<iframe src="http://www.slideshare.net/slideshow/embed_code/12803578" style="border: 1px solid #CCC; border-width: 1px 1px 0; margin-bottom: 5px;" width="512" height="421" scrolling="no" marginwidth="0" marginheight="0" frameborder="0">
</iframe>
</p>
<div style="margin-bottom: 5px; text-align: center;"><strong> <a title="Scala in practice" href="http://www.slideshare.net/holograph/scala-in-practice-12803578" target="_blank">Scala
in practice</a> </strong> from <strong><a href="http://www.slideshare.net/holograph" target="_blank">Tomer
Gabel</a></strong>
</div>
<h3>What is Scala?
</h3>
<p>
<a href="http://www.scala-lang.org/">Scala</a> is a modern, statically-typed language
designed to run on the Java platform. It's commonly perceived as an "evolutionary
Java" and with good reason: Scala adds powerful features while significantly reducing
Java's verbosity. It is a highly practical language in that it offers a very straightforward
migration path for developers on existing platforms: Java developers will feel right
at home with Scala, and a .NET developers will not have to give up on a lot of the
advantages C# has over Java.
</p>
<p>
For organizations with a preexisting codebase Scala offers an excellent balance between
power and feature set, as well as perfect interoperability with existing Java code:
although you certainly don't <em>have </em>to, you can freely use familiar libraries
without a hitch, call into existing code and, for the most part, use your existing
tool-chain with little or no impact.
</p>
<h3>Why did we pick Scala?
</h3>
<p>
As mentioned above, Scala offers a very compelling migration path from an existing
Java codebase. When we were setting up the new R&amp;D center at <a href="http://www.newbrandanalytics.com">newBrandAnalytics</a>,
we were already serving paying customers via a complex codebase. A complete rewrite
was out of the question as we had contractual obligations, and we had to keep improving
the existing product in order to maintain the competitive edge; it became very clear
that we needed to maintain the existing codebase and refactor it incrementally.
</p>
<p>
An additional data point was that our core team members were highly experienced with
Java development and quite comfortable with the platform; we also had a distinct preference
for statically typed languages, which ruled several alternatives (particularly Clojure)
right out. Scala seemed like a great compromise in that it allowed us to maintain
and extend the existing codebase while enjoying advanced language features and improved
veracity at little or no risk to the product itself.
</p>
<h3>How should I "sell" Scala to my boss?
</h3>
<p>
<strong>"Safe" choice with proven track record: </strong>Scala is not an entirely
new language, and has reached a maturity tipping point at 2.8; over the last two years
the language has been gaining significant momentum, and has a number of strong advocates
and success stories, including Twitter, Foursquare, LinkedIn and a <a href="http://www.quora.com/Startups/What-startups-or-tech-companies-are-using-Scala">whole
host of others</a>.
</p>
<p>
<strong>Scala as a better Java:</strong> You don't have to go all-in on Scala's advanced
feature set, but can instead think of Scala as an improved Java with type inference,
closures, advanced collection framework, traits and pattern matching; these features
alone will increase your developers' happiness by an order of magnitude, and productivity
will see a corresponding improvement.
</p>
<p>
<strong>Less code ⇒ less bugs</strong>: Scala code is far more concise than corresponding
Java code, an helps the developer focus on the "what" instead of the "how". The resulting
code is usually much shorter, clearer and simpler, which in turn helps lower bug count.
</p>
<p>
<strong>Helps hire better engineers:</strong> Great engineers not only love working
with the latest technologies, but also love practical, incremental improvements to
well-respected technologies. Merely saying "we use Scala" will help attract the sort
of seasoned, reliable and professional engineers that you most want to hire.
</p>
<h3>Where does Scala put you at risk?
</h3>
<p>
<strong>Learning curve:</strong> Although Scala largely derives from Java, it's a
whole new language with a lot of features that takes time to master. Don't expect
your developers to be productive from day one; instead, provide opportunities for
experimentation and encourage iterative development (and yes, give your developers
time and mandate to throw away badly written early code and redo their work if necessary).
There is actually a lot of material on Scala and an active and vibrant community;
specifically, your developers can easily find help (and answers) on <a href="http://www.stackoverflow.com">StackOverflow</a>.
</p>
<p>
<strong>Rough edges: </strong>Scala is fairly new, and consequently a lot of things
that you take for granted with Java are not as mature or robust with Scala. IDE support
is a moving target: Eclipse and IntelliJ IDEA both have actively developed Scala plugins
and both have occasional issues (spurious error highlighting, lackluster performance,
wonky debuggers). The common build tools support Scala, but don't play as nicely;
for example, only the native build tool (sbt) support incremental compilation. Even
the compiler itself is not entirely bug-free, although these are getting very rare
indeed. Bottom line: expect occasional problems, and be patient while working around
them; even better, <strong>encourage your engineers to participate in the community</strong>,
file bugs and even offer patches where possible.
</p>
<p>
<strong>Production characteristics:</strong> While it runs on the JVM, Scala is <em>not</em> Java;
there are subtle differences that you should be aware of when maintaining large-scale
or highly-available software. Scala generates a great deal of synthetic code, which
puts additional pressure on the PermGen space; synthetic stack frames may also exhibit
significantly increased stack usage. Scala also creates a lot of intermediate objects
at runtime, which results in added eden generation churn. You may want to profile
your applications and tune the GC accordingly.
</p>
<h3>What's the bottom line?
</h3>
<p>
<img style="display: block; margin-left: auto; margin-right: auto;" title="codebase-evolution.png" src="http://www.tomergabel.com/content/binary/codebase-evolution.png" alt="Codebase evolution" width="600" height="450" border="0" />
</p>
<p>
Scala is fantastic. Our team at newBrandAnalytics is remarkably happier with Scala
despite the occasional hitches, and I doubt any of us will consider going back to
Java given the option. As long as you keep in mind that <em>on the bleeding edge you
may get cut</em>, I definitely recommend taking the plunge, with contractors and die-hard
traditional enterprises the possible exceptions.
</p>
<img width="0" height="0" src="http://www.tomergabel.com/aggbug.ashx?id=b8d6056d-cdf8-49a7-ac8c-d4424a965720" />DevelopmentDevelopment/Javahttp://www.tomergabel.com/Trackback.aspx?guid=b849579e-4637-4051-ba21-f87975905ca0http://www.tomergabel.com/pingback.aspxhttp://www.tomergabel.com/PermaLink,guid,b849579e-4637-4051-ba21-f87975905ca0.aspxTomer Gabel

A great but oft-ignored feature of Visual Studio 2005 and up is the inherent consolidation
of an important developer tool: the build system. With a Visual Studio solution you
can simply run MSBuild and you get accurate, automated builds. This is an invaluable
capability: continuous integration is ridiculously easy to set up, as are nightly
builds and automated deployment tools.

Since I started working for Delver (now
Sears) I’ve been switching back and forth between C# (2.0 and later 3.0) and Java
1.6, and though the ecosystems share many similarities there are also several glaring
differences. The first of these differences is that, in the Java world, it is perfectly
acceptable – even traditional – to maintain a dual project structure, one using the
IDE (usually Eclipse or IntelliJ IDEA) and one using one of the build tools (commonly
Ant or Maven). The build scripts need to be continuously synchronized with the project
structure, and output parity between the two separate build systems is almost unheard-of.

Because I had been a complete Java newbie when I started, I had never had the time
to really sit down and set up a continuous integration server for our Java codebase,
a mistake I did not intent to repeat when Sears took over. The first item on my agenda
was to do away with the dual project structure; we originally used Eclipse, so I built
a custom Ant script (my first, actually) around ant4eclipse and
managed to come up with a semi-satisfactory solution. This also gave us invaluable
insight when it was time to revisit our IDE choice; the lackluster project structure
offered by Eclipse, along with firm positive comments on IntelliJ IDEA from several
team members, tipped the balance and led us to switch to the alternative IDE, while
also creating the necessity for a revamped build system can that work on top of the
IntelliJ IDEA project structure.

Out of necessity, a project was born. ant-intellij-tasks is
the result of several months of all-night itch-scratching on my part. While not directly
affiliated with the company, we’ve been dogfooding the project at Sears for over a
month now, and while there are certainly rough edges it finally seems stable enough
for release! From the project website:

ant-intellij-tasks is a
self-contained build system for IntelliJ IDEA projects based around Apache
Ant. In essence, ant-intellij-tasks comprises three components:

An Ant task library that can extract and resolve the IntelliJ IDEA project and module
files (.ipr and .iml respectively), and provides a set of tasks and conditions around
the project structure;

A common build script which provides the four major build targets for modules: clean,
build, test and package (see the
quickstart guide);

A master build script which extends these targets to the entire project.

The build system is designed to be extensible (e.g. by adding targets), customizable
(e.g. by overriding a target's behavior for a specific module) and self contained
in that it's a drop-in solution that should not require any significant modifications
to the code base.

This project is fully open source (distributed under an Apache license) and hosted
at Google Code. Please report any bugs or issues on the project issue
tracker.

ant-intellij-tasks makes use of, and redistributes, the ant-contrib task
library.

Announcing ant-intellij-taskshttp://www.tomergabel.com/PermaLink,guid,b849579e-4637-4051-ba21-f87975905ca0.aspxhttp://www.tomergabel.com/AnnouncingAntintellijtasks.aspx
Wed, 30 Sep 2009 06:18:58 GMT<p>
<em>Download </em><a href="http://ant-intellij-tasks.googlecode.com/files/ant-intellij-tasks-1.0-b1.zip"><em>ant-intellij-tasks-1.0-b1.zip</em></a><em> </em>
</p>
<p>
A great but oft-ignored feature of Visual Studio 2005 and up is the inherent consolidation
of an important developer tool: the build system. With a Visual Studio solution you
can simply run MSBuild and you get accurate, automated builds. This is an invaluable
capability: continuous integration is ridiculously easy to set up, as are nightly
builds and automated deployment tools.
</p>
<p>
Since I started working for Delver (<a href="http://www.tomergabel.com/LifeIsFullOfSurprises.aspx">now
Sears</a>) I’ve been switching back and forth between C# (2.0 and later 3.0) and Java
1.6, and though the ecosystems share many similarities there are also several glaring
differences. The first of these differences is that, in the Java world, it is perfectly
acceptable – even traditional – to maintain a dual project structure, one using the
IDE (usually Eclipse or IntelliJ IDEA) and one using one of the build tools (commonly
Ant or Maven). The build scripts need to be continuously synchronized with the project
structure, and output parity between the two separate build systems is almost unheard-of.
</p>
<p>
Because I had been a complete Java newbie when I started, I had never had the time
to really sit down and set up a continuous integration server for our Java codebase,
a mistake I did not intent to repeat when Sears took over. The first item on my agenda
was to do away with the dual project structure; we originally used Eclipse, so I built
a custom Ant script (my first, actually) around <a href="http://ant4eclipse.sourceforge.net/">ant4eclipse</a> and
managed to come up with a semi-satisfactory solution. This also gave us invaluable
insight when it was time to revisit our IDE choice; the lackluster project structure
offered by Eclipse, along with firm positive comments on IntelliJ IDEA from several
team members, tipped the balance and led us to switch to the alternative IDE, while
also creating the necessity for a revamped build system can that work on top of the
IntelliJ IDEA project structure.
</p>
<p>
Out of necessity, a project was born. <a href="http://code.google.com/p/ant-intellij-tasks/">ant-intellij-tasks</a> is
the result of several months of all-night itch-scratching on my part. While not directly
affiliated with the company, we’ve been dogfooding the project at Sears for over a
month now, and while there are certainly rough edges it finally seems stable enough
for release! From the project website:
</p>
<blockquote style="padding-bottom: 5px; padding-left: 5px; padding-right: 5px; background: #ccc; padding-top: 5px">
<p>
<a href="http://code.google.com/p/ant-intellij-tasks">ant-intellij-tasks</a> is a
self-contained build system for IntelliJ IDEA projects based around ><a href="http://ant.apache.org/">Apache
Ant</a>. In essence, ant-intellij-tasks comprises three components:
<ol>
<li>
An Ant task library that can extract and resolve the IntelliJ IDEA project and module
files (.ipr and .iml respectively), and provides a set of tasks and conditions around
the project structure;
<li>
A common build script which provides the four major build targets for modules: clean,
build, test and package (see <a href="http://code.google.com/p/ant-intellij-tasks/#Quickstart_Guide">the
quickstart guide</a>);
<li>
A master build script which extends these targets to the entire project.
</li>
</ol>
<p>
The build system is designed to be extensible (e.g. by adding targets), customizable
(e.g. by overriding a target's behavior for a specific module) and self contained
in that it's a drop-in solution that should not require any significant modifications
to the code base.
<p>
<p>
This project is fully open source (distributed under an Apache license) and hosted
at Google Code. Please report any bugs or issues on the project <a href="http://code.google.com/p/ant-intellij-tasks/issues/list">issue
tracker</a>.
<p>
<p>
ant-intellij-tasks makes use of, and redistributes, the <a href="http://ant-contrib.sourceforge.net/">ant-contrib</a> task
library.
</p>
</blockquote><img width="0" height="0" src="http://www.tomergabel.com/aggbug.ashx?id=b849579e-4637-4051-ba21-f87975905ca0" />DevelopmentDevelopment/JavaSoftwareant-intellij-taskshttp://www.tomergabel.com/Trackback.aspx?guid=6a6c2dc7-df2a-4bec-8a2b-0e7d1e652d3fhttp://www.tomergabel.com/pingback.aspxhttp://www.tomergabel.com/PermaLink,guid,6a6c2dc7-df2a-4bec-8a2b-0e7d1e652d3f.aspxTomer Gabel

Apparently Java has quite a few known but practically undocumented issues with its
handling of UNC paths under Windows. I’ve specifically encountered this
bug albeit in a slightly different scenario:

Apparently the two slashes after file: are misinterpreted as the authority part of
the URI; this
thread on StackOverflow may give a few starting points if want to delve deeper.
It seems Java implements an older RFC for URIs which has slightly different tokenization
rules.

At any rate, so far the only sensible solution I’ve managed to come with is to
manually remove or add (depending on your tastes…) a slash:

Because the Java language lacks delegates, anonymous classes are prevalent as a syntactic
replacement. Non-static nested classes are also often used in the language, a feature
which is conspicuously absent from C#, albeit far less necessary with that language.

This brings me to the following language caveat. This may seem a contrived example,
but it's a simplification of an actual issue I've encountered in the last few days.
Suppose you have a generic base class, call it BaseClass<U>, which
you extend with an anonymous class. Lets also assume that the extended class spawns
a thread that needs to access the BaseClass<U> state:

I'll spare you the guessing game. Here's what happens with each of the five invocations
of getState():

Compiles and behaves as expected.

Obviously won't compile; this points to the Runnable.

Obviously won't compile; the superclass of a Runnable is Object.

Although this is the correct raw class, it won't compile because "No enclosing
instance of the type BaseClass<U> is accessible in scope", even though
the raw type should still be accessible and U can be inferred.

Although this appears to be the correct fully-qualified form, this does not compile
with a "Syntax error on token(s), misplaced construct(s)" error.

The Java language specification section on "qualified this"
is very brief and does not mention generics at all (does "class name" include bounded
type parameters?). Oddly enough, moving the class declaration outside of the test
method actually lets 4 compile -- if there's a clue there, I haven't figured it out
yet.

I still haven't found a syntactically-correct way to access BaseClass<string>.this,
other than placing it in a temporary variable outside of the Runnable declaration.
I searched yesterday for a couple of hours with no obvious solution in sight. Ideas
are more than welcome!...

Java &quot;qualified this&quot; with generic enclosing typeshttp://www.tomergabel.com/PermaLink,guid,eae0e740-85ac-40ce-b924-2c126bfa7471.aspxhttp://www.tomergabel.com/JavaQuotqualifiedThisquotWithGenericEnclosingTypes.aspx
Tue, 22 Jul 2008 08:27:45 GMT<p>
Because the Java language lacks delegates, anonymous classes are prevalent as a syntactic
replacement. Non-static nested classes are also often used in the language, a feature
which is conspicuously absent from C#, albeit far less necessary with that language.
</p>
<p>
This brings me to the following language caveat. This may seem a contrived example,
but it's a simplification of an actual issue I've encountered in the last few days.
Suppose you have a generic base class, call it <tt>BaseClass&lt;U&gt;</tt>, which
you extend with an anonymous class. Lets also assume that the extended class spawns
a thread that needs to access the <tt>BaseClass&lt;U&gt;</tt> state:
</p>
<blockquote><pre><span style="color: #0000ff">class</span> BaseClass&lt;U&gt; { <span style="color: #0000ff">void</span> getState()
{} } <span style="color: #0000ff">class</span> Test { <span style="color: #0000ff">public</span> <span style="color: #0000ff">void</span> test()
{ <span style="color: #0000ff">final</span> BaseClass&lt;String&gt; instance = <span style="color: #0000ff">new</span> BaseClass&lt;String&gt;()
{ <span style="color: #0000ff">public</span> <span style="color: #0000ff">void</span> invokeStatefulThread()
{ <span style="color: #008000">// Create our runnable</span> <span style="color: #0000ff">final</span> Runnable
threadCode = <span style="color: #0000ff">new</span> Runnable() { <span style="color: #0000ff">public</span> <span style="color: #0000ff">void</span> run()
{ <span style="color: #008000">/* 1 */</span> getState(); <span style="color: #008000">/*
2 */</span> <span style="color: #0000ff">this</span>.getState(); <span style="color: #008000">/*
3 */</span> <span style="color: #0000ff">super</span>.getState(); <span style="color: #008000">/*
4 */</span> BaseClass.<span style="color: #0000ff">this</span>.getState(); <span style="color: #008000">/*
5 */</span> BaseClass&lt;String&gt;.<span style="color: #0000ff">this</span>.getState();
} }; <span style="color: #0000ff">new</span> Thread( threadCode ).start(); } }; instance.invokeStatefulThread();
} }</pre></blockquote>
<p>
I'll spare you the guessing game. Here's what happens with each of the five invocations
of <tt>getState()</tt>:
</p>
<ol>
<li>
Compiles and behaves as expected.
<li>
Obviously won't compile; <tt>this</tt> points to the <tt>Runnable</tt>.
<li>
Obviously won't compile; the superclass of a <tt>Runnable</tt> is <tt>Object</tt>.
<li>
Although this is the correct raw class, it won't compile because <tt>"No enclosing
instance of the type BaseClass&lt;U&gt; is accessible in scope"</tt>, even though
the raw type should still be accessible and <tt>U</tt> can be inferred.
<li>
Although this appears to be the correct fully-qualified form, this does not compile
with a <tt>"Syntax error on token(s), misplaced construct(s)"</tt> error.</li>
</ol>
<p>
The Java language specification section on "<a href="http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.8.4">qualified <tt>this</tt></a>"
is very brief and does not mention generics at all (does "class name" include bounded
type parameters?). Oddly enough, moving the class declaration outside of the test
method actually lets 4 compile -- if there's a clue there, I haven't figured it out
yet.
</p>
<p>
I still haven't found a syntactically-correct way to access <tt>BaseClass&lt;string&gt;.this</tt>,
other than placing it in a temporary variable outside of the <tt>Runnable</tt> declaration.
I searched yesterday for a couple of hours with no obvious solution in sight. Ideas
are more than welcome!...
</p>
<img width="0" height="0" src="http://www.tomergabel.com/aggbug.ashx?id=eae0e740-85ac-40ce-b924-2c126bfa7471" />DevelopmentDevelopment/Javahttp://www.tomergabel.com/Trackback.aspx?guid=b657662e-31b1-4eb3-bfd4-2557b2ff78b0http://www.tomergabel.com/pingback.aspxhttp://www.tomergabel.com/PermaLink,guid,b657662e-31b1-4eb3-bfd4-2557b2ff78b0.aspxTomer Gabel

The Java implementation for generics is radically different from the C# equivalent;
I won't reiterate issues that have been thoroughly
discussed before, but suffice to say that Java generics are implemented as a backwards-compatible
compiler extension that works on unmodified VMs.

The implications of this are considerable, and I'd like to present one of them. Lets
fast forward a bit and consider a relatively new language feature in Java (introduced,
I believe, with J2SE 5.0): autoboxing. A thoroughly overdue language feature, autoboxing
allows the seamless transition from regular value types (e.g. the ubiquitous int)
to object references (Integer); before autoboxing you
couldn't simply add a value to an untyped ArrayList, you had to box (wrap) it in a
reference type:

As a long-time C# programmer I was completely befuddled when the code resulted in
a NullPointerException. Huh? Exception? What? Why?

It took me a while to figure it out: because Java generics are compile-time constructs
and are not directly supported by the VM, what actually happens is that the underlying
container class accepts regular Object instances (reference
types); the compile-time check merely asserts that n can
be promoted from short to int,
whereas the actual object passed to the container class (via autoboxing) is a Short!
Since the container doesn't doesn't actually have a runtime generic type per
se, the collection merely looks up the reference object in the map, fails to find
it (I guess the Object.hashCode implementation for value
types simply returns the reference value as the hash code as in C#) and returns null.
Doh! *slaps forehead*

Java language caveat: autoboxing and genericshttp://www.tomergabel.com/PermaLink,guid,b657662e-31b1-4eb3-bfd4-2557b2ff78b0.aspxhttp://www.tomergabel.com/JavaLanguageCaveatAutoboxingAndGenerics.aspx
Sun, 06 Jan 2008 17:15:54 GMT<p>
The Java implementation for generics is radically different from the C# equivalent;
I won't reiterate issues that have been <a href="http://www.itu.dk/courses/PFOO/F2006/diku-javacsharpgenerics.pdf">thoroughly
discussed before</a>, but suffice to say that Java generics are implemented as a backwards-compatible
compiler extension that works on unmodified VMs.
</p>
<p>
The implications of this are considerable, and I'd like to present one of them. Lets
fast forward a bit and consider a relatively new language feature in Java (introduced,
I believe, with J2SE 5.0): autoboxing. A thoroughly overdue language feature, autoboxing
allows the seamless transition from regular value types (e.g. the ubiquitous <span class="codetext">int</span>)
to object references (<span class="codetext">Integer</span>); before autoboxing you
couldn't simply add a value to an untyped ArrayList, you had to box (wrap) it in a
reference type:
</p>
<blockquote><pre>ArrayList list = <span style="color: #0000ff">new</span> ArrayList();
list.add( 3 ); <span style="color: #008000">// Compile-time error</span> list.add( <span style="color: #0000ff">new</span> Integer(
3 ) ); <span style="color: #008000">// OK</span></pre></blockquote>
<p>
Eventually Java caught up with C# (which introduced autoboxing in 2002), and with
a modern compiler the above code would be valid.
</p>
<p>
With the introductions out of the way, here's a pop-quiz: what does the following
code print?
</p>
<blockquote><pre>HashMap&lt;Integer, Integer&gt; map = <span style="color: #0000ff">new</span> HashMap&lt;Integer,
Integer&gt;(); map.put( 4, 2 ); <span style="color: #0000ff">short</span> n = 4; System.out.println(
Integer.toString( map.get( n ) ) );</pre></blockquote>
<p>
As a long-time C# programmer I was completely befuddled when the code resulted in
a <span class="codetext">NullPointerException</span>. Huh? Exception? What? Why?
</p>
<p>
It took me a while to figure it out: because Java generics are compile-time constructs
and are not directly supported by the VM, what actually happens is that the underlying
container class accepts regular <span class="codetext">Object</span> instances (reference
types); the compile-time check merely asserts that <span class="codetext">n</span> can
be promoted from <span class="codetext">short</span> to <span class="codetext">int</span>,
whereas the actual object passed to the container class (via autoboxing) is a <span class="codetext">Short</span>!
Since the container doesn't doesn't actually have a runtime generic <em>type</em> per
se, the collection merely looks up the reference object in the map, fails to find
it (I guess the <span class="codetext">Object.hashCode</span> implementation for value
types simply returns the reference value as the hash code as in C#) and returns <span class="codetext">null</span>.
Doh! <b>*slaps forehead*</b>
</p>
<img width="0" height="0" src="http://www.tomergabel.com/aggbug.ashx?id=b657662e-31b1-4eb3-bfd4-2557b2ff78b0" />DevelopmentDevelopment/Javahttp://www.tomergabel.com/Trackback.aspx?guid=08ee53ca-6d1a-4406-a7c4-579f6414db2ahttp://www.tomergabel.com/pingback.aspxhttp://www.tomergabel.com/PermaLink,guid,08ee53ca-6d1a-4406-a7c4-579f6414db2a.aspxTomer Gabel

So you want a web project, a build system and a reasonable IDE to take care of the
annoying details for you, right? The good news are that it's actually quite possible
and there're many ways to do this. The bad news are that it's nigh impossible to get
them to play along if you don't already know how to do that. It took me days to find
a solution that finally seems to work, and I'd like to share it with you. I'm probably
missing a few important details or did something really really stupid along the way
(I'd appreciate comments!), but this process does seem to work. I'm not going
into essentials of Java-based web development here -- if you want a more
basic explanation of the terminology, post a comment and I'll see what I can do...

1. Goal

I want to:

Use a common, standard and powerful IDE to edit and debug my Java code, and preferably
provide a usable GUI interface for dependency and project management;

Use a common, standard servlet container to host my servlet and still be able to control
and debug everything from the same IDE;

Have a convenient way to handle internal-and-external dependencies without worrying
too much about the details;

Be able to quickly compile, test and package my servlet for deployment;

Understand as little as possible about the dependency stack of the tools
involved

I'm going to tell you how to achieve most of these goals, with two glaring omissions:
I won't show you how to do testing (I haven't successfully managed servlet unit testing
so far -- different post on that) and I can't help but delve into some of the more
annoying details involved with these tools and their dependencies. Sorry about that.
Additionally, some of the information here applies even if you use different tools,
but you're bound to face issues not covered here; don't assume I know more than you
do -- seek the answers, post them somewhere, and maybe the next person will actually
find what they're looking for!

Web Tools Platform: this is the Eclipse
plug-in that adds web development capabilities to the IDE, including J2EE dependency
management, hosting and running servlets from within the Eclipse workspace etc. This
would be a good time to run along to the WTP
web-site and download the Web Tools Platform All-In-One package. I only used the
release version (2.0.1 at the time of writing this), so if you use another version
your mileage may vary;

Apache Maven is the newfangled build system
from Apache slated to replace ant. I've used
it for the last few days and so far it appears to be quite robust and even fairly
well-integrated into Eclipse (see next item). Version used: 2.0.8;

M2eclipse is the Eclipse plug-in for
Maven integration. I've only found one problem with it so far, which I'll detail later
on;

Apache Tomcat is a solid choice in servlet
containers. It's robust, fast and open-source, and has terrific Eclipse integration.
I haven't given any of the other containers a serious whirl yet though.

Add whichever J2EE libraries you desire from the Tomcat installation to your class-path.
If you have no idea what I'm talking about, you'll probably just want to set the CLASSPATH environment
variable to your equivalent of c:\tools\apache-tomcat-6.0.14\lib\servlet-api.jar;c:\tools\apache-tomcat-6.0.14\lib\jsp-api.jar

At this point you may encounter a "Java compiler level does not match the version
of the installed Java project facet" error. If that's the case, just right-click on
the error (in the Problems view) and select Quick Fix, which will allow you to change
the Java project facet version to 6.0. If this isn't what you want, you probably know
enough to resolve the issue on your own...

You'll need a src/main/java directory as a root source
folder (as per the Maven
convention). Right-click on the project, select New->Source Folder and type
in src/main/java.

Finally, in order to execute or debug the project on an actual running server, right-click
on the new project and select Properties. From there go to the Server tab and select
the runtime you created in the previous chapter.

At this point you have a Maven web project with a corresponding Eclipse project ready
for editing in your workspace. In practice you will have to do several things to have
any meaningful results.

Add your own code into the mix, such as a servlet. When adding a new servlet (via
right-clicking the project, New->Other and choosing Web->Servlet) your WEB.XML file
is automatically updated with the new servlet.

Add your own dependencies. Maven handles dependencies quite well; for instance, in
order to actually create a servlet you're going to need servlet-api.jar in
your classpath; the easiest way to do this is to right-click the project, select Maven->Add
Dependency and then simply type in servlet and choose javax.servlet
servlet-api.

When you wish to run or debug your servlet, right-click on its Java file and select
Run As->Run on Server (or Debug, as appropriate). Your applet should be happily
up and running.

5. Converting an existing project to Maven

I'm not sure how to go about doing this for web projects, but converting regular projects
to use Maven is actually pretty straightforward; move your sources to the appropriate
directories according to the Maven
conventions, right-click the project in Eclipse and choose Maven->Enable Dependency
Management; this will implicitly create a Maven project descriptor for you (POM.XML)
and that's pretty much it. From that point on your Eclipse and Maven projects should
peacefully coexist, allowing you to leverage both tools for your purposes.

Beginner's Guide to Web Development (or, Getting Eclipse, WTP, Tomcat and Maven to play along)http://www.tomergabel.com/PermaLink,guid,08ee53ca-6d1a-4406-a7c4-579f6414db2a.aspxhttp://www.tomergabel.com/BeginnersGuideToWebDevelopmentOrGettingEclipseWTPTomcatAndMavenToPlayAlong.aspx
Wed, 05 Dec 2007 13:10:05 GMT<p>
So you want a web project, a build system and a reasonable IDE to take care of the
annoying details for you, right? The good news are that it's actually quite possible
and there're many ways to do this. The bad news are that it's nigh impossible to get
them to play along if you don't already know how to do that. It took me days to find
a solution that finally seems to work, and I'd like to share it with you. I'm probably
missing a few important details or did something really really stupid along the way
(I'd appreciate comments!), but this process does seem to work. <strong>I'm not going
into essentials of Java-based web development here</strong> -- if you want a more
basic explanation of the terminology, post a comment and I'll see what I can do...
</p>
<p>
<u>1. Goal</u>
</p>
<p>
I want to:
</p>
<ul>
<li>
Use a common, standard and powerful IDE to edit and debug my Java code, and preferably
provide a usable GUI interface for dependency and project management;
<li>
Use a common, standard servlet container to host my servlet and still be able to control
and debug everything from the same IDE;
<li>
Have a convenient way to handle internal-and-external dependencies without worrying
too much about the details;
<li>
Be able to quickly compile, test and package my servlet for deployment;
<li>
<em><strong>Understand as little as possible about the dependency stack of the tools
involved</strong></em>
</li>
</ul>
<p>
I'm going to tell you how to achieve most of these goals, with two glaring omissions:
I won't show you how to do testing (I haven't successfully managed servlet unit testing
so far -- different post on that) and I can't help but delve into some of the more
annoying details involved with these tools and their dependencies. Sorry about that.
Additionally, some of the information here applies even if you use different tools,
but you're bound to face issues not covered here; don't assume I know more than you
do -- seek the answers, post them somewhere, and maybe the next person will actually
find what they're looking for!
</p>
<p>
<u>2. Tools</u>
</p>
<p>
The tools used are:
</p>
<ul>
<li>
<a href="http://java.sun.com/javase/downloads/index.jsp">J2SE JDK</a> is an obvious
must-have. Version used: JDK 6 update 3;
<li>
<a href="http://www.eclipse.org/">Eclipse</a> (but please don't download it just yet)
for code editing, debugging and project management;
<li>
<a href="http://www.eclipse.org/webtools/">Web Tools Platform</a>: this is the Eclipse
plug-in that adds web development capabilities to the IDE, including J2EE dependency
management, hosting and running servlets from within the Eclipse workspace etc. This
would be a good time to run along to the <a href="http://download.eclipse.org/webtools/downloads/">WTP
web-site</a> and download the Web Tools Platform All-In-One package. I only used the
release version (2.0.1 at the time of writing this), so if you use another version
your mileage may vary;
<li>
<a href="http://maven.apache.org/">Apache Maven</a> is the newfangled build system
from Apache slated to replace <a href="http://ant.apache.org/">ant</a>. I've used
it for the last few days and so far it appears to be quite robust and even fairly
well-integrated into Eclipse (see next item). Version used: 2.0.8;
<li>
<a href="http://m2eclipse.codehaus.org/">M2eclipse</a> is the Eclipse plug-in for
Maven integration. I've only found one problem with it so far, which I'll detail later
on;
<li>
<a href="http://tomcat.apache.org/">Apache Tomcat</a> is a solid choice in servlet
containers. It's robust, fast and open-source, and has terrific Eclipse integration.
I haven't given any of the other containers a serious whirl yet though.</li>
</ul>
<p>
<u>3. Preparations</u>
</p>
<p>
Unlike Visual Studio, with the tools mentioned above there's no straightforward installation
procedure. You'll have to designate at least a workspace directory (where your Eclipse
projects, settings etc. go) and some location where the tools themselves go. For me,
it's C:\Dev\Eclipse and C:\Tools respectively.
</p>
<ul>
<li>
Setting up Java:
<ul>
<li>
Install the JDK and remember where it was installed (nominally in <span class="codetext">%PROGRAMFILES%\Java\jdk1.6.0_03</span>)
<li>
Set up a system-wide <span class="codetext">JAVA_HOME</span> environment variable
pointing to the same directory</li>
</ul>
<li>
Setting up Maven and Tomcat:
<ul>
<li>
Extract both archives to your designated directory (e.g. for Maven it would be <span class="codetext">C:\Tools\apache-maven-2.0.8</span>)
<li>
Add the Maven bin directory to your <span class="codetext">PATH</span> environment
variable (user- or system-wide, depending on your preference)
<li>
Add whichever J2EE libraries you desire from the Tomcat installation to your class-path.
If you have no idea what I'm talking about, you'll probably just want to set the <span class="codetext">CLASSPATH</span> environment
variable to your equivalent of <span class="codetext">c:\tools\apache-tomcat-6.0.14\lib\servlet-api.jar;c:\tools\apache-tomcat-6.0.14\lib\jsp-api.jar</span>
</li>
</ul>
<li>
Setting up Eclipse:
<ul>
<li>
Extract the WTP all-in-one package (which contains Eclipse itself) to your designated
directory (e.g. <span class="codetext">C:\Tools\Eclipse</span>)
<li>
Load Eclipse and point it to your designated workspace location
<li>
Install M2Eclipse:
<ul>
<li>
Go to Help-&gt;Software Updates-&gt;Find and Install..., select "Search for new features
to install" and click Next
<li>
Click on New Remote Site..., use M2eclipse or whatever for the name and <a title="http://m2eclipse.codehaus.org/update/" href="http://m2eclipse.codehaus.org/update/">http://m2eclipse.codehaus.org/update/</a> for
the URL
<li>
Click on Finish and let Eclipse install the M2Eclipse plug-in</li>
</ul>
<li>
Set up a web server runtime for Eclipse to host your servlets in:
<ul>
<li>
Open Window-&gt;Preferences...
<li>
Under Server select Installed Runtimes and click on Add...
<li>
Choose (from Apache) the Apache Tomcat v6.0 runtime and click Next
<li>
Enter the Apache installation directory (e.g. <span class="codetext">C:\Tools\apache-tomcat-6.0.14</span>)
in the appropriate location and click Finish</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>
<u>4. Creating a new web project</u>
</p>
<p>
First off, you must create the actual project, directory structure etc. To do this:
</p>
<ul>
<li>
Open a command prompt, go to your Eclipse workspace directory
<li>
Decide on your Maven group and artifact IDs; it's worth noting that the artifact ID
is also the directory name for the project
<li>
Type in <span class="codetext">mvn archetype:create -DgroupId=<strong>your.group.id</strong> -DartifactId=<strong>your.artifact.id</strong> -DarchetypeArtifactId=maven-archetype-webapp </span>
<li>
You'll notice that a new directory was created under the workspace root
<li>
Edit the Maven project descriptor <span class="codetext">POM.XML</span> in the newly
created directory:
<ul>
<li>
Add (after the <span class="codetext">&lt;url&gt;</span> tag, although I'm not sure
the order matters) the following section: <blockquote style="font-family: monospace">&lt;profiles&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;profile&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;id&gt;servlet&lt;/id&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;activation&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;activeByDefault&gt;false&lt;/activeByDefault&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/activation&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;dependencies&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;dependency&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;groupId&gt;javax.servlet&lt;/groupId&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;artifactId&gt;servlet-api&lt;/artifactId&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;version&gt;2.5&lt;/version&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;scope&gt;provided&lt;/scope&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/dependency&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;dependency&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;groupId&gt;javax.servlet.jsp&lt;/groupId&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;artifactId&gt;jsp-api&lt;/artifactId&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;version&gt;2.1&lt;/version&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;scope&gt;provided&lt;/scope&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/dependency&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/dependencies&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;/profile&gt;<br>
&lt;/profiles&gt; </blockquote>
<li>
Under <span class="codetext">&lt;build&gt;</span>, add the following section: <blockquote style="font-family: monospace">&lt;plugins&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;plugin&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;groupId&gt;org.mortbay.jetty&lt;/groupId&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;artifactId&gt;maven-jetty-plugin&lt;/artifactId&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;/plugin&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;plugin&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;artifactId&gt;maven-compiler-plugin&lt;/artifactId&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;configuration&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;source&gt;1.5&lt;/source&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;target&gt;1.5&lt;/target&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/configuration&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;/plugin&gt;<br>
&lt;/plugins&gt;</blockquote>
</li>
</ul>
<li>
You can now thank my colleague <a href="http://www.aviransplace.com/">Aviran Mordo</a> for
finding out this bit of Voodoo. :-)
<li>
In the command prompt, now enter the project directory
<li>
Type in <span class="codetext">mvn eclipse:m2eclipse -Dwtpversion=1.5</span> to create
an Eclipse project
<li>
Run Eclipse if it's not already started, then from the package explorer right click
anywhere and click on Import...
<li>
Choose General-&gt;Existing Projects into Workspace. For root directory pick the workspace
directory
<li>
Choose the new project and click on Finish
<li>
At this point you may encounter a "Java compiler level does not match the version
of the installed Java project facet" error. If that's the case, just right-click on
the error (in the Problems view) and select Quick Fix, which will allow you to change
the Java project facet version to 6.0. If this isn't what you want, you probably know
enough to resolve the issue on your own...
<li>
You'll need a <span class="codetext">src/main/java</span> directory as a root source
folder (as per the <a href="http://maven.apache.org/maven-1.x/reference/conventions.html">Maven
convention</a>). Right-click on the project, select New-&gt;Source Folder and type
in <span class="codetext">src/main/java</span>.
<li>
Finally, in order to execute or debug the project on an actual running server, right-click
on the new project and select Properties. From there go to the Server tab and select
the runtime you created in the previous chapter.</li>
</ul>
<p>
At this point you have a Maven web project with a corresponding Eclipse project ready
for editing in your workspace. In practice you will have to do several things to have
any meaningful results.
</p>
<ol>
<li>
Add your own code into the mix, such as a servlet. When adding a new servlet (via
right-clicking the project, New-&gt;Other and choosing Web-&gt;Servlet) your <span class="codetext">WEB.XML</span> file
is automatically updated with the new servlet.
<li>
Add your own dependencies. Maven handles dependencies quite well; for instance, in
order to actually create a servlet you're going to need <span class="codetext">servlet-api.jar</span> in
your classpath; the easiest way to do this is to right-click the project, select Maven-&gt;Add
Dependency and then simply type in servlet and choose <span class="codetext">javax.servlet
servlet-api</span>.
<li>
When you wish to run or debug your servlet, right-click on its Java file and select
Run As-&gt;Run on Server (or Debug, as appropriate). Your applet should be happily
up and running.</li>
</ol>
<p>
<u>5. Converting an existing project to Maven</u>
</p>
<p>
I'm not sure how to go about doing this for web projects, but converting regular projects
to use Maven is actually pretty straightforward; move your sources to the appropriate
directories according to the <a href="http://maven.apache.org/maven-1.x/reference/conventions.html">Maven
conventions</a>, right-click the project in Eclipse and choose Maven-&gt;Enable Dependency
Management; this will implicitly create a Maven project descriptor for you (<span class="codetext">POM.XML</span>)
and that's pretty much it. From that point on your Eclipse and Maven projects should
peacefully coexist, allowing you to leverage both tools for your purposes.
</p>
<img width="0" height="0" src="http://www.tomergabel.com/aggbug.ashx?id=08ee53ca-6d1a-4406-a7c4-579f6414db2a" />DevelopmentDevelopment/Javahttp://www.tomergabel.com/Trackback.aspx?guid=ac38738f-475d-4f04-ba64-aead90a9fb17http://www.tomergabel.com/pingback.aspxhttp://www.tomergabel.com/PermaLink,guid,ac38738f-475d-4f04-ba64-aead90a9fb17.aspxTomer Gabel

In case it wasn't obvious, I've been doing some Java development lately. One of the
curious things about doing development in the Java world is that, whereas in the Microsoft
world you get a fairly complete tool-chain direct from a commercial vendor, in the
Java world you're pretty much dependant on the open-source ecosystem built
around the essential Java technologies: Sun defines the APIs, the community provides
the tools. In many ways this is really really cool: many Java tools like JUnit are
so absolutely groundbreaking that they found their way into the common development
idiom irrespective of language, and the availability of tools for just about any purpose
is a tremendous advantage (being able to choose freely between Resin, Jetty, Tomcat
or any other commercial container, for instance, is a huge boon).

This diversity and community-centric development ecosystem definitely comes with a
price though. Java tools, even the high-profile ones such as Eclipse, are extremely
difficult to work with for the uninitiated, with a learning curve somewhat like that
of Linux: if you take the time to learn the tools you can do astounding things and
remain in complete control of the system, but the sheer context required to do even
the most trivial thing can be - and often is - daunting.

I've been battling these tools on and off for the last few weeks and often end up
having to figure something out on my own. Unlike the .NET ecosystem, it's usually
quite difficult to find a blog post detailing a solution to a particular problem.
To that end I intend to document my successes - victories, if you will - over the
tool-chain, and also the problems I encounter and haven't been able to solve, in the
hope of helping others and maybe myself in the process. These posts will go under
the Development->Java category, and I'd really appreciate any comments on the solutions
(so that I can improve my own work) as well as the problems (so I can actually solve
them). Here's to hoping :-)

Kickstarting the Java category on this bloghttp://www.tomergabel.com/PermaLink,guid,ac38738f-475d-4f04-ba64-aead90a9fb17.aspxhttp://www.tomergabel.com/KickstartingTheJavaCategoryOnThisBlog.aspx
Wed, 05 Dec 2007 09:48:11 GMT<p>
In case it wasn't obvious, I've been doing some Java development lately. One of the
curious things about doing development in the Java world is that, whereas in the Microsoft
world you get a fairly complete tool-chain direct from a commercial vendor, in the
Java world you're pretty much <em>dependant </em>on the open-source ecosystem built
around the essential Java technologies: Sun defines the APIs, the community provides
the tools. In many ways this is really really cool: many Java tools like JUnit are
so absolutely groundbreaking that they found their way into the common development
idiom irrespective of language, and the availability of tools for just about any purpose
is a tremendous advantage (being able to choose freely between Resin, Jetty, Tomcat
or any other commercial container, for instance, is a huge boon).
</p>
<p>
This diversity and community-centric development ecosystem definitely comes with a
price though. Java tools, even the high-profile ones such as Eclipse, are extremely
difficult to work with for the uninitiated, with a learning curve somewhat like that
of Linux: if you take the time to learn the tools you can do astounding things and
remain in complete control of the system, but the sheer context required to do even
the most trivial thing can be - and often is - daunting.
</p>
<p>
I've been battling these tools on and off for the last few weeks and often end up
having to figure something out on my own. Unlike the .NET ecosystem, it's usually
quite difficult to find a blog post detailing a solution to a particular problem.
To that end I intend to document my successes - victories, if you will - over the
tool-chain, and also the problems I encounter and haven't been able to solve, in the
hope of helping others and maybe myself in the process. These posts will go under
the Development-&gt;Java category, and I'd really appreciate any comments on the solutions
(so that I can improve my own work) as well as the problems (so I can actually solve
them). Here's to hoping :-)
</p>
<img width="0" height="0" src="http://www.tomergabel.com/aggbug.ashx?id=ac38738f-475d-4f04-ba64-aead90a9fb17" />DevelopmentDevelopment/Java