I did some Java development when it first came out. Honest I did. I even taught Java classes in the late 1990's at Bellcore, which was a division of AT&T.
I have managed teams that have Java-based systems. And, as part of the CEP system that I did, I had to go and write Java-based web services and deliver a Java API so that other groups could hook into the Notification Services.
Despite that, and because of my long history with Microsoft technologies, I am often viewed as "The Dot Net Guy".
So, this week, I broke out the Java manuals again, and I decided to write the Exchange Simulator portion of my little project in Java 1.6. Writing the simulator was fairly easy, and in little time, I had FIX messages being passed back and forth between my Java-based Exchange Simulator and my .NET-based OMS.
Java is not that much different than C#. They even have Reflection, something that I sorely missed when I had to do C++ in the past year. I wish that Java supported C# auto properties and C# events (is this stuff coming in Java 1.8?), but other than that, it feels like programming in C# 1.0.
However, the Java language is only one small part about being a true Java developer and architect. There is an entire ecosystem that surrounds Java development. I got a list of tools and frameworks to learn from one of my friends, and there is a lot of stuff in there. This is a list of the basic tools that one needs:
I have experimented with Spring in various forms over the years (mostly Spring.Net), in addition to writing my own dependency injection framework. Plus, my recent experiences with Prism has gotten me back into the world of IOC (although I am annoyed that Prism/UnityContainer does not support any kind of "IDisposable" pattern when your modules are unloaded when an app closes). I cannot integrate Spring 3.1 into my app just yet because of some logging dependencies that are documented (QuickFix/J uses SLF4J, which is not compatible with Spring).
(N)Hibernate is also another ORM that I have looked at over the years.
As far as source control, I have always been a TFS/Perforce user. The past year and a half was spent in Clearcase, which seems a bit ancient, although it seems to work. Many people seem to prefer Subversion, so this is a good opportunity for me to learn it.
The same goes for Continuous Integration servers. I have been using Cruise Control .NET for all of my CI needs, and Hudson/Jenkins is something that I have heard mentioned for a while now.
The only piece of this stack that is totally alien to me is the Java Application Server. The whole concept of a Java Application Server is a bit new to me, as we really don't have an equivalent in the .NET world. I am not interested in the web server capability of these containers, so I need to find out the other capabilities that I can leverage. This morning, I am going to download JBoss as a first step.
(Update - It looks like you need to purchase a $99 subscription for JBoss. So, I will download Jetty, even though I am not sure that Jetty is a complete Java Application Server.)
(From the Stack Overflow post, where is a great summary of what a JAS is:
A Java EE app server is a transaction monitor for distributed components. It provides a number of abstractions (e.g., naming, pooling, component lifecycle, persistence, messaging, etc.) to help accomplish this. Lots of these services are part of the Windows operating system. Java EE needs the abstraction because it's independent of operating system.)
I will keep everyone posted on my progress.
©2011 Marc Adler - All Rights Reserved. All opinions here are personal, and have no relation to my employer.
I have managed teams that have Java-based systems. And, as part of the CEP system that I did, I had to go and write Java-based web services and deliver a Java API so that other groups could hook into the Notification Services.
Despite that, and because of my long history with Microsoft technologies, I am often viewed as "The Dot Net Guy".
So, this week, I broke out the Java manuals again, and I decided to write the Exchange Simulator portion of my little project in Java 1.6. Writing the simulator was fairly easy, and in little time, I had FIX messages being passed back and forth between my Java-based Exchange Simulator and my .NET-based OMS.
Java is not that much different than C#. They even have Reflection, something that I sorely missed when I had to do C++ in the past year. I wish that Java supported C# auto properties and C# events (is this stuff coming in Java 1.8?), but other than that, it feels like programming in C# 1.0.
However, the Java language is only one small part about being a true Java developer and architect. There is an entire ecosystem that surrounds Java development. I got a list of tools and frameworks to learn from one of my friends, and there is a lot of stuff in there. This is a list of the basic tools that one needs:
- JDK 1.6
- Eclipse 3.6 (Java EE Edition)
- JTA/JTS (transaction services)
- Spring 3.0 or 3.1
- Hibernate 3.6
- Open JMS or ActiveMQ
- JBoss, Jetty, or Apache Geronimo
- Subversion
- Jenkins or Hudson
I have experimented with Spring in various forms over the years (mostly Spring.Net), in addition to writing my own dependency injection framework. Plus, my recent experiences with Prism has gotten me back into the world of IOC (although I am annoyed that Prism/UnityContainer does not support any kind of "IDisposable" pattern when your modules are unloaded when an app closes). I cannot integrate Spring 3.1 into my app just yet because of some logging dependencies that are documented (QuickFix/J uses SLF4J, which is not compatible with Spring).
(N)Hibernate is also another ORM that I have looked at over the years.
As far as source control, I have always been a TFS/Perforce user. The past year and a half was spent in Clearcase, which seems a bit ancient, although it seems to work. Many people seem to prefer Subversion, so this is a good opportunity for me to learn it.
The same goes for Continuous Integration servers. I have been using Cruise Control .NET for all of my CI needs, and Hudson/Jenkins is something that I have heard mentioned for a while now.
The only piece of this stack that is totally alien to me is the Java Application Server. The whole concept of a Java Application Server is a bit new to me, as we really don't have an equivalent in the .NET world. I am not interested in the web server capability of these containers, so I need to find out the other capabilities that I can leverage. This morning, I am going to download JBoss as a first step.
(Update - It looks like you need to purchase a $99 subscription for JBoss. So, I will download Jetty, even though I am not sure that Jetty is a complete Java Application Server.)
(From the Stack Overflow post, where is a great summary of what a JAS is:
A Java EE app server is a transaction monitor for distributed components. It provides a number of abstractions (e.g., naming, pooling, component lifecycle, persistence, messaging, etc.) to help accomplish this. Lots of these services are part of the Windows operating system. Java EE needs the abstraction because it's independent of operating system.)
I will keep everyone posted on my progress.
©2011 Marc Adler - All Rights Reserved. All opinions here are personal, and have no relation to my employer.
5 comments:
subversion is getting a bit long in the tooth. The new kid on the block is git (http://en.wikipedia.org/wiki/Git_(software)), which is one of the new breed of distributed revision control systems. (git was originally authored by the creator of Linux, so just that fact makes it worth a look.)
jetty is a servlet container like tomcat, not a full blown app server (which contains all sorts of stuff like XA support, EJBs, etc). But its pretty amazing how much of this extra stuff you can add to jetty/tomcat if you use spring. e.g. spring supports plugging in various transaction managers. So you can start with jetty and add things as you need, or start with jboss which has a lot of stuff built in - but the stuff adds bloat, which increases start and deployment times.
Nice to see you blogging again Marc!
Thanks for the advice, Robert! The web developers who were working for me for the past year were using Git, and they kept their own source in Git and back-merged it with the main Clearcase repository every night. So, maybe I will look at Git instead of Subversion. I wonder how many of the Wall Street banks have moved over to Git. Often times, the technologies that you use are dictated by the Architectural Standard committees at the banks (I should know!).
Working in the Visual Studio environment and using .NET seems so much easier than the piecing together all of the of various components in the Java world. Say what you will about Microsoft ... but sometimes being the "benevolent dictator" has its advantages.
Interesting reading that stack of software - I use almost none of it! A bunch of the 'Java Enterprise' ecosystem is just bloat. For most applications an app server is unnecessary, Spring is unnecessary ('new' is underrated as a DI tool), etc. I've always been on the IntelliJ side of the IntelliJ / Eclipse debate. Plus there's a free version of IntelliJ now that does all that most people need.
Subversion is great, but I'm starting to use git now. The days of proprietary source control should be long gone.
Does anyone still use CruiseControl.NET? I wrote a decent chunk of it back in the day, and I think it's outdated. I've been a huge fan of TeamCity for years and still think its the market leader. Again, it has a free version for small team use.
Thanks for your feedback Mike (I guess the old Finetix crew still monitors this blog :-)
I completely agree about the use of 'new'.
As I mentioned before, some of the stack might be dictated by the individual bank or architecture committee. So something like IntelliJ/TeamCity might not be approved for Java development (although most places would probably be using Resharper). But, it's good to know that you like these tools in case I am ever in the situation where I might influence the use of the tooling.
Couple of notes:
Application servers are similar to IIS + MSMQ + COM+/MTS component services - they are usually promoted as one big process, but in fact most of them are quite modular. That said, the trend, especially in front office is *not* to use application service, but just assemble implementations of the services you need (hint - JTA is most likely not one of them).
Regarding IDE - if you are not really attached to Eclipse, do yourself a service and learn IntelliJ IDEA. It Just Works (tm). Now as they have free version, it is usually easy to get it approved.
As mentioned, Bamboo and TeamCity are the premier CI servers (with ElectricCloud and AntHill Pro for the really high end environments).
Post a Comment