"Real World" Java Development?


  • ♿ (Parody)

    As a .NET/Microsoft guy, I've been inside a whole lot of different .NET shops and have seen the way they develop their applications. It's a lot different than what "the bloggers" talk about: no continous integration (doesn't make sense for a business info sys usually), no xUnit tests, no MVC, etc and so on. Most people just use Visual Studio and code. If I were to rely entirely on what I read on the blogs and forums, my impression of .NET development would be completely different than the reality.

    Enter Java, specifically as it relates to enterprise/information systems. I'm trying to learn and understand how companies structure, develop, and deploy their code. According to the bloggers, everyone is using Ant or Maven, Enterprise Beans (or not, they seem to be unpopular), and all sorts of other tools and utilities by apache, sun, etc. I was at a java shop the other day, and learned that their development was much simpler than I immagined:

    • SVN
    • Eclipse w/ Tomcat Plugin
    • Application: 
      • Bunch of Servlet Classes 
      • Bunch of JSP Pages
      • Utilize a few 3rd party helper libs/tools (/lib/*.jar)
    • Handful of jUnit tests, but not really activiely doing them
    • Tomcat

    Nothing else - everything was built by Eclipse through the "Build WAR file" option, then dropped in Tomcat's folder.

    So, my question is.... what do the java development environments/stacks look like at places you'e worked or seen? Like .NET, is the "blogger" view of Java developmet much different than the real world?



  • There are java shops that use just the basics, as described above. Other always follow the trend, use JSF and Struts and Spring etc. In my experience, it's the first kind of shop that gets things done.



  • I think you will see that everywhere, no matter what language.

    Although i have to say that at the shop where i work we do actually use unit testing and proper development, ... most of the time.  But has more to do with what the budget and deadline for a project then what the norm is. But i guess at my shop we deliver to a segment of the market that would slap us silly if we didn't. 


  • ♿ (Parody)

    @stratos said:

    think you will see that everywhere, no matter what language.

    I'm not really surprised about this fact... but the problem is, I'm having a hard time figuring out what "stacks" people acutally use. No one writes a blog post that says, "we just use Tomcat, Servlets, and JSP".

    I'm just trying to figure out what technologies/techniques/components are generally tied together to make Java applications. What are common stacks have you seen for different projects?


  • Garbage Person

    In general, the Java stack as I see it in practice looks like this (rendered from the top down):

    <garbled mess of trendy frameworks, etc.>
    JSP/Servlets
    Tomcat
    Apache2
    Ubuntu, Debian, CentOS, Fedora or RedHat

     

    The garbled mess at the top usually has at least one of everything you've heard of, plus 2 or 3 things you haven't.


  • ♿ (Parody)

    Our stack is Eclipse, svn, ant, JSF, Tomcat, JBoss, Seam, Hibernate, RichFaces, RHEL4.  There are some unit tests, championed by one of the lead developers, but I don't think they're very comprehensive, although I believe he did set up CruiseControl, though I'm not sure that it really has any effect.



  • @Alex Papadimoulis said:

    @stratos said:

    think you will see that everywhere, no matter what language.

    I'm not really surprised about this fact... but the problem is, I'm having a hard time figuring out what "stacks" people acutally use. No one writes a blog post that says, "we just use Tomcat, Servlets, and JSP".

    not surprising as it's not easy to answer.

    We run many projects, and the actual stack depends on the project requirements. WebLogic, OC4J, JBoss, WebSphere, we use it all. Struts, Spring, JSP, ADF, bring it on. JDeveloper, Eclipse, IntelliJ, Netbeans, you name it. ANT, Maven? Subversion, Visual Sourcesafe, CVS.
    But rarely will all that take place inside the scope of a single project.

    We tried last year to come up with a 'standard stack' that would be the recommended basis for new projects but gave up on the idea as the diversity of projects we run is just too great.



  •  Here where i work we have some sort of "standard" (loosly enforced):

    CVS

    Eclipse

    Maven 2

    JSP with Struts 1.X framework and Hibernate for DAO entity beans

    All sitting on Apache Tomcat 5.5 (soon moving to 6)

    Although my team is going to start using JSF to get away from the Struts 1.X

     

    Most shops that I know of use Tomcat servers (on some Linux brew), some type of framework (Struts, Spring ect), Maven and either SVN or CVS. 



  •  Our development stack here, for web apps, is along the lines of JSF + IceFaces for the presentation layer; Spring for the business layer; and iBATIS for the data access layer.

     We use Ant to build the project (with AntHill for continuous integration), and Tomcat 6. Oh, and we do have JUnit tests, although probably not as many as we should.

    In my experience there are as many different Java 'stacks' as there are companies, although some seem to be more common than others. Struts 1 + JSP still seems to be very popular. And in my limited experience the Spring Framework is pretty ubiquitous, and Hibernate is a very popular ORM tool.

    Part of the problem is the proliferation of tools - there are hundreds of Java web frameworks (Tapestry, JSF, Struts 2, Spring MVC, ...). 



  • @PhillS said:

    Part of the problem is the proliferation of tools - there are hundreds of Java web frameworks (Tapestry, JSF, Struts 2, Spring MVC, ...). 

     

    Don't forget jBanana.



  • The bottom of the stack is pretty irrelevant. Most small to medium projects I've seen are running Tomcat on Linux - a few people are migrating over to Glassfish V2 and V3. In theory your app will deploy fine on any app server.

    DB persistence stuff is nearly always done with Hibernate. Hand-rolled JDBC "manager" classes suck. So that's the M in MVC.

    V & C are usually one of:
    Struts1 (popular, easy, but cumbersome)
    Struts2 (not very popular, more complex, but very powerful for certain kinds of tasks)
    JSF (tag soup, but I've heard it's better these days)
    Spring & Spring MVC
    Minority framework (Wicket, Tapestry, other random stupid name)
    Some shops mix in Spring with other frameworks - since it's not really a "web framework" without Spring MVC. If your project is big and complicated with lots of modules and so on, Spring is your friend.

    IDEs are almost exclusively Netbeans or Eclipse.

    Third-party helper things are numerous. The Apache Commons set of libs are a wonderful mixed bag of tools - they're great for things like string manipulation, array copying, reflection on beans, etc etc. Displaytag is a fantastic tag library for making tables easily and quickly, and it works great with most web frameworks.

    JUnit is usually everywhere or nowhere - it depends on the attitude of the developers and how easy the framework makes unit testing. Its been rare in my experience to see shops half-use it. I love JUnit, but it took me a while to get the hang of unit-testing S2 actions.

    My own stack is Netbeans -> Struts2 & Hibernate & Spring -> Tomcat on Linux.

    I've not worked on huge, enterprise-spanning EJB projects, so I can't comment on that area, but in the small-to-medium app world it's very simple, and better for it.



  •  Utilizing eclipse to build your project is fairly rare, I would say. The by far most common way of building projects is using Ant. Some people let ant and eclipse coexist and complement each other, letting eclipse compile on-the-fly, then have the ant script checking the compile, running tests and packaging the product.

    If you ask me, I find it very verbose and fairly repetitive and hard to make a complete ant script doing compile, test, weaving, instrumentation, coverage reports etc for every project. Therefore I advocate maven, which really uses 'configuration by exception' and naming convention to manage really complex builds with minimal verbosity. Maven takes a long time to learn and is hard to 'wrestle' to do what you want in the beginning, wherefore I think many people dismiss it as overly complicated.

     When it comes to the code itself, Spring is very popular as a generic integration framework, providing adapter classes and tons of utilities to tie persistence, transactions, caches etc together to a more manageable product. It runs on java 1.3 onwards and is probably the only integration framework you will need for java.

    Enterprise beans are handy if you need to build non-stop applications. You get automatic persistence and reloading of state (immunity to application crash) with stateful beans. All EJB:s provide you with per-methodcall transaction setting. Ejb 2 was a horrible mess with a huge xml file and 2 interfaces needed for every class that you wanted to have. This was fixed with EJB 3.0, which is really nice to work with. Java EE also gives you persistent, transactional messaging, JMS. This is really a lifesaver if you are considering a HA app. Since Java EE is a standard, you can choose from many different servers providing these services, all with different gotchas.  

     Generally, I find that there are two different groups within the Java community. One strongly advocates Spring, and declares Java EE 'a bloat'. The other group have embraced Java EE and try to take it further (see JBoss SEAM for example). I beleive that these two groups are closing in on each other lately, with the Spring people realizing what is lacking in Spring, and the Java EE people realizing that the framework can be much less intrusive and lightweight.

     Considering the build configurations, I think that you will see a big span, but I definately beleive that the possiblity of setting up a good build environment in Java is much greater, considering all the great available tools such as Emma, Maven, Ant (with Ivy), all the test frameworks etc.

    My impression is that there are two type of build stacks that you will: one fairly 'old school' with ant + jsp + libs, as you describe. However, there is also the other kind of people, who really have a full-blown stack with unit+regression+integration testing, ci with coverage, maven, spring+wicket or seam+JSF. But these are usually just the most motivated ones with time on their hands :)


Log in to reply