Forrester’s authors say that its report, “The Future of Java,” is not a Java obituary. Java is still dominant in the enterprise but no programming language has retained a central position through multiple platform changes. Java will evolve just as Assembler, C and COBOL did. More so, the core message here is for application developers and how applications are distributed.

…

Oracle controls the future of Java but its road map has been accepted and that means no major disruptions for enterprise customers. But it’s clear that Java is no longer the center for technology innovation. The innovation is now on the platforms and with Ruby and open environments such as HTML 5.

via Why The Future of Java is with Large Customers, not Innovative, Young Developers.

No related posts.

My theory goes like this: Good java developers are hard to find because fewer and fewer of them are being created. New developers are not choosing java to “cut their teeth” on. And I suspect that coming from whatever they are coming from, java doesn’t look appealing.

via I think I figured out why good Java developers are so hard to find « I love groovy.

The excerpt above came from a blog post I read this morning. It made me ask the question: Is Java on it’s way to being phased out by newer JVM languages? Judging by some of the comments to this article at least a few believe so. But which JVM language has the potential to replace it? I found this article: The Next Big JVM Language which evaluates a few contenders.

Java is not sexy to the next generation of developers. The language is considered old, bloated, overly complex and has more than a few legacy quirks which fuel many language debates. Scala, Jython/Python, JRuby/Ruby and Groovy all seem to be popular alternatives.

headpower :

I’m a 15 year old person studying to become a developer (mostly in my free time), and I can tell you that Java is not something I would ever consider. I consider myself to “know” Python and [Objective-]C, but, Java isn’t even on my radar. I know some people my age who would use Java, but to me it just seems outdated and bloated to most of us, I think.

Since I guess I’m the “next generation”, it doesn’t seem that your situation is going to get any better…

According to these sources:  http://www.numberof.net/number-of-java-developers/ and http://jaxenter.com/how-many-java-developers-are-there-10462.html there are 9,007,346 Java developers world-wide. That’s a very large and active user base. While it seems that Java may not be the choice of the next-generation of developers it is still the primary language for over 9 million developers.

No related posts.

JavaOne and Oracle Develop 2010

No related posts.

Receiving null is confusing. When you make a function call and the result is null what does it mean? Was the data not found? Was there an exception in the function that was silently swallowed resulting in the return of a null object? You’re not really sure if null is an expected return value. If no exception is thrown then you just kind of assume that null is a valid return value. However, you can’t really do anything with the returned null object so what do you do now?

Here are a couple of alternatives to returning null:

Use the Empty Collection Methods

If you are working with returning collection objects from your function you should return an empty collection rather than a null object. This is very easy to do with the Collections class. There are three static methods available:

• Collections.emptyList()
• Collections.emptySet()
• Collections.emptyMap()

An empty List is easily instantiated for return as shown here:

   List<String> myList = Collections.emptyList();

Returning an empty List eliminates the required check for null by the function caller. Now instead of having code which looks like this:

   List<String> names = getNames();
   if(names != null) {
      for(String name : names) {
         System.out.println(name);
      }
   }

You can simply write the following without worrying about a NullPointerException:

   List<String> names = getNames();
   for(String name : names) {
      System.out.println(name);
   }

This second example is much cleaner, easier to read and understand. Returning empty Collections is much safer as well since it avoids the potential run time exception: NullPointerException.

An unchecked exception represent defects in the program (bugs) - often invalid arguments passed to a non-private method. To quote from The Java Programming Language, by Gosling, Arnold, and Holmes : “Unchecked runtime exceptions represent conditions that, generally speaking, reflect errors in your program’s logic and cannot be reasonably recovered from at run time.” [1]

Certainly an empty collection is not a bug! So lets just return an empty collection rather than a null reference. In addition, testing for an empty collection is a lot more intuitive than testing for null.

   List<String> names = getNames();
   if(names.isEmpty()) {
      //throw an Exception
      //or do something else
      //or do nothing at all

   }

Throw an Exception

It’s perfectly acceptable to throw a custom checked exception alerting the calling client that the requested object cannot be populated or retrieved. This approach is much more revealing and forces the calling client to handle the potential problem. It also eliminates the need to check the returned object for null.

A checked exception is guaranteed to be handled so you gain more control over your program. A RuntimeException may or may not be handled by the caller and will bubble up until either it is caught or reaches the top of the caller chain.

Conclusion

Nulls are useful under certain conditions when null values are expected. However, for the above conditions with collections and data retrieval I feel it has been abused. Use the empty collection and avoid returning null objects whenever possible. It will make code cleaner, easier to read and debug.

Citations:

1. “checked versus uncheck exceptions” JavaPractices.com. 2010 Hirondelle Systems. 6 June 2010 <http://www.javapractices.com/topic/TopicAction.do?Id=129>

No related posts.

A Simple Service

To start out you should create an interface defining your business methods. I will keep the implementation extremely simple so we can focus on the details of web services. Here’s our interface named SimpleServiceWS

public interface SimpleServiceWS {

	public String simpleMethod();

}

The next step is to create a plain java class (POJO) which implements this interface. I’ll name it SimpleServiceImpl

public class SimpleServiceImpl implements SimpleServiceWS {

	public String simpleMethod() {
		return "Simple response";
	}

}

Please note that it is not required to create and implement an interface and almost every web service example I found did not do so. I feel it is good practice and consistent with Java programming practices to program against interfaces.

What we have so far is just a plain Java class (POJO) that returns a simple string. Now we have to decorate our class with some annotations to make it behave as a web services.

import javax.jws.WebService;

@WebService(
		serviceName="SimpleService",
		portName="SimpleServicePort",
		endpointInterface="net.franksalinas.javablog.SimpleServiceWS")
public class SimpleServiceImpl implements SimpleServiceWS {

	public String simpleMethod() {
		return "Simple response";
	}

}

I added the @WebService annotation and supplied some values to the annotation attributes. You can simply add the @WebService annotation without specifying any of the attributes and they will pick up default values based on the class and package names. However, there is one exception. If you choose to define and implement an interface you must do two things:

1. You must decorate the interface with the @WebService annotation.
2. You must also supply the endpointInterface annotation attribute with the fully qualified name of the interface in the implementation class.

import javax.jws.WebService;

@WebService()
public interface SimpleServiceWS {

	public String simpleMethod();

}

As far as code goes this is all there is to it. The remaing steps describe how to package and deploy these objects.

Package and Deploy

As I mentioned above we will package and deploy these classes as a servlet implementation. I am most familiar with JBoss so that is the application server I will use but any servlet container should work fine.

Create a new xml file named web.xml and define the servlet mappings for the SimpleServiceImpl class as shown here.

<?xml version="><?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC
	"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
	"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
	<servlet>
		<servlet-name>SimpleServiceWS</servlet-name>
		<servlet-class>net.franksalinas.javablog.SimpleServiceImpl</servlet-class>
	</servlet>

	<servlet-mapping>
		<servlet-name>SimpleServiceWS</servlet-name>
		<url-pattern>/SimpleService</url-pattern>
	</servlet-mapping>
</web-app>

Now create a WEB-INF directory and place this file there. Compile your Java files and place them in a folder named classes. Create a folder named dist. Copy the WEB-INF and classes directory to this new folder. Now create a JAR file named SimpleService.war containing the contents of dist directory. (Visit http://en.wikipedia.org/wiki/Sun_WAR_(file_format) for more info on the WAR file structure.)

You should now have a WAR file with the following structure:

META-INF/
META-INF/MANIFEST.MF
WEB-INF/
WEB-INF/web.xml
classes/
classes/net/
classes/net/franksalinas/
classes/net/franksalinas/javablog/
classes/net/franksalinas/javablog/SimpleServiceImpl.class
classes/net/franksalinas/javablog/SimpleServiceWS.class

Now you can copy this SimpleService.war file to your application server’s deployment directory (<jboss_home>/server/default/deploy) and start the server. Your web service will be deployed. On JBoss you can see the deployment and access the WSDL for the service at url http://127.0.0.1:8080/SimpleService/SimpleService?wsdl

That’s all there is to it!

Note that we did not implement the javax.servlet.http.HttpServlet interface in the service class. It is not required but may be considered good practice to do so depdending on your implementation.

Summary

In this example we created a simple web service using JAX-WS and packaged and deployed the implementation as a servlet configuration. We learned that web services are nothing more than plain old Java objects (POJOs) that are decorated with a few simple annotations and that servlet configurations do not require the web service class to implement the javax.servlet.http.HttpServlet interface. We covered packaging the code as a WAR file and deploying on the JBoss application server.

This is a very simple example and there’s a lot more material to cover. I hope you found this posting informative and helpful. You can download all the source code for this example here: SimpleService.zip.

Related posts:

1. Web Services on JBoss I’ve been working on a project which requires developing some...
2. The EJB Specification, Concurrency, and Batch Processing The EJB specification does not leave much room for implementing...

Java tip: How to read files quickly | Nadeau Software

No related posts.

Renaud Waldura’s The Final Word On the final Keyword .

No related posts.

The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.

These functions are reserved for the EJB container. Allowing the enterprise bean to manage threads would decrease the container’s ability to properly manage the runtime environment.

Researching this topic I found that while the specification states the restrictions, the EJB containers do not actually enforce the rule. I was able to test an implementation using a ThreadPoolExecutor in JBoss with no problems. Most implementations addressing long running batch processing solutions specify developing applications outside the EJB container. While the design respects the EJB programming restrictions it is not always a feasible solution for developers. Currently, I am confronted with business requirements to process a large set of files within the process flow of a business method.  The process flow would be to select files based on some criteria, specify what to do with the file collection, and submit the task asynchronously as a background process through JMS to a message-driven bean (MDB) for processing. When the job is done, update the database with the new file paths and notify the user of successful completion. There are several underlying issues:

1. The user submits a request to process a very large set of files. The time to process this request may take hours to complete and will most-likely exceed the default configured transaction time-out of the message-driven bean at which point a TransactionTimeOut Exception is thrown and the operation halts. This can be overcome to a certain extent by increasing the transaction timeout period in the application server settings.
2. The single large task executes in a sequential manner, and does not take advantage of all available CPU’s on a multi-processor machine.
3. It would be more efficient and reduce execution time if the task could be broken up into smaller tasks (or batches) and executed in parallel, or distributed across a group of servers which can process each sub-task individually.

The design concepts are relatively simple but the implementation details are complex due to the programming restrictions in the EJB specification. This screams concurrency! The most commonly suggested solution for concurrency is to use JMS. One solution I found is to break up the task, create multiple JMS messages that reply to an acknowledgment queue. Then set the Session Bean to listen to that ack queue using a message filter to collect the results of each sub-task. This is a good solution but a bit more complex to implement than bending the rules and using a ThreadPoolExecutor. I think the real issue with managing threads within the EJB container is the topic of reentrancy. In my case, I am calling a remote service so there is no chance of that.

There are many factors to consider when implementing a batch processing framework for your application. There is no one size fits all solution. You really have to evaluate all the options, weigh the pros and cons of each, and decide on your own which approach works best in your environment. Here is a list of articles I found very helpful in making that decision:

• High Performance Batch Processing with Java Enterprise Edition
• Add Concurrent Processing with Message Driven Beans
• JMS Enables Concurrent Processing in EJB
• High Volume Transaction Processing in J2EE

Related posts:

1. Java Web Services: Getting Started A short tutorial on getting started with Java Web Services...

I didn’t know what to do. I wanted to insert a new row but could not decide which value is correct to denote for boolean true or false? Then I thought how would the code handle these values? The above value combinations make it impossible to use the ternary operator to retrieve the desired boolean value such as:

boolean isLaughable =
    resultSet.getString("is_laughable").equals("Y")?true:false);

Then I found that someone had gone through the trouble of creating a utility method to convert the various character values to the desired boolean output of true or false. The method looked something like this:

static public boolean getBooleanFromString(String attr)
{
  if ( attr == null ) {
		return false ;
  }
  boolean val = false;

  if ("true".equalsIgnoreCase(attr)
         || "t".equalsIgnoreCase(attr)
         || "y".equalsIgnoreCase(attr)
         || "yes".equalsIgnoreCase(attr))
  {
		val = true;
  }

  return val;
}

I couldn’t believe it! Instead of cleansing the data they just applied a Band-Aid to get around the issue. This is not the proper way to store this type of data. Possible values for this field can only be one of two values; true or false. Physically what characters represent those values is up to the developer. However since it represents a boolean value it should not allow more than two values to be inserted nor should it allow NULL values.

The proper action to take here is to clean up the data and add a check constraint to the table to restrict the data stored in this field. This can be done with two simple ALTER statements:

ALTER TABLE jokes
ADD IS_LAUGHABLE char(1) DEFAULT 'N' NOT NULL; 

ALTER TABLE jokes
ADD CONSTRAINT jokes_is_laughable_ck
CHECK (IS_LAUGHABLE IN('Y','N'));

Adding check constraints to your database will greatly increase data integrity, reduce data related bugs and make programming easier since you know exactly what values to expect from the database. Any situation where you have a finite list of values such as boolean values, or state (e.g. Error, Success, Processing, etc) are good candidates for value check constraints. Use good judgment and leverage check constraints to your advantage.

No related posts.

Median Salary

As you can see from the data below the median salary between the two technologies is comparable with .NET having a slightly higher median salary for Architect/Lead roles and Java/J2EE having a higher median salary for Developer roles.

Generated By: OdinJobs – IT Jobs and Technology Job Search Engine

Generated By: OdinJobs – IT Jobs and Technology Job Search Engine

Job Trends

The job trends charts shows that there is a higher demand for J2EE Architect/Lead roles than for .NET. There also appears to have been a spike in job listings for J2EE Architect/Lead roles in recent months while job trends for Developer roles are comparable between the two technologies. Both charts show an increase in job listings in 2008 over 2007.

Generated By: OdinJobs – IT Jobs and Technology Job Search Engine

Generated By: OdinJobs – IT Jobs and Technology Job Search Engine

Salary Histogram

The salary histograms show that the salary range for Architect/Lead roles is between $80k and $120k, and $70k and $100k for Developer roles depending on experience. Both histograms show outlying salary data around the $150k range which I suspect represents Director level positions.

Generated By: OdinJobs – IT Jobs and Technology Job Search Engine

Generated By: OdinJobs – IT Jobs and Technology Job Search Engine

Conclusion

The job market seems solid for both technologies and salaries are comparable. Java/J2EE seems to have a slight advantage in demand and salary but it is evident that you can make a great career specializing in Java or .NET with plenty of room for career advancement. The OdinJobs web site provides additional functionality to compare job market trends and salary in different locations as well as specific job roles and company types. It’s interesting to see which industries specific technologies are in demand.

No related posts.