In October, Sun released an early access of the new Java ME SDK 3.0. This SDK promises to unite all the Java ME SDKs to include what is the Sun Wireless Toolkit (WTK) for CLDC/MIDP development, the Sun Java Toolkit for CDC as well as integrated tools and libraries for BD-J and the Lightweight User Interface Toolkit (LWUIT). In addition to the uniting the Java ME SDK's, this new SDK provides some very useful tools to include profiling, a device database and search tool, and on-device debugging. The underlying virtual machine also uses the CLDC Hotspot Implementation Virtual Machine (in place of the KVM used with the WTK).
Based on an email from Radko Najman, the final release of the product should be available by JavaOne 2009. In fact, he indicated they hope to have a final release out by March or April.
Find out more about this new SDK at http://java.sun.com/javame/downloads/sdk30ea.jsp. Also, look for my upcoming article on the SDK on http://www.DevX.com.
Monday, February 23, 2009
Wednesday, February 4, 2009
The Eclipse Classpath
Tools can be a funny thing. They are meant to help shorten the time it takes to complete a task. But when you are unfamiliar with how the tool works, it can sometimes take longer than if the tool didn’t exist.
Eclipse, and most integrated development environments (IDEs), are that way. It is an extremely powerful tool in the right hands. In the hands of a novice, sometimes it can be overwhelming.
Novice Java developers are taught about the classpath in their first days or hours of learning the Java programming language. When using java.exe and javac.exe command line tools, the classpath is usually transparent or can be made transparent with a simple call to setenv. When developers step up to an IDE, what the classpath is and what it points to isn’t so clear anymore. So, if you are just learning Java and need some help on the where to set and get information on the classpath, this posting is for you!
By the way, take heart. The reason I make this post is because so many of my students have had questions about the classpath or wrestled with problems due to the classpath setting in the IDE that I felt compelled to write this post in hopes of alleviating some future student’s pain. So you are not alone.
Maybe one of the largest issues with classpath and Eclipse is that there are so many places to set and affect the classpath. So, let’s address them one at a time.
The Project Properties
First, start Eclipse and right click on a project folder in the Package Explorer view. Select Properties from the menu that results.
A Properties window like that shown below will appear.
Select Java Build Path from the menu on the left hand side. A series of tabs (Source, Projects, Libraries, Order and Export) appear. It is on these tabs that you can set the “build” classpath. That is, you can set where Java will find class files, Jar files and other resources when it is compiling (building) your application. The Source tab allows you to specify folders of source code (typically folders containing the packages and .java files for your project). The Projects tab allows you to include the code from other Eclipse projects into the building. Finally, the Libraries tab allows you to specify libraries of classes to add to your build – either external or internal to Eclipse.
Selecting the Add JARs button on this tab allows you to add a Java library (JAR or ZIP file of classes) that is known to Eclipse (that is part of an open Eclipse project). The Add External JARs button allows you to add a Java library that is available via your computer’s file system or network (essentially any library reachable by your machine). The Add Library button allows you to add the classes (via Java library) of a Java/Eclipse plug-in, tool (like JUnit), or framework (like Struts or JSF) that is known and installed with Eclipse.
The Add Class Folder button allows you to add the classes from any folder of any project that is open in Eclipse.
And of course the Add External Class Folder button allows you to add classes from any folder on your computer’s file system or network to your build. I skipped one button; the Add Variable button. That’s covered in the next section.
By the way, as a short cut, you can also adjust the build path by right clicking on a project in the Package Explorer view and selecting Build Path from the menu.
Variables
So what does the variable button do? If you click on it, you’ll see you can add a variable to the build path but what does that mean?
Close the project properties window and return to the Eclipse window. In Eclipse, select the Window > Preferences menu option on the menu bar.
In the Preferences window that appears, locate the Java > Build Path > Classpath Variable option in the menu on the left (see the image below, it can be a little tricky to find in this large menu.
A classpath variable allows you to define a variable or alias to a folder with class files or a specific JAR file. Then, the variable can simply be added to the classpath of either the build or runtime configuration (see below). A variable helps you easily refer to a particular library without having to remember where it is. Also, it allows the location to change without having to change the project – just change the variable’s path. This can be particularly useful if the library is shared by several projects.
The Runtime Configuration
The classes that are available to build the application are not always the same as the classes available to run the application. When you are ready to run your application, most people just click on the Run As or Debug As icons in the Eclipse toolbar; unaware that Eclipse is setting up an environment complete with a classpath to execute your code. When you run or debug your application, Eclipse sets up what is called a runtime configuration. That configuration includes a classpath telling the Java VM where it should locate classes, libraries, etc. needed as the application is executed. You can modify this execution or runtime classpath as well.
Right click on one of your executable classes or projects in the Package Explorer view. Select either the Run As… or Debug As… option from the menu that appears. From the sub-menu that appears, notice the Run Configurations… or Debug Configurations… option that is presented.
Select the Run Configurations… option and a Run Configurations window like the one shown below should appear.
In the menu on the left hand side, find the Java Application listing. These are your runtime configurations. By default, the name of the configuration usually matches the name of your executing class. In the Main tab to the right, notice the “Main class” field. This is the class that is going to be executed when you request your project or class “Run As…” Click on the Classpath tab and you see a display similar to that below.
By expanding the entry trees, you can see all the file folders and libraries that are part of the runtime classpath and are accessible to your application as it is execute. Again, with the buttons on this window, you can choose to add or remove file folders and libraries (internal or external JAR or ZIP files) to the classpath. By default, the runtime classpath should contain the same file folders and libraries as your build path.
A classpath checker
For those that find they have some issues with duplicate classes or classes not found, you may want to take a look at the Classpath Checker Eclipse plug-in (available here).
This tool will detect missing JAR files and help detect if you have classes coming from more than one location (duplicate classes).
Hope this helps developers trying to untangle the mystery of classpath in Eclipse. If you need help learning Java or other open source technology, come join me in class (www.intertech.com).
Eclipse, and most integrated development environments (IDEs), are that way. It is an extremely powerful tool in the right hands. In the hands of a novice, sometimes it can be overwhelming.
Novice Java developers are taught about the classpath in their first days or hours of learning the Java programming language. When using java.exe and javac.exe command line tools, the classpath is usually transparent or can be made transparent with a simple call to setenv. When developers step up to an IDE, what the classpath is and what it points to isn’t so clear anymore. So, if you are just learning Java and need some help on the where to set and get information on the classpath, this posting is for you!
By the way, take heart. The reason I make this post is because so many of my students have had questions about the classpath or wrestled with problems due to the classpath setting in the IDE that I felt compelled to write this post in hopes of alleviating some future student’s pain. So you are not alone.
Maybe one of the largest issues with classpath and Eclipse is that there are so many places to set and affect the classpath. So, let’s address them one at a time.
The Project Properties
First, start Eclipse and right click on a project folder in the Package Explorer view. Select Properties from the menu that results.
A Properties window like that shown below will appear.
Select Java Build Path from the menu on the left hand side. A series of tabs (Source, Projects, Libraries, Order and Export) appear. It is on these tabs that you can set the “build” classpath. That is, you can set where Java will find class files, Jar files and other resources when it is compiling (building) your application. The Source tab allows you to specify folders of source code (typically folders containing the packages and .java files for your project). The Projects tab allows you to include the code from other Eclipse projects into the building. Finally, the Libraries tab allows you to specify libraries of classes to add to your build – either external or internal to Eclipse.
Selecting the Add JARs button on this tab allows you to add a Java library (JAR or ZIP file of classes) that is known to Eclipse (that is part of an open Eclipse project). The Add External JARs button allows you to add a Java library that is available via your computer’s file system or network (essentially any library reachable by your machine). The Add Library button allows you to add the classes (via Java library) of a Java/Eclipse plug-in, tool (like JUnit), or framework (like Struts or JSF) that is known and installed with Eclipse.
The Add Class Folder button allows you to add the classes from any folder of any project that is open in Eclipse.
And of course the Add External Class Folder button allows you to add classes from any folder on your computer’s file system or network to your build. I skipped one button; the Add Variable button. That’s covered in the next section.
By the way, as a short cut, you can also adjust the build path by right clicking on a project in the Package Explorer view and selecting Build Path from the menu.
Variables
So what does the variable button do? If you click on it, you’ll see you can add a variable to the build path but what does that mean?
Close the project properties window and return to the Eclipse window. In Eclipse, select the Window > Preferences menu option on the menu bar.
In the Preferences window that appears, locate the Java > Build Path > Classpath Variable option in the menu on the left (see the image below, it can be a little tricky to find in this large menu.
A classpath variable allows you to define a variable or alias to a folder with class files or a specific JAR file. Then, the variable can simply be added to the classpath of either the build or runtime configuration (see below). A variable helps you easily refer to a particular library without having to remember where it is. Also, it allows the location to change without having to change the project – just change the variable’s path. This can be particularly useful if the library is shared by several projects.
The Runtime Configuration
The classes that are available to build the application are not always the same as the classes available to run the application. When you are ready to run your application, most people just click on the Run As or Debug As icons in the Eclipse toolbar; unaware that Eclipse is setting up an environment complete with a classpath to execute your code. When you run or debug your application, Eclipse sets up what is called a runtime configuration. That configuration includes a classpath telling the Java VM where it should locate classes, libraries, etc. needed as the application is executed. You can modify this execution or runtime classpath as well.
Right click on one of your executable classes or projects in the Package Explorer view. Select either the Run As… or Debug As… option from the menu that appears. From the sub-menu that appears, notice the Run Configurations… or Debug Configurations… option that is presented.
Select the Run Configurations… option and a Run Configurations window like the one shown below should appear.
In the menu on the left hand side, find the Java Application listing. These are your runtime configurations. By default, the name of the configuration usually matches the name of your executing class. In the Main tab to the right, notice the “Main class” field. This is the class that is going to be executed when you request your project or class “Run As…” Click on the Classpath tab and you see a display similar to that below.
By expanding the entry trees, you can see all the file folders and libraries that are part of the runtime classpath and are accessible to your application as it is execute. Again, with the buttons on this window, you can choose to add or remove file folders and libraries (internal or external JAR or ZIP files) to the classpath. By default, the runtime classpath should contain the same file folders and libraries as your build path.
A classpath checker
For those that find they have some issues with duplicate classes or classes not found, you may want to take a look at the Classpath Checker Eclipse plug-in (available here).
This tool will detect missing JAR files and help detect if you have classes coming from more than one location (duplicate classes).
Hope this helps developers trying to untangle the mystery of classpath in Eclipse. If you need help learning Java or other open source technology, come join me in class (www.intertech.com).
Tuesday, February 3, 2009
Spring is on its way!
In Minnesota, winter is a long hard season. We usually don’t start thinking about spring until the lakes unfreeze and fishing season begins – that’s May those unfamiliar with the territory.
But this year, Spring of a different nature arrives early. The Spring I am speaking of is the Spring Framework. Spring Framework 3.0 Milestone 1 is out (download it here), arriving in December ’08 with the final release expected… no pun intended… this spring. Major additions and changes include: requiring Java 5 and J2EE 1.4, support for RESTful Web Services, the introduction of Spring expression language (EL). To learn more about Spring 3.0, I point you to the blog and web site of the experts.
However, what I found very interesting about Spring 3.0 can be found in the Spring MVC module. In Spring 2.5, the Spring MVC framework adopted annotation-based controllers as an alternative to the large hierarchy of Spring MVC controller classes (see diagram below).
In fact, these annotation-based controllers were just one of many “stereotype” annotations. Components with stereotype annotations (let’s call the stereotypical components) are meant to clearly identify the components serving in each role of the application – especially as it relates to the model-view-controller rolled environment. The drive behind stereotypical components is that these classes do not have to extend any base class or reference a Spring, Servlet, or other API. One thing about the Spring Framework – it has always embraced loose coupling!
With the Spring Framework 3.0, I was surprised to find that the intent of the Spring project team is to take this shift in design to the next level – and to do it NOW. The MVC controller hierarchy that many in the Spring development community have become familiar with (and embraced over Struts or JSF in many cases) is being deprecated in favor of the new annotation/stereotypical model. Read the following quote from Rod Johnson (Spring founder, project lead and CEO of Spring Source) from an interview with InfoQ on Jan 22nd.
In Spring framework 3.0 there will be a number of deprecations, for example, the old MVC controller hierarchy. We view the Annotation based Spring MVC usage model that we introduced in Spring 2.5 is being a far superior replacement. That will be deprecated in Spring framework 3.0 and in the next version, whether it's 3.1 or 4.0, those classes will be removed. We don't approach deprecation the way some seem to approach deprecation, which is "Let's put a message into it" that will take years when they compile a code. Our view on deprecation is that it is a serious statement of intent. If we deprecate something we are saying "Hey, guys, it's time to think getting off this because we don't think it's a good usage model anymore." There will certainly be a bit of - if you like - Spring cleaning in the next release after Spring 3.0. Probably the most obvious part will be the Spring MVC controller hierarchy.
I applaud the Spring team for its position on deprecation. On every project I have been on, it seems there is at least one consultation with a novice developer about why using many of the java.util.Date methods is a bad idea. While Sun deals with a different extent of concerns and legacy support, I often wonder when, if ever, we’ll see Java deprecated classes and methods leave the JDK.
However, I am anxious to see how the Spring community embraces this large change. A lot of applications have been built with Spring MVC. In large enterprise applications that have embraced Spring MVC, the “spring cleaning” may not be easily accomplished. Many of us have seen development shops stop upgrading a framework environment because of backward compatibility issues. In corporate environments, there is usually little appetite (read money) for upgrading frameworks and addressing backward compatibility issues. It can push an application under the label “legacy” too quickly.
And while the entire Java community is embracing annotations as a gift from above, I often wonder if application architects and lead developers have stopped to examine potential hazards of them as well. Mike Keith posted an excellent exploration of some of the general pros/cons regarding annotations that all should take a look at. Dave Minter and Jeff Linwood have also addressed some of the pros and cons as they relate to Hibernate’s use of annotations in their book Beginning Hibernate. Although these articles may be somewhat dated and not commenting on Spring annotations, architects and developers would benefit from a quick glance to see if some arguments (and potential issues) apply to their Spring world?
Before someone takes this posting as a diatribe against Spring, Spring MVC or annotations, allow me to caveat. As a 20 year veteran of software development and as educator of those entering our ranks, I have taken the view that it is the responsibility of any developer to inspect all sides of a software problem and solution. As I tell my students, there is no free lunch in software engineering. There are always pros and cons (I joke that those that do not believe or understand that are called sales people or consultants). An understanding of those sides is critical to success in our business. In the case of Spring MVC annotations, there is a lot on the pro side as well; ...did I mention the loose coupling?
So, what’s your take? Will the Spring stereotype model and MVC annotations help your world? If so why? If not, again why? I welcome your thoughts and comments.
If you are looking at Spring and want to learn more, I encourage you to join me in the classroom for our Complete Spring class.
But this year, Spring of a different nature arrives early. The Spring I am speaking of is the Spring Framework. Spring Framework 3.0 Milestone 1 is out (download it here), arriving in December ’08 with the final release expected… no pun intended… this spring. Major additions and changes include: requiring Java 5 and J2EE 1.4, support for RESTful Web Services, the introduction of Spring expression language (EL). To learn more about Spring 3.0, I point you to the blog and web site of the experts.
However, what I found very interesting about Spring 3.0 can be found in the Spring MVC module. In Spring 2.5, the Spring MVC framework adopted annotation-based controllers as an alternative to the large hierarchy of Spring MVC controller classes (see diagram below).
In fact, these annotation-based controllers were just one of many “stereotype” annotations. Components with stereotype annotations (let’s call the stereotypical components) are meant to clearly identify the components serving in each role of the application – especially as it relates to the model-view-controller rolled environment. The drive behind stereotypical components is that these classes do not have to extend any base class or reference a Spring, Servlet, or other API. One thing about the Spring Framework – it has always embraced loose coupling!
With the Spring Framework 3.0, I was surprised to find that the intent of the Spring project team is to take this shift in design to the next level – and to do it NOW. The MVC controller hierarchy that many in the Spring development community have become familiar with (and embraced over Struts or JSF in many cases) is being deprecated in favor of the new annotation/stereotypical model. Read the following quote from Rod Johnson (Spring founder, project lead and CEO of Spring Source) from an interview with InfoQ on Jan 22nd.
In Spring framework 3.0 there will be a number of deprecations, for example, the old MVC controller hierarchy. We view the Annotation based Spring MVC usage model that we introduced in Spring 2.5 is being a far superior replacement. That will be deprecated in Spring framework 3.0 and in the next version, whether it's 3.1 or 4.0, those classes will be removed. We don't approach deprecation the way some seem to approach deprecation, which is "Let's put a message into it" that will take years when they compile a code. Our view on deprecation is that it is a serious statement of intent. If we deprecate something we are saying "Hey, guys, it's time to think getting off this because we don't think it's a good usage model anymore." There will certainly be a bit of - if you like - Spring cleaning in the next release after Spring 3.0. Probably the most obvious part will be the Spring MVC controller hierarchy.
I applaud the Spring team for its position on deprecation. On every project I have been on, it seems there is at least one consultation with a novice developer about why using many of the java.util.Date methods is a bad idea. While Sun deals with a different extent of concerns and legacy support, I often wonder when, if ever, we’ll see Java deprecated classes and methods leave the JDK.
However, I am anxious to see how the Spring community embraces this large change. A lot of applications have been built with Spring MVC. In large enterprise applications that have embraced Spring MVC, the “spring cleaning” may not be easily accomplished. Many of us have seen development shops stop upgrading a framework environment because of backward compatibility issues. In corporate environments, there is usually little appetite (read money) for upgrading frameworks and addressing backward compatibility issues. It can push an application under the label “legacy” too quickly.
And while the entire Java community is embracing annotations as a gift from above, I often wonder if application architects and lead developers have stopped to examine potential hazards of them as well. Mike Keith posted an excellent exploration of some of the general pros/cons regarding annotations that all should take a look at. Dave Minter and Jeff Linwood have also addressed some of the pros and cons as they relate to Hibernate’s use of annotations in their book Beginning Hibernate. Although these articles may be somewhat dated and not commenting on Spring annotations, architects and developers would benefit from a quick glance to see if some arguments (and potential issues) apply to their Spring world?
Before someone takes this posting as a diatribe against Spring, Spring MVC or annotations, allow me to caveat. As a 20 year veteran of software development and as educator of those entering our ranks, I have taken the view that it is the responsibility of any developer to inspect all sides of a software problem and solution. As I tell my students, there is no free lunch in software engineering. There are always pros and cons (I joke that those that do not believe or understand that are called sales people or consultants). An understanding of those sides is critical to success in our business. In the case of Spring MVC annotations, there is a lot on the pro side as well; ...did I mention the loose coupling?
So, what’s your take? Will the Spring stereotype model and MVC annotations help your world? If so why? If not, again why? I welcome your thoughts and comments.
If you are looking at Spring and want to learn more, I encourage you to join me in the classroom for our Complete Spring class.
Subscribe to:
Posts (Atom)
