Wednesday Jun 12, 2013

Interesting Java EE Problem

I ran into an unexpected problem the other day while working on a Java EE application. We deployed our entire application stack, which ran fine under GlassFish 2ur2, to GlassFish 3.1.2.2, using the compatibility=v2 property for deploying, as we're moving to GF3. After some testing, one of our features threw a TransactionRollbackException stating 'A system exception occurred during an invocation on an EJB'. I expected issues while migrating, but this one I hadn't seen before. The code is packaged in the following way:

server.ear
   |-LIB1.jar (contains a persistence.xml)
   |-EJB1.ejb
   |-EJB2.ejb
   |-EJB3.ejb
   |-EJB4.ejb (contains a persistence.xml)

All 4 EJB's include LIB1. The call stack looks like this (simplified):

EJB1 -> EJB2 -> EJB3 -> DB

A search value is passed from EJB1 to EJB2 to EJB3 to be searched for in the DB. The return value is an Entity Bean (EB) which represents the data from the row in the DB. Digging into the code and debugging, I saw that the returned EB was not null and contained the proper data, right up to EJB2. Once the EB was returned to EJB1, the EB was not null, but was empty! All of the values in the fields were null. I was able to return other EB's, complete with their data in tact, using this same mechanism. So the problem had to do with this particular EB.

