Tag Archives: XML

The 8 Nights of Java – Night 4

Posted on by
Reply

Continuing The 8 Nights of Java series, tonight we focus on one of the single most important releases of Java. Java 1.4 was released a time when many businesses were starting to look to Java as a foundation for their software systems. After years of licensing proprietary or difficult to use software, Java was seen as a breadth of fresh air for many software engineers. It was helped, in part, by the decline of Windows-based computers and explosive growth of Mac and open-source Linux systems in the workplace and in homes. After all, if all of your developers are using different operating systems, then you need a software development platform that works on all of them and in that, Java was a success. So many business adopted Java 1.4 during this time and stayed on Java 1.4 for over a decade. In fact, many large enterprise systems still rely on Java 1.4 to this day. Hopefully, someone will be hired to update them soon!

Jump to: [Night 1 | Night 2 | Night 3 | Night 4 | Night 5 | Night 6 | Night 7 | Night 8]

Java 1.4 Notable Features
Sun released Java 1.4 (codename Merlin) on February 6th, 2002. Key new functionality included:

  • Regular expressions
  • Assertions
  • NIO Version 1
  • XML/XSLT support

From Jeanne:

I love regular expressions. They are one of my favorite language features because they are concise and expressive when written well. I was excited when they came out. While I started programming as a full time job after Java 1.4 was released, we were still using 1.3 as we waited for the application servers to support Java 1.4. This meant I was already employed and got to teach my teammates about regular expressions. I’ve actually given that presentation a number of times since.

I don’t use assertions because I write a lot of unit tests and the unit tests tell me about the type of problem that an assertion would. Tests help me design my code in a way that I don’t need assertions to tell me about the state of affairs. And then there is poor New I/O. I really like Java 7 NIO.2. New I/O “1”, not so much. It served it’s purpose in getting us to NIO.2 though.

From Scott:

I started programming professionally around the time that XML/XSLT were seen as the “new hot technology” to use on build enterprise systems. Having built-in support for XML transformations made Java look cutting edge at the time. While a lot of what is now done with XML is instead done by JSON, XML is still the core of many data-based systems. In fact, numerous web and mobile frond-end languages still use XML for their layouts, even if the developers using them rely solely on a GUI-based editor. Either way, Java 1.4 demonstrated that new technologies could be integrated into the JVM quite rapidly. That said, I’m still waiting for a JSON parser to become part of the standard Java runtime environment!

Java 1.4 also introduced NIO version 1, or NIO.1 for short. While NIO.2 is a quite powerful, if not commonly used framework, NIO.1 is basically dead weight at this point. The NIO.1 API never really caught on and today, very few people rely on file channels and the like. Since a key part of Java is keeping backwards compatibility, it remains part of the JRE, albeit rarely used.

EJB3 – annotations vs xml

Posted on by
2

Scott’s recent post on EJB3 got me thinking about annotations as a “replacement” for XML.

By now, we all know why shoving everything in XML isn’t the best of ideas.  I think shoving everything in Java code is bad too.  In particular deployment time concerns (like security) shouldn’t require a recompile.

JEE 5 offers the ability to choose whether to use all annotations, all XML or a mix of annotations and a partial deployment descriptor.  Yet most of the articles and books I’ve seen encourage using annotations for everything and the deployment descriptor as some kind of legacy practice or anti-pattern.  This reminds me of the situation where most people agree code in a JSP is bad practice and yet it keeps coming up due the vast quantity of beginner books with code in the JSP.  From reading the books, it sounds like EJB deployment descriptor XML = bad regardless of whether that is the case in practice.

I do think the annotation approach is fine for the mapping – unless you are developing a common component that will be deployed to different schema definitions.  Most of the time, the schema is stable as Scott noted.

Let’s look at some of the things in an EJB deployment descriptor (for a session bean):

  • Bean Type – This is a coding concern and as such fits well in the Java code.  If my bean changes from stateful to stateless, I should be looking at my code.
  • Security Settings -This is a deployment time concern.  There’s no reason a role change should mandate a redeployment.  Or that the developers know this information.  The application assembler or deployer could add this in.  As such, the security settings are well suited to being in an XML file.  This also has the advantage of a reusable component provider being able to provide generic information and the integrating applications specify XML info specific to their application.
  • Transaction Settings – This one could be argued either way.  If certain settings such as “required new” are needed, it makes sense to specify in the code to hint at this.  At the same time, the correct transaction setting could depend on the integrating application.  I think transaction settings could be a use case for specifying as a Java annotation and allowing/suggesting the integrating application override in XML.
  • Resource References -Resources are both a coding concern and a deployment time concern.  The code certainly cares that the correct resources exist.  And the deployer cares that they are linked correctly.  Luckily, this scenario has existed for years and there already exists an approach.  The reference name and link to the JNDI can be specified as Java annotations since they are coding concerns and likely stable.  The deployer has always been responsible for setting up the correct resource in the JNDI.

None of these are hard and fast rules.  They are just meant to get people thinking about when to use Java annotations vs XML for the deployment descriptors.  We don’t want to just use Java annotations blindly because they are there.

As more people migrate to EJB 3, I think we are going to see some of a “I’m not going to have a deployment descriptor at all now that I can do everything in Java” mentality.  We’ll have to see if it is going to take a swing to far in the other direction (no XML) before people realize some things belong in Java while others belong in XML.