Home » Blog » Java
Categorie: Java
7 oktober 2009
Yesterday the umbrella JSR for Java EE 6 finally released a proposed final draft. This means the release of Java EE 6, a fairly large release with many tweaks and additions, is relatively imminent.
I’ve been tracking its progress for some time now and collected references to a number of articles about the major parts of Java EE 6 here: Java EE 6 progress page.
Indeed, the two most influential open source implementations (Jboss AS and Glassfish) are about to release new versions supporting Java EE 6. Naturally, Glassfish is more up to date with their support, but this time Jboss AS is hot on their heels.
Alexis of Sun wrote yesterday that “We’re fast approaching a final release of v3 with full Java EE 6 support indeed.”
Meanwhile, Jason Green of Jboss announced about a month ago that “we can put out a 5.2 beta which includes some cool EE6 capabilities. The target release date is 10/15″, which would be around next week.
So, Glassfish is about to come with full support, while Jboss AS comes with some Java EE 6 support, but whatever your favorite implementation is, it seems that enterprise Java developers are in for some interesting times.
Posted in Java | 2 Comments »
27 juni 2009
In the Java market we have a plethora of ide’s to choose from. The one I am most familiar with and also see used most often is Eclipse. Everyone knows Eclipse of course. Eclipse is not without its faults. So its natural to look around every so often. Eclipse is my baseline. At this point we arrive at IntelliJ. IntelliJ is another well known ide. I have heard IntelliJ described as the only ide for java developers, the ide that wil increase productivity 10-100 times. Its a commercial product which means you can have a reasonable expectation of stability, customer support and all the nifty tooling you would expect in Eclipse or any other ide. Naturally you expect it to be better than Eclipse or you would’t pay for it. I proceeded to download, install and put IntelliJ to use.
A few words on environment. I run Debian Lenny on a Dell Precision T-3400.
IntelliJ is an easy install. Download, unpack, run (,????, profit!). Its only 100MB compressed which is less than 150MB for Eclipse classic (and a lot less than 650MB for MyEclipse). You may need to check JDK_HOME variables but I’m guessing most people wil have this set up already. Otherwise what are you doing with a Java specific IDE. You may be confronted with a dialog or two. To begin with you should be safe with the defaults. Odds are you only need a subset of the defaults to begin with anyway.
My first impression after the install is that IntelliJ is very pretty. Especially after I changed the theme. This all went really well. Everything was fast and seemed well thought out. Of course IntelliJ has its own key mapping, menu ordering and things of that nature. If you like you can enable Eclipse key mappings but if you want to get to know a program rather than get to work quickly I recommend going with what’s totally unfamiliar. Although I am of the opinion that ctrl-s means save in any language.
The Subversion plugin works like a charm. I am even convinced it’s faster than Subversive…at least in our local environment where Subversion has, at times, been a pain to work with. If for no other reason, this plugin makes me want to use IntelliJ. If my work confined itself to talking to the repository I would be done. Forever.
So here we have a fresh working copy of our project, complete with Eclipse project files. IntelliJ understands Eclipse project files or at least so it claims. An import or two later and I have an official IntelliJ project. As far as I’m concerned I just need to point this puppy to Tomcat and we’re good to go.
Now IntelliJ has a lot of spiffy UI thingies. You got screens for configuring everything. You’ve got modules and facets. You’ve got raindrops on roses and warm woolen mittens. Confidently I configured the project to deploy to tomcat. Of course it wouldn’t work at once, that would be too much to ask. I was convinced any problems I was sure to encounter would be easy to solve.
My first problem comes in the form of compiler errors. “But wait,” you say, “did you not do a fresh checkout? Are your colleagues so daft that they enter broken code?” That would be yes and not usually. IntelliJ seems less permisive than eclipse in allowing certain constructs. Mind you Eclipse has no compile errors on the same code…so it can’t really be a compiler error since they use the same one. Ok, so its a precompile syntax validation check error or whatever. It’s not really a big deal.
Unfortunately I have no clue what IntelliJ is really doing. Somewhere there exists a tomcat. Somewhere there exists at least one copy of this tomcat. Somewhere you may or may not be deploying your project. Ok, I can actually find where IntelliJ hides its tomcat copy. Why can’t it just use my tomcat? I don’t know. Oh you can, sort of, but then you all of a sudden have to start and stop tomcat yourself. Not that I really care that IntelliJ uses a copy of tomcat, except that this copy still uses the originals directories. Sort of. I think. I’m not really sure.
A word on IntelliJ support. If you happen to write them they answer quickly. Really quickly. Actually the reply is there almost before you press compose mail. I was seriously impressed. Unfortunately they couldn’t help me and I dind’t want to rely heavily on support which is mostly meant for paying customers anyway. I also don’t like using support lines in general. It feels like a flaw in the product. Which it is.
You may be asking why I didn’t simply look up the answers in the documentation. IntelliJ documentation is one of the worst I have ever seen. It’s not worse than factually wrong information but it’s not better than a blank piece of paper. Basically if you have something labeled “Perform action” the documentation wil read “Performs the action Action”. The documentation will never actually explain what is happening or go into the details of anything.
So now I have a project which may or may not be deploying somewhere. After some looking around I do figure out I have lots of classpath problems. Also, my ant builds aren’t being run. Ok, add library here, ant build before deploy…Some progress made but not enough. My project still won’t work.
To make a long story short for about a week I’ve been playing with IntelliJ. I’ve installed, reinstalled, checked out, imported, etc, etc. I can’t get our project to work. This is a project which does work under Eclipse. So I blame IntelliJ. Where Eclipse always seems to have the thing you are looking for where you are looking for it, IntelliJ will make you search for it. Where Eclipse forces you to know what you’re doing and setup this and do that, IntelliJ has done it for you (mostly) and otherwise you can pretty much forget it.
To me IntelliJ is like a beautiful woman with a really anoying personality and a deaf ear. I really wanted to like it. Ask my colleagues, I am ready and willing to say that I hate something. I do it regularly and with passion. I do it to Eclipse all the time. Yet, despite all this, I really can’t hate IntelliJ. I would still really like to work with it. I’m convinced it could be really good. I can’t hate it and yet I can’t love it. For now it wil remain the IDE I wanted to love.
Posted in Eclipse, Java | 10 Comments »
5 december 2008
Today is a historic day for Java, as one of the leading implementations of Java EE 5, Jboss AS 5 has *finally* been released. Originally planned for early 2007 orso and promised to be released almost every quarter.
But today, no more speculation and no guessing. It’s here, and this time it’s for real! Read all about this fabulous release here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=146773
Download it from here: http://www.jboss.org/jbossas/downloads/
With Jboss officially implementing the Java EE 5 spec now, a new baseline of Java has been set. From now on, technologies like JSF 1.2, EJB3 and JPA can really be considered as basic, standard available techs.
Congrats to the Jboss team, and hoping it won’t take them as long to release Java EE 6 
References:
Posted in Java | No Comments »
24 november 2008
People have been wondering for some time about the release date of Jboss AS 5. As many of you know, Jboss 5 has been in development for quite some time and its release has been highly anticipated. Arguably, Jboss is one of the most important, if not -the- most important Java EE implementation. The fact that an official release of version 5 of this spec has been so long overdue, has been painful. Of course, Jboss 4.2.x supports most of the Java EE 5 stuff, but it’s just not the Real Thing.
The importance of Jboss AS is due to a number of reasons. Of course there are other Java EE 5 implementations out there, but the number of offerings seem to be declining. On the commercial side of the fence there’s basically IBM’s Websphere and Oracle’s OC4J, and on the open source side there’s Glassfish, Geronimo and Jboss AS 5. For many people, a closed source, commercial Java EE implementation seems to be little attractive. This leaves us basically with only 3 options for the moment. Geronimo may be nice, but nobody seems to be using this. Glassfish should maybe be the default choice (afterall, the Sun Java SE implementation is typically the default choice for many too), but has two main problems:
- It can’t be configured.
- It doesn’t offer any services.
This basically leaves Jboss AS 5 as the only choice, it it weren’t for the fact that it was always still in beta or in rc. In a way, this left a kind of void in the Java EE world (unless of course configuration and services don’t matter to you, then I suppose Glassfish would be perfectly fine).
Previously, Jboss AS 5 had been announced for february 2008 (see Where is JBossAS GA 5), but this seemed to be too optimistic. A major milestone was reached when Jboss AS 5 RC2 was officially EE 5 certified. A careful guess for the GA release date was then made for early November 2008 (see JBoss AS is now EE5 certified!).
Today however, a definite date has been given by Project Lead Dimitris Andreadis:
December 2008!
(See Jboss 5 release date?)
For those interested, these are some additional interesting resources:
Posted in Java | 9 Comments »
1 september 2008
About 2 weeks ago one of my team members, Robin Eggenkamp, mentioned there would be some iPhone dev ‘conference’ this month (iPhone Dev Camp, Amsterdam), originally at the building exactly opposite of the building where our own office is. Since I’m always interested in anything related to development I agreed to tag along. I expected it to be the kind of event where some talks are organized with a small hands on lab where some expert developer teaches newbies how to get up and running.
Now I’m certainly not a newbie when it comes to development. I lead a team of Java developers working on a rather large 200.000+ loc Java EE enterprise application and in a past life I worked as a win32/MFC C++ developer. Somewhere in between I also managed to finish a CS master. But… the iPhone was new to me. Although I’ve owned Apple computers ever since System 6 was still new & shiny, I’d never touched Xcode, Objective-C or Cocoa before. The closest I ever came was firing up Project Builder on my G3 iMac’s OS X 10.2, but only to test some C++ routine.
Because of the hands-on thing, I did plan to at least read an Objective-C tutorial the night before going to the event, but unfortunately couldn’t find the time to do so. When we arrived at the scene at exactly 10:00 in the morning, the place was already rather filled up. We found a cozy spot at a place in the back and while Robin started to connect his MacBook, I looked around and noticed it was not exactly what I thought it would be. Instead of an organized series of talks, this was a bunch of people sitting behind their computers, hacking away at stuff. The atmosphere seemed top notch though and I had a quick chat with some of the other people. At around 11 there was a short introduction talk and it became clear that the intend was to code something up for the iPhone and demo it at 17:00. The best apps would win a prize, with the first prize being a speaker set and a copy of Adobe CS3 or so.
By total coincidence, only moments after having his MacBook connected to the network, Robin finally received an email that he had been accepted for the iPhone developer program, something for which he had applied a whole month before. That meant we could start with some real development now! Robin had a little bit of experience with Xcode, but had done barely more than deploy some hello world examples to the simulator and tinkering a bit with the code. The fun thing about this was that normally whenever I need to use a new technique for my regular enterprise development, I first get myself a book of at least 600 pages, read the first 200 pages of that, try out some basic concepts, read another 200 pages, try another aspect of the tech, etc before I even attempt to apply it. Now we had to build something in a language we both didn’t know, on a platform we didn’t know, with tools we didn’t know and all of that in the course of a day 
We started thinking about what kind of application we would try to create for the iPhone and I suddenly got the idea of letting the iPhone connect to a Mac and using data from its acceleratometer to move the Mac’s mouse pointer. I started with formulating some simple milestones to reach that goal:
- Create local Mac app that moves mouse programmatically.
- Create local iPhone app that just prints accelerator values to the screen.
- Setup a connection from the iPhone to the Mac that just sends “helloâ€. Let the Mac prints this.
- Integrate the individual steps to become the app we actually want. I assumed we would need some time to calibrate the raw acceleratometer and to find a suitable mapping from the meter’s range to the pixels on the Mac’s screen.
Meanwhile Robin was attempting to deploy his hello world example app to his iPhone using his just obtained certificate. It should have been a trivial thing, but after each deployment attempt a message box was displayed saying something like “0xE8000001, your mobile device has encountered an unexpected error (0x…) during the install phase: verifying applicationâ€. We tried many things, but nothing seemed to work. While we were feverishly googling for a solution, precious time on the clock ticked away. It must have been somewhere around 13:00 when Robin finally found out which settings in the project needed to be adjusted in what way. The example hello world app deployed correctly to the iPhone and it worked! Looking at the clock we realized we only had about 4 hours to go and we hadn’t written a single line of code ourselves yet…
Milestone 1 – The local Mac app – moving the mouse
The initial plan was to build the Mac app in Cocoa, but we decided that using Java would be the fastest way for us, basically since we simply know the language and environment. This milestone was easily completed. Using the java.awt.Robot class moving the Mac’s mouse pointer was a breeze.
Milestone 2 – The local iPhone app – printing accelerator values
For this milestone we couldn’t shy away from Objective-C anymore and actually had to take the plunge. We first looked up an example for getting data from the acceleratometer and luckily Apple had provided one. The next thing was to build a simple app, barely more than a hello world, that prints these values to the screen. This proved to be a little harder. Objective-C sometimes looks like Java and sometimes doesn’t. What are those square brackets everywhere? It looked like a kind of method call, but I couldn’t really figure out the meaning of the square brackets themselves. And how where we supposed to define properties so we could take advantage of the injection features of interface builder? Using @Property seemed obvious to us, but the compiler kept generating tons of warnings and errors. And how do we organize our code? We had created an AppDelegate, which we connected in interface builder to a mainView that inherited from the Window class. We added two labels that we injected to this view class, deployed our app to the iPhone, and… nothing happened. After feeling a little silly, we actually tried to quickly read some documentation. We learned that the square brackets have no extra special meaning, it’s just the Objective-C syntax for doing a method call. @Property needed to be accompanied with a declaration in the header and another annotation in the implementation file, @synthesize, that’s there to actually generate the getter and setter. Also, when creating a new project Xcode had already created an AppDelegate for us, something we overlooked.
With this new insight we ‘almost’ got our first real code completely working, but a few small things were still not going as planned. We therefor decided to throw it all away and change our strategy; start with an existing iPhone example application and just throw away what we don’t need and add what we do need. Going that route would save us from dealing with some of the nitty-gritty.
It was 14:00 by then and lunch had started. We enjoyed our nice and free lunch and had a chat again with the other guys. It seemed to be the case that we where hopelessly behind, since we still didn’t really had anything. After lunch things started to improve though. Having some idea of the Objective-C syntax now and using some of my almost forgotten C knowledge, we were quickly able to adapt an existing app to just print the 3 accelerator values (x, y, z) to 3 separate labels. Check!
Milestone 3 – Connecting iPhone and Mac
Since we had wasted a tremendous amount of time on the deployment and second milestone, we only had little time remaining. My original plan was to have one thread on the Mac listening to incoming communication, fetching commands and dispatching these to a (blocking) queue which will be read by another thread that controls the mouse movement. For the communication we wanted to dig through the iPhone API a little to see what it had to offer. With only 2 hours remaining, we decided to use the most basic communication method available; a simple BSD socket. At the Mac side we used a simple ServerSocket in Java and at the iPhone side we used the low level C socket()/connect() functions, for which we found a basic snippet of code that needed only a few adjustments. Although absolutely not the best technical solution, we decided to create and close a connection for each message sent.
Sending a basic test string from the iPhone to the Mac worked perfectly, so a little later we were able to send the accelerator values to the Mac. Check!
Milestone 4 – Integration
We had all the separate components up and running and now only needed to integrate them together. The acceleratometer’s values appeared to be in the range of -3 to 3 for all axis, while Robin’s Mac had a 1280*800 resolution. When totally in rest, there was a certain noise margin in the values that we got from the acceleratometer, so we expected that a little calibration was required. To test a little though we started with just multiplying the values we got by 60 and added that to the current mouse position. Surprisingly this already gave fairly good results. The multiplication and the rounding down to whole pixels canceled out the noise perfectly. In a few minutes we ended up with a really simple mapping that was just something like max(0,min(forceX * 15,1280)) for the movement on the X-axis. Sending about 15 messages per second appeared to be enough for smooth motion.
By now we suddenly had some time remaining, so we used that to implement the ability to also do a mouse click. Our initial approach to that was to sent a separate message for a mouse click, but it appeared to be more robust to just add the mouse button state as a fourth parameter to the existing message. At the very last moment there was a little panic when all messages being sent appeared to be empty. Apparently, our string formatting syntax for a boolean wasn’t supported by Objective-C (we used something like “%d,%d,%d,%bâ€) or maybe there was a difference between a primitive boolean and an Object boolean. We decided not to pursue the issue and simply use the string “false†and “true†(something I normally always stay far from, but with 30 seconds on the clock remaining there wasn’t much choice). Since we had been fumbling with the code for most of the day, we figured that our chances of winning anything where rather slim. Nevertheless we were happy that we had came up with something that worked, and actually worked rather nice.
The demo
It was now time for all of us to demo our application. Among others there was a tips of the days app, an app that retrieved quotes from the Internet, a very cool looking game where you had to touch the screen to cause a kind of bubble on which a moving object bounced to another side complete with sound effects and all and a very impressive looking application that measured your air time when skiing in addition to your speed, path and direction. Unfortunately this last app appeared to be only concept art.
When it was our time for the demo, I told something about the technical shortcuts we had taken, while Robin demonstrated how to use the iPhone to paint a running man in a painting application on the Mac.
Picture by tizzle. See flickr.
Much to our surprise, our application was well received and we got the first price; a nice speaker set for the iPhone or iPod. We’ll install it in the office 
Arjan Tijms
Links:
Posted in Java, Mac OS X | 8 Comments »
27 augustus 2008
Having been recently thrown into the deep waters of JSF and Facelets it seemed natural to do an evaluation of where this technology is going. JSF is currently at version 1.2. Version 2.0 is scheduled for release with Java EE 6. So what goodies will this bring us?
The main goals of the revision is to make development easier by integrating into the core system many tools/frameworks which were built on top of previous JSF versions. Ajax support, facelets-like templating, improved development support and better performance are all things that are mentioned in the specifications.
These are the highlights of what is coming:
I’m sure everyone is familiar with Ajax. JSF 2.0 includes Ajax in its life cycle and offers more direct support for its use. The view state can now be partially updated to reflect that only part of the view has changed. Ajax will make use of the new resource handler scheme. This isn’t very exciting in and of itself. A natural progression in the way one would expect this technology to mature.
Facelets is another technology needing to be incorporated into 2.0. Facelets allows us to define our pages in a different way by using XML and templating. The way to write these pages is very close to the the way we already work, which makes it easy to learn. The added usefulness of templating allows us to write less cluttered pages. It also increases code reuse. The popularity of this approach and its obvious usefulness make it inevitable that this would be included in JSF 2.0. This is currently referred to as ‘page description language’ in the JSF specification. While the name is less exciting than Facelets it is accurate and there is no doubt that this is a welcome addition to JSF
Development for JSF is getting some support through the ‘Project_Stage’ feature. This is no more or less than a context parameter. Now many people are excited by this, but I don’t quite seem to share the sentiment. Theoretically this will allow for actions dependent on where the project is in its life. Is it in production, unit test, system test or development? The options are limited, though probably enough. What I am wondering is what it is doing in JSF. While there is a use for a setting like this, indeed it seems common in many disparate projects, it seems to me to be a higher level setting than JSF level. JSF should support it, but not claim it.
Another interesting feature is the Resource Handler. Resources are anything that could be included in a component that is required for the component to be rendered correctly to the user-agent. Think about images, JavaScript or css files. The Resource Handler enforces a structure on your resources which in and of itself just helps in organizing your project. This will also make it easier for component developers. They know exactly where to put or look for resources without having to know what application is using them. Locale and versioning are handled automatically. Another advantage is that replacing resources runtime will be much cleaner. No restart of the system should be needed.
There are some things about resources I don’t like however. First of all the specification only specifies a structure for webapps. Implementations for other platforms are even invited to do whatever they want. It seems an unfortunate choice since you really want a standard to be standard. Another is the relocatable resource. Now you can tell certain resources where they are supposed to be. Put the tag in the body but tell it to be rendered in the head. I don’t understand the reasoning for this. Perhaps if it is based on some conditional programming elsewhere on the page….but quite frankly your page is probably getting to complicated at that point. If something needs to be in the head (body, wherever), just put it there. I wonder if I am not missing some essential insight with which I will all of a sudden see what a great and useful feature this is.
One argument for relocatable resource is that components may wish to write things in locations which are outside of their direct knowledge. The head of an HTML document is an example. A component, possibly called by other components, could decide it wanted to change the head of a document. This is completely undesirable behavior. If the component is generic it should never bother with anything outside its scope. If it isn’t generic then its use is limited anyway and one could ask why it is even a component. Thinking specifically of style information I would say that this should never be overwritten at component level. Scripts can be included in the body and shouldn’t require anything beyond what exists in the component anyway. Apparently the community desires this functionality. To me it seems a harmful construct which should not be supported.
All in all I think JSF 2.0 will be an improvement of the technology. It has listened and learned from what the community has built on top of JSF and incorporated the features that were most used. As well it improves its internal workings which is never a bad thing from a user perspective. While I may not yet understand all the choices made it is obvious that the changes were well thought out and planned. Assuming the implementation is improved as well then JSF 2.0 will be pretty much what you want from version 2.0.
Jasper Floor
useful links:
Posted in Java | 6 Comments »
2 augustus 2008
Hoe vind je een goede programmeur? Programmeurs hebben verschillende hobby’s, houden van verschillende soorten muziek, hebben verschillende meningen over politiek, enz. Je loopt niet zomaar een genootschap van programmeurs binnen waar je de mensen met de juiste kennis voor het uitzoeken hebt. Waar vind je dan die goede programmeur?
E̩n ding weet ik wel Рdat iemand vroeg moet zijn begonnen met programmeren om er echt gevoel voor te krijgen. Je moet als het ware kunnen denken in nulletjes en ̩̩ntjes. Als je als kind met een Atari of een Commodore 64 hebt gespeeld Рdan ben jij er als programmeur vroeg bij geweest.
Tegenwoordig wordt je niet meer gedwongen om te weten wat programmeren is. Vroeger, met Basic, kon je eigenlijk niet anders. Vele technische ontwikkelingen hebben die ervaring overbodig gemaakt. Er zijn nu allerlei mogelijkheden om het echte programmeren te omzeilen. De programmeur die wij zoeken deinst er niet voor terug dit soort mogelijkheden links te laten liggen, en écht diep in de code te duiken.
Maar ervaring uit het verleden is niet alles. Je moet ook in staat zijn om je snel nieuwe technieken eigen te maken, en je moet veel lezen om je kennis steeds te blijven uitbreiden. En natuurlijk moet je weten waar je je computer voor kunt gebruiken. Dat programmeurs soms lui zijn is eigenlijk wel eens een goede eigenschap. Ik geloof in het woord automatisering! Laat de computer het werk maar doen.
Terug naar het onderwerp. Waar zijn de developers die we zoeken? Als je dit leest zijn we misschien klein stukje verder… Neem eens een kijkje op onze pagina Vacatures.
Met vriendelijke groeten,
Klaas
Posted in Java | 1 Comment »
28 juni 2008
On this page I will try to keep track about resources related to the upcoming release of Java EE 6.
Java EE 6 will be the next edition of the enterprise platform that powers quite a lot of (web) applications. Java EE itself consists out of a lot of sub specifications, with JSF (web) and EJB (business) being major parts of that. New for this release will be Webbeans, a specification that integrates JSF and EJB more tightly than was possible before.
JSF 2.0
Despite some early critic, JSF is becoming the default web layer technology in Java EE. In a way, JSF can be seen as a foundational technology upon which a very vibrant community is able to build exciting new solutions.
Main JSR: http://jcp.org/en/jsr/detail?id=314
Discussion:
http://www.theserverside.com/news/thread.tss?thread_id=49870
Ryan Lubke’s blog:
New features in JSF 2.0
Part 1: http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2
Part 2: http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature5
Part 3: http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature
Part 4: http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature3
Part 5: http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature1
Part 6: http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature4
Ed burns’ blog:
JSF and AJAX
http://weblogs.java.net/blog/edburns/archive/2008/02/jsf_20_update.html
Easier JSF custom components
http://weblogs.java.net/blog/edburns/archive/2007/11/jsf_usage_and_j.html
JSF 2.0 presentation
http://weblogs.java.net/blog/edburns/archive/20070628-swiss-jsf-user-group-jsf-2_0.odp
New JSF 2.0 features discussion
http://weblogs.java.net/blog/edburns/archive/2007/05/jsf_20_eg_kick.html
EJB 3.1
EJB is the part of Java EE that provides solutions for managing business code related artifacts, mainly transactions and domain entities. EJB started off in the wrong direction and especially EJB2 has received a lot of critic for being extremely cumbersome and heavyweight. EJB3 however is a complete redesign, using an ultra light approach and a very elegant design. Some say that EJB3 is actually a 1.0 version of a complete new technology. In Java EE 6, few major new additions will be done for EJB. Instead, existing functionality will be tuned and polished.
Main JSR: http://jcp.org/en/jsr/detail?id=318
New features in EJB3.1 by Reza Rahman:
Part 1: http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesinEJB3-1
Part 2: http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesEJB31
Part 3: http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesEJB31-3
Part 4: http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesinEJB3-Part4
Feedback on Reza Rahman’s articles:
Part 1: http://www.theserverside.com/news/thread.tss?thread_id=48198
Part 2: http://www.theserverside.com/news/thread.tss?thread_id=48684
Part 3: http://www.theserverside.com/news/thread.tss?thread_id=49108
Part 4: http://www.theserverside.com/news/thread.tss?thread_id=49749
JPA 2.0
JPA, Java Persistence Architecture, is the default ORM implementation in Java. Basically it allows a developer to specify a simple mapping with annotations or in XML from an Object to a relational data base table. JPA is based on existing ORM solutions like Oracle’s Toplink and Hibernate. Although originally part of EJB3, JPA has always been applicable to the entire Java platform, including Java SE. JPA 2.0 will be based on Eclipselink.
Main jsr: http://jcp.org/en/jsr/detail?id=317
Discussion:
Eclipselink for JPA 2.0
http://www.theserverside.com/news/thread.tss?thread_id=48757
Announcement
http://www.theserverside.com/news/thread.tss?thread_id=46406
Linda DeMichiel’s Blog:
http://blogs.sun.com/ldemichiel/entry/java_persistence_2_0_early
Posted in Java | No Comments »
3 april 2008
When I first started working with user interface (UI) design the process looked something like this: Take an existing paper template, copy it to the screen and make it work. What were the benefits of such approach? For one we did not have to spend much time on UI design – we simply added fields to the screen where they existed on paper. The other benefit was that people who were already familiar with the paper form had no problem understanding the UI page visible on the computer screen.
What were the drawbacks of such approach? For historical reasons paper forms were rarely ever “designedâ€. They simply grew over time until they were deemed sufficient for the task they had to perform. Using such forms as UI templates was hardly the smartest thing to do – they were a real pain to work with even in their original (paper) form, and only the most experienced of users could find their way around them. All new employees had to suffer the pains of learning those forms – no matter if on paper or on the screen – through trials and errors.
Then time came for full-fledged UI design. A new profession came into view – usability expert. Developers started to realize that copying paper forms was hardly the best and greatest when it came to user interaction. In all truth paper forms were downright evil when incorporated as-is into software – they simply functioned in a different way. The time came for input dialogs, task wizards, user-centered design – the works. Though an occasional experienced user grumbled a little after being forced to learn how to use the new UI all over again even he/she could see the benefits of the new – smarter – design. Users who were only starting with the new software were downright happy since the new UI was much easier to use than paper forms from hell.
Unfortunately it seems like the process of improving the UI stopped right there. Someone might ask what else could be done to make the UI better? After all the UI of today does everything what it needs to do, and in a sensible and efficient way.
Here is a question to think about: What is the real benefit of using computer software? Depending on who you talk to you might get a different answer:
“Computers are fast and they perform better.â€
“You can undo and redo changes with ease.â€
“Computers connected via network let you share data with other members of your organization.â€
And so on.
All those answers are valid, but to me the greatest benefit of using computers in office work is capturing the business logic. A good UI not only serves as a tool but also embeds the knowledge of business it was designed for. When a bank clerk tries to enter alphabet letters into a field called “Amount†an error message appears: “Amount is a number – enter digits!†This simple input validation step captures certain amount of knowledge of the banking industry. And this is just a simple example. Whole scripts can be created to control financial securities trade. There is software that controls robots in car factories. Each of those programs encapsulates the knowledge of how to do something.
So what can be done to make the UI better? Here are some thoughts. How about not only give people the tools to use, but also the knowledge on how to use them? A simple hover pop-up box with information on what clicking the selected button does could teach a new user how to use the UI in no time. Providing the user with a list of possible work flows (for example a list of step-by-step wizards) could explain to him/her how the business works. Not to mention including links to examples right there, on the page the user currently works with.
It is a well-known fact that people don’t read FAQs, manuals, etc. Anything longer than a sentence scares users off. That’s why “sprinkling” the interface page with small bits of helpful information – not like “in order to open a banking account you have to …”, but more like “e.g. click this, click that, enter this …” – might be a better choice for information injection. Some good examples from among the existing software are examples at the bottom of the Linux manual (man) page, or at the bottom of Ant task descriptions. Once people get used to the UI they might not need those examples anymore, but such small bits of info should cut down the overall learning curve.
Such approach would make the UI not only a tool, but also a teacher. After all people are only people, and they do make mistakes, no matter how experienced they are. Mistakes can be made when using the software, but also when explaining to another person how to use the software in question. I’ve seen this happen: people running from cubicle to cubicle, looking for answers, when the only experienced person on the floor was out for lunch.
For developers with a bit of imagination it shouldn’t be too hard to see how expert systems – and possibly AI – could be incorporated into the business logic to make a complex task execution automatic. After all computers evolve much faster than people, so the computing limits we face today might not be there tomorrow.
It is important to remember that human society is changing and that computers play greater and greater role in it with every passing day. It’s old news that more and more human-performed tasks are represented in computer software. Creating a smart UI – UI that teaches users about the business it was designed for – is a step in the right direction.
Marcin Citowicki
Posted in Java | 1 Comment »
16 oktober 2007
Working in a team with members located in different parts of the world is common today, but it’s maybe not that common for a company to bring the freedom of work regarding time and place to such an extend as M4N does.
I have been dreaming of a job with some flexibility in time. It turned out that M4N can provide me with more than I had dreamed about: located in a part of the world (Beijing) 6 hours earlier than the central office (Amsterdam), I can work at any time as long as I can make 16 hours per week, at any place with an Internet connection. M4N uses quite a few methods and tools for me to work as in a virtual local office: project management and issue tracking is done through the Trac system; an Intranet website and an office Calendar facilitate communication and coordination. I’m in the development team and the project version control is through the SVN system. For all these systems, I can use them just as the local members do. You may point out that communication with the team members could be a problem. Well, it is true that that we can not have actual face-to-face discussion or a real-life meeting, which is inconvenient, but we communicate through text or voice and video chat with MSN or skype. In fact, most often than not, team members in the same office use text chat too in order to keep the office in silence.
My working day can be like this: one o’clock in the afternoon, I make some tea and start the computer, then start MSN or skype. Working on my local computer with Internet connection, I program on my local computer but use the remote database in the M4N central office. Around 4 to 5 o’clock, my colleagues go on line. I chat with my team members of the projects now and then. Around 11 o’clock, I commit my work for the day and go off work.
M4N has quite a few distant employees like me. She has cut off the place and time boundary of the traditional cooperation, I feel so lucky to have the opportunities to enjoy the most freedom I can get from a job so far.
Hongqin Chen
Posted in Java | No Comments »
|