After doing some research, it looked like the problem might be EclipseLink's weaving feature, which performs byte-code manipulation to optimize the class. So I added the requisite eclipselink.weaving=false property to the persistence.xml. This, however, did not solve the problem. I then noticed that both persistence.xml files in this EAR defined separate Persistence Unit's (PU's), and both PU's referenced a handful of the same classes (including the one I was seeing the problem with). Aha!, a breadcrumb to chase. LIB1 contains utility classes as well as EB's which are shared among all of the EJB's. The EB's required in EJB1, EJB2, and EJB4 are all listed in LIB1's persistence.xml. EJB4 also already includes LIB1. So I removed the persistence.xml in EJB4...and problem solved.

Wednesday May 15, 2013

Series On Embedded Development (Part 6) - Power Efficiency

Let's not forget efficieny as it pertains to power...important for embedded devices, especially battery powered ones. I mentioned avoiding idle tasks in the last installment and the suggestions here build on that same theme (CPU (therefore power) conservation):

Avoid inefficient polling - inefficient polling will keep the CPU busy and waste power. You should spend time thinking about your polling algorithm and optimize it to reduce CPU usage. Can you poll when the CPU isn't being utilized much?

Avoid idling and block waiting on asynchronous events - these are also things which will consume CPU. Instead of waiting, implement a listener pattern so your application is event-driven.

Provide quiet periods to allow the CPU to sleep - any time the CPU is asleep, power is being conserved.

Don’t assume there are multiple CPU cores - coding for multiple cores can place a demand on a single-core machine. Try to code efficiently for the machine you'll be running on.

Tuesday Apr 16, 2013

Series On Embedded Development (Part 5) - Efficiency

In this 5th installment of Embedded Development, I'm going to talk about efficiency. Efficiency has to do with, well, being efficient. It has to do with not being wasteful...not doing things which don't need to be done. It also has to do with doing things more efficiently...doing things you wouldn't normally do to have more efficient code.

A good example of this is moving fields to helper classes. If you have a class which contains fields which aren't used often, consider moving them to a helper class which contains sparsely-used fields. You will save memory and CPU cycles when the fields are not used. The memory and CPU will only be incurred when the fields are used. This is something you wouldn't normally do. I'm not talking about fields shared by multiple classes, which you do put into shared classes. This falls under the category of making your Java classes efficient (read smaller, using less memory, and less CPU in the typical case).

Related to moving fields to helper classes is grouping like-used fields together in shared classes. If you put too few fields in too many classes, you'll end up burning CPU and memory instantiating too many fields. Put fields which are likely to be used by the same functionality in shared classes. This is especially useful when the fields are static.

Simply eliminate extra fields. This one should be obvious, but if you've removed a reference to a field, make sure the field is still needed. A good IDE can help with this.

Use smaller buffers. This is related to the cache discussion in 'Part 4 - Tunability'. When using buffers, you should make them small and grow them as needed. Growing your buffers will incur some CPU cycles *when they grow*, but only then. Take care to ensure you don't make them too small and grow them in too small chunks. Testing and profiling will help find the sweet spot.

Use the smallest data type you can for each field. Do you really need a long or will an integer do just as well? Do you really need an integer or will a short do just as well. I rarely see the use of shorts. Most of the time I see ints used.

Keep stack frames small. This is especially important in recursive calls.

Avoid idle tasks which prevent the CPU from sleeping or going into low-power mode.

Usually once you start thinking in terms of efficiency (size/memory, less code/CPU) rather than just functionality and performance, you'll start getting creative ideas for keeping data structures smaller. Don't forget to get creative with your data structure layouts as well!

Friday Jan 11, 2013

Series On Embedded Development (Part 4) - Tunability

Writing a tunable application means writing your application in such a way that you can change it's behavior. This is different then having functionality available or not (optionality), it's changing the behavior of your application based on various factors. There's really two types of tunability, build-time and runtime. Within runtime tunability, there's also two types...static and dynamic.

Build-time tunability is when you set certain parameters at build-time. For example, if you use a cache and set the cache size based on a constant in your Java code, you're setting the cache size at build-time. Chaning a build-time tunable feature means you have to (obviously) re-build your application to change it's behavior. If you want to allow the users of your application to change it's behavior, then they'll need to be able to build your application to change it's behavior.

Runtime tunability is when your application changes it's behavior at runtime, so you don't have to re-build for to change its behavior. Runtime tunability can be static, set once when you run the JVM, or dynamic, changing based on certain criteria. The JVM uses runtime static tunability in several ways. One way it uses it is in the heap size. You can change the JVM heap size using a command-line parameter when you run the JVM. Another way is with the garbage collection. You can change the the JVM's garbage collector (GC) by specifying the GC on the command-line when starting the JVM. Both of these change the behavior of the JVM while it's running. Runtime dynamic tunability is when your application changes its behavior based on certain criteria it detects while it's running. For example, if you use large cache's in your application by default, but reduce the cache size when memory gets low, your using runtime dynamic tunability. Runtime tunability is more flexible then build-time and runtime dynamic is even more flexible then runtime static. Runtime dynamic allows your application to adapt as needed on the fly. However, it can be slower as you have to detect the criteria that trigger changes and then change the behavior of your application appropriately. With runtime dynamic tunability, you can move your application from device to device without having to make code changes, rebuild your application, or re-start it.

Tuesday Nov 27, 2012

Series On Embedded Development (Part 3) - Runtime Optionality

What is runtime optionality? Runtime optionality means writing and packaging your code in such a way that all of the features are available at runtime, but aren't loaded and used if the feature isn't used. The code is separate, and you can even remove the code to save persistent storage if you know the feature will not be used.

In native programming terms, it's splitting your application into separate shared libraries so you only have to load what you're using, which means it only impacts volatile memory when enabled at runtime. All the functionality is there, but if it's not used at runtime, it's not loaded. A good example of this in Java is JVMTI, Java's Virtual Machine Tool Interface. On smaller, embedded platforms, these libraries may not be there. If the libraries are not there, there's no effect on the runtime as long as you don't try to use the JVMTI features.

There is a trade-off between size/performance and flexibility here. Putting code in separate libraries means loading that code will take longer and it will typically take up more persistent space. However, if the code is rarely used, you can save volatile memory by including it in a separate library. You can also use this method in Java by putting rarely-used code into one or more separate JAR's. Loading a JAR and parsing it takes CPU cycles and volatile memory. Putting all of your application's code into a single JAR means more processing for that JAR. Consider putting rarely-used code in a separate library/JAR.

Thursday Nov 01, 2012

Series On Embedded Development (Part 2) - Build-Time Optionality

In this entry on embedded development, I'm going to discuss build-time optionality (BTO). BTO is the ability to subset your software at build-time so you only use what is needed. BTO typically pertains more to software providers rather then developers of final products. For example, software providers ship source products, frameworks or platforms which are used by developers to build other products.

If you provide a source product, you probably don't have to do anything to support BTO as the developers using your source will only use the source they need to build their product. If you provide a framework, then there are some things you can do to support BTO. Say you provide a Java framework which supports audio and video. If you provide this framework in a single JAR, then developers who only want audio are forced to ship their product with the video portion of your framework even though they aren't using it. In this case, support providing the framework in separate JARs...break the framework into an audio JAR and a video JAR and let the users of your framework decide which JARs to include in their product. Sometimes this is as simple as packaging, but if, for example, the video functionality is dependent on the audio functionality, it may require coding work to cleanly separate the two.

BTO can also work at install-time, and this is sometimes overlooked. Let's say your building a phone application which can use Near Field Communications (NFC) if it's available on the phone, but it doesn't require NFC to work. Typically you'd write one app for all phones (saving you time)...both those that have NFC and those that don't, and just use NFC if it's there. However, for better efficiency, you can detect at install-time if the phone supports NFC and not install the NFC portion of your app if the phone doesn't support NFC. This requires that you write the app so it can run without the optional NFC code and that you write your install app so it can detect NFC and do the right thing at install-time. Supporting install-time optionality will save persistent footprint on the phone, something your customers will appreciate, your app "neighbors" will appreciate, and that you'll appreciate when they save static footprint for you.

In the next article, I'll writing about runtime optionality.

Wednesday Oct 24, 2012

Series On Embedded Development (Part 1)

This is the first in a series of entries on developing applications for the embedded environment. Most of this information is relevant to any type of embedded development (and even for desktop and server too), not just Java. This information is based on a talk Hinkmond Wong and I gave at JavaOne 2012 entitled Reducing Dynamic Memory in Java Embedded Applications.

One thing to remember when developing embeddded applications is that memory matters. Yes, memory matters in desktop and server environments as well, but there's just plain less of it in embedded devices. So I'm going to write about saving this precious resource as well as another precious resource, CPU cycles...and a bit about power too. CPU matters too, and again, in embedded devices, there's just plain less of it. What you'll find, no surprise, is that there's a trade-off between performance and memory. To get better performance, you need to use more memory, and to save more memory, you need to need to use more CPU cycles.

I'll be discussing three Memory Reduction Categories:

- Optionality, both build-time and runtime. Optionality is about providing options so you can get rid of the stuff you don't need and include the stuff you do need.

- Tunability, which is about providing options so you can tune your application by trading performance for size, and vice-versa.

- Efficiency, which is about balancing size savings with performance.

Tuesday Sep 25, 2012

Oracle Unveils Oracle Java Embedded Suite 7.0

Today Oracle announced the Oracle Java Embedded Suite 7.0. What is the Java Embedded Suite (JES)? It's a middleware stack designed to be run on embedded devices. It's a suite which includes an application server (Glassfish for Embedded Suite), database (Java DB), and web services (Jersey Web Services Framework). Putting these services on the embedded device gives you the ability to provide a set of services at the device point. It also lets you aggregate data at the device point, which you can later sync with your enterprise systems.

Friday May 25, 2012

Speeding up NetBeans Scanning

If you've ever experienced slow scanning while using NetBeans, as I have, I suggest you give one of the 7.2 daily builds a try (http://www.netbeans.org, click the 'Download FREE' button, click on the 'Development' link near the top right, and choose the download option which works for you). One of 7.2's features is background scanning, which does just what the name says. I have found it significantly improves the user experience as it relates to scanning...much less time is spent "waiting" for the scanning to complete. Version 201205250002 works very well, although I don't see a way to pick a specific dev build. If you get a build with a problem, try again later when a newer version is released. This upgrade is definitely worth while.

Thursday Apr 14, 2011

Group Tabs in Firefox

I recently stumbled on a useful feature in Firefox 4, Group Tabs. Group tabs let you group the tabs you have open in Firefox into convenient groups of your choosing. I found this by hitting the button to the right of the tabs list drop-down in the upper-right corner of Firefox, just above the home icon. Once there, you'll see a group frame window which contains all of your tabs in the form of icons representing each tab. To create another group, click and drag an icon outside of the group. You'll see the icon by itself in no group, and if you click on the tab icon, you'll see a new Firefox window open with just that tab in it. Clicking on the Group Tabs icon will get you back to managing your group tabs. To continue creating your group, click and drag another tab icon and drop it on or near the previous tab icon. You'll see a frame display around the two tab icons. This represents the new group. You can name the group by clicking near the top of the group frame (there's a faint pencil icon to the left of the edit box). Resizing the group tab frame will automatically re-size the tab icons. If you click on a tab icon, Firefox will display a window with only the tabs from the group in it, with the selected tab displayed. You'll notice if you hit the tabs drop-down, you'll only see the tabs listed which are in that group. Clicking back on the Group Tab icon will take you back to managing the group tabs. You can close tabs and move them between groups easily.

Using the Group Tab interface makes it easy to manage and find tabs when you have a lot of tabs open. You can find more information on Firefox's Group Tabs here: http://support.mozilla.com/en-US/kb/what-are-tab-groups

Wednesday Mar 16, 2011

Oracle ADF Mobile

Oracle recently announced the availability of the Oracle ADF Mobile client. Combined with Oracle JDeveloper, you can quickly build Java ME based mobile applications in offline and online modes for the device and the mobile browser, which utilize these capabilities: logic services, database access, security, user interface framework, and data binding.

Wednesday Feb 03, 2010

Oracle + Sun Product Strategy Webcast Series

For anyone interested on where Sun/Oracle is headed, you can check out the webcast series. There are webcasts of every area: hardware, software, systems, solutions, and partners. You can also find information on the various products here.

Monday Sep 28, 2009

Trust your Instinct(s)


Add the recently released Samsung Instinct HD (available exclusively on Sprint and available now at Best Buy) to the growing list of JavaME consumer devices. This device is pretty special though. Why? Because it's the first device to combine the two JavaME stacks (CDC and CLDC) and to include OSGi into the mix. This device has an OSGi implementation running on top of a CDC stack, and running MIDP on top of OSGi. The application model generally used on the device is MIDP, but at some point it could allow running other OSGi applications and CDC applications as well. There's a lot of capability built into this phone.

Monday Jun 15, 2009

2009 JavaOne Presentations Online


If you missed JavaOne this year, possibly due to the economic downturn and the ever tightening of corporate belts, do not despair. The technical presentations presented at JavaOne are now available to Sun Developer Network members (this membership is free) here: 2009 JavaOne Technical Sessions. If you missed the keynotes, you can view replays of those here: 2009 JavaOne Conference. Granted, you don't get to mingle with other Java developers, but there's lots of good information in the presentations and contact information if you want to get more information on a particular presentation. It's the next best thing to being there.

Wednesday Jan 14, 2009

Launchy Keystroke Launcher


I just found a really nice utility named Launchy. Launchy is a utility which is always in the background. You bring it up by hitting a key combination (Alt-Space is the default). It displays a simple box into which you can type commands to launch applications (e.g. firefox). Launchy indexes your hard drive and creates a catalog of the files on your system. When you start typing, Launchy suggests an application in which you might be interested. When it finds an application, it displays the applications icon and the name of the application. If it found the correct application, you can just hit the Enter key and it will launch the application. If it didn't find the correct one, you can hit the down arrow to see a list of all applications which match.

On Windows, Launchy indexes what is in your Start menu by default. You can modify this list. You can also change the default key combination to bring up Launchy. You can also enter file names into Launchy and it will launch that file using the default application for that file. For those of us who don't like reaching for the mouse, Launchy is a really useful utility.

Does anyone remember Borland's Sidekick?
About

Darryl Mocek

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today