blogging from reza rahman’s jee 7 talk

This month’s NY JavaSig was chock full of information about JEE 7.  It was nice seeing it before Oracle’s launch webcast.  And at a more convenient time as well!  Given that Reza Rahman works for Oracle, we got the standard Oracle disclaimer that anything can change in the next two weeks.  But we all know they don’t have time to change much so 99.9% of this should be true.  [comments in brackets are my opinions; not Reza’s or Oracle’s]
High level JEE 7 changes
  • JMS 2. Batch. Transactions. Concurrency, interceptor, web socket java api, json java api
  • El 3, jms 2′ jax-rs 2.
  • Rest like EJB are minor releases. Ejb 3.2 (interestingly CMP is from J2EE 1.3)
  • Add to web profile: jax-rs 2
  • Deprecate jax rpc, cmp, cmp, jsr 88 – no known tools to get off bmp/cmp
  • Themes are productivity and html 5, core foundational apis
Jms 2
  • 8 year old api. Needed an overhall
  • Change api to use  DI
  • Delivery delay, async send, delivery count, now standard rather than optional, mdb alignment
  • Now you just inject JMSContext and Queue – a  new Object. Reduces code from a slide to a few lines.
  • Uses default JMSContext connection factory unless specify otherwise
  • Context has createProducer() and createConsumer(). Uses builder pattern so can chain/use one liners to configure
  • New API uses runtime exceptions
  • Added JMSConnectionFactoryDefinition and JMSDestinationDefinition annotations so can configure in code instead of vendor specific descriptor. Can still use xml instead of annotations
  • MDBs have new @ActivationConfigProperty
  • Spring will be supporting JMS 2 in their apis. Will need new JMS apis as well from third party libraries.
Websockets
  • Stateful protocol. Bidirectional async communication. Good for gaming, online stock tickers, etc
  • Uses HTTO as handshake between client and server
  • Part of HTML 5. Hope people will be using within 3-5 years.
  • Very high level API
  • Supports both declarative and progamatic programming. Most people should be dealiling with declarative api.  The programmatic one is meant for third party api developers
  • Abstracts keep alive setting
  • Weakness in websocket spec: can use up all sockets on a machine
  • Keep alive packets sent about every 5 minutes (vs 30 seconds normally). If your router times out after a minute, you’ll need to reconfigure. No session replication yet. If server goes down, you lose it
  • Server side code – POJO with annotaton for serverendpoint(url)’ onopen and onclose. Onopen and onclose callbacks get passed a session. Also callbacks for onmessage and onerror.  Use session.getRemote.  To get handle to remote endpoint and call sendXXX. It is NOT an HttpSession  because you are not in http level of abstraction
  • Client – JavaScript has an api for websocket.  Use this 90 peercent of the time
Json
[feels like java util logging.  late to the party and not as good as open source libraries]
  • Have jsonp – Like xmlp?
  • Will have jsonb in future –  Like xmlb. Eclipselink has two implementations now. Moxi and eclipse link json binding. The later one is likely to be closest to the standard.
  • No safe bet. Use what exists now and change later
To use
  • JsonArray  array = Json.createArrayBuilder(). Can add primatives and objects
  • To read: parser().iterator and parser,getString()
  • iterator,nextO will return START_OBJECT, KEY_NA ME, etc in addition to the real values.  [ugly – reminds me of the early days of DOM]
JAX-RS 2
[Lost what i typed because after deleting text undo deleted still more text. I think i remembered it all to retype]
  • Jersey is an implementation as is RESTEasy
  • Jax-rs was was introduced in jee 6
  • Hypermedia support – using hyperlinks in rest, like for lazy loading
  • Cient api, message filter, entity interceptor, asnc processing for high throughput, content negotiation (queues used to apply weight to client)
  • Client api: ClientBuilder.newClient() and client.target(url, params, …  )
  • For filter implement ContainerRequestFilter
JPA 2.1
  • Schema generation – every provider supports already.  This adds a standard format. Can create database and/or ddl,   Showed examole with index names in Java and said “no other way to do it” [yuck – this is why you should separate your DDL and not store it in only in Java.  You are going to need that standalone DDL later anyway for laters so why not put the index there.]
  • Stored procedure support – people want it, all providers have it already so gave in and put it in in ORM spec.  Looks like namedqueries. @NamedStoredProcedureQuery
  • Unsynchronized persistence contexts – can join when  ready to rejoin context
  • Entity convertors – edge case solution for odd format in database field but dont want in java objects
  • Fixes/enhancement
Jta 1.2
  • Old api that needed an update. Lots of fixes and two new features
  • Declarative transactions outside EJB – any CDI object supported now. @Transactional. Default is rollback for runtime exception and ignore checked exception
  • @TransactionScoped – new CDI scope. JMSContext uses this scope
Jsf 2.2
  • Html 5 support – pass thru html 5 components. Use normal inout type=color and then jsf:value and el expression as attribute. That way not limited to jsf component libraries. Similary jsf:id, jsf:validate, jsf:renderer
  • @Flowscoped – alternative to conversation scope. Conversation was suited to wizards. Flow scoped keeps certain objects active for different parts of the app. [Code looks like a state diagram in java code – long]
  • @ViewScoped for CDI
  • Deprecated JSF managed beans. Use CDI instead
  • File upload component – couldn’t add until now because JSF was being backward compatible with 2 versions of servlet apis
  • View actions – can trigger an action when land on page rather than wait for user to click on something
  • Multi templating – templates can have parents
  • Security
Batch applications
  • Concepts. JobRepository, Job,JobOperator, Step, ItemReader, ItemProcessor, ItemWriter ( map reduce pattern with readerprocess, write)
  • The java community doesnt generally get into batch processing. Financial community is different. Hadoop and analytics starting to bring batch to wider audience
  • To code use named annotation and implement Itemreader, ItemProcessor, ItemWriter
  • Write XML for step to chunk it and send to reader, processor and writer. Methods. ReadItem, processItems, writeitems
  • IBM websphere compute grid  called out for batch multi threading on different machines.
  • IBM most active and spring second most active contributor to batch spec. Presumably that means Spring is interesting in supporting
Bean validation 1.1
  • Added method level constraints.  Useful in REST. Method param and return type constraints.  Used to only have property level
  • Bean validation artifacts injectable
Concurrency utilities for JEE
  • Builds on JSE Executor Service
  • Thread pool aware
  • Relatively low level API
  • Don’t expect a lot of people to use.  Meant for third parties running on JEE so can share app server thread pool
  • Inject ManagedExecutorService annotation. Submit your task to executor
El. 3
  • Lambda expressions, collections support, operator support
  • EJB 3.2 truncating BMP/CMP
  • Servlet api – non blocking IO
  • Ordering of interceptors
Jee 8 
  • jsonB. – probably before JEE 8
  • Jcache – available as drop in jar before. Just missed JEE 7 cutoff
  • Lots more stuff
Tomcat
  • Base Tomcat planning on supporting JSR 356 (web sockets), maybe concurrency utilities
  • TomEE – apache project taking plain tomcat and brining up to JEE web profile level. It is certified against web profile

Live Blogging with an iPad – part 2

iPad with Keyboard and DockScott wrote about his iPad live blogging from The Server Side Java Symposium flurry of posts.  While I wrote a little bit about the iPad at the time, I too wish to reflect.  My perspective is a bit different since I operated almost exclusively with the touch screen keyboard.

My path to blogging

Since this was the first time I was live blogging from my iPad, I was learning as I went.  I encountered a few things that didn’t work over the course of a day and a half.

WordPress iPad App

I was excited to see there was an app for WordPress.  I tried this app at home and it was fine.  Turns out it was fine because I was typing everything in one setting.  Problems:

  1. Despite indications to the contrary you can only have one draft in the iPad app at a time.  This wouldn’t be so bad if they provide a warning when you try to create a new draft.  Instead they silently delete the first draft.  FAIL.  I lost a whole blog entry that way.  The website indicates you can have multiple drafts, but it didn’t work when I tried it.
  2. One of my blog entries posted twice.
  3. I learned of other even worse problems that I didn’t encounter first hand.  Scared me sufficiently to jump ship though.

The WordPress web page

I started out happily typing in the wordpress app.  Then I got to a screenful of content and no scroll bars appeared.  Using one finger to scroll scrolled the whole page and not the textarea.  (see below for solution) My blog posts tend to be long.  Since I didn’t know how to scroll, I deemed the web page approach unusable and looked for a better solution.

Notes

I spent a while typing my text in Notes and copy/pasting it into the WordPress app.  This worked ok, but I got frustrated typing HTML characters.

HTML Editor

I thought HTML editor would solve my problems with Notes because it would be less tedious to type “<“.  Turns out not so much.  While the “<” was on the main screen, the “/” was still not.  (Anyone know of an HTML editor that is easier to use.)  Granted this wouldn’t be a problem on a Bluetooth keyboard because then all the keys are on a keyboard.  More importantly, the editor didn’t wrap text making it hard to read what I wrote.

The WordPress web page – redux

I later learned that you can scroll in the textarea by using two fingers.  Once I figured out how to scroll, I stayed with the web page for my blogging.  I’m wondering if the two finger scroll is supposed to be something “everyone knows” ?

The Bluetooth keyboard

Scott lent me his Bluetooth keyboard to try out for blogging a session. Unsurprisingly, it feels like a real keyboard so I touch type faster and more accurately than on the iPad directly. It’s also really easy to configure. Scott paired it to my iPad right in front of me.

I wouldn’t buy one for two reasons:

  1. The point of an iPad is to have less to lug around. I can’t see myself carrying a metal keyboard.
  2. I wouldn’t use it often so it’s not worth it for me.

Why it is useful:

  1. HTML is so much easier to type on a real keyboard. To the point where I am still actively avoiding it when typing on the iPad.
  2. It’s great having arrow keys to move between lines. Turns out I didn’t miss that at all when I was typing on the iPad because then using my finger on the touch screen was convenient. With the iPad screen a good 6 inches from my hands, I revert to my “use the keyboard over the mouse for almost everything” habits.
  3. You get a full screen on the iPad since they keyboard isn’t using half of it. While this is cool, it turns out not to matter for me, because I’m watching the speaker and only looking at the screen rarely to see what the iPad has “auto-uncorrected” for me.

Basically, it’s not better enough to be worth it for my usage pattern.

An interesting side note: I forgot the part where you have to look for a few keys when you get a new keyboard like the “end” button.

Conclusion

I’m surprised how fast my iPad typing speed has gotten. I am able to touch type with all ten fingers at a “fast enough” speed. And I can often do so without looking at the keyboard. Unless I need a single quote of course. Then I need to look to find the special symbols button.

Also, turning off autocorrect helped as Scott noted.  This helps because the iPad un-corrects technical words. There are a lot of those at a conference. The downside is that turning off auto correct also turns off spellcheck. I could still use spellcheck.

All in all, it took a day, but I am able to blog on the iPad in a sustainable fashion.  Six thousand words later, I had fun doing this.

I got a tip yesterday to turn off auto correct.

Live Blogging with an iPad

iPad with Keyboard and Dock As regular readers know, Jeanne and I blogged heavily at TheServerSide Java Symposium 2011, writing over 30 articles in a three-day period. What we may not have had time to mention is that we both did so entirely from a pair of Apple iPads. Below is a summary of some of things I learned during my experience.

1. Set up and Blogging Software
For my blogging spree, I used an Apple iPad 2 with an Apple Wireless Keyboard. I started with the WordPress iPad application, but found it too frustrating to use. The local/remote saving of articles was problematic, as Jeanne explains, and the interface felt very last-minute and cheap. I had three options remaining for blogging: the WordPress web interface in Safari, word processing software such as Apple Pages, or a plain old text editor. Since Internet was unstable at the conference, the first solution was out. I also vetoed fancy word processing software, since in the end the articles would be copied as plain text to the web browser for publishing. I settled on a plain text editor and was pleasantly surprised that my document management app, GoodReader, doubled as a text editor.

2. GoodReader as a Live Blogging Software
I liked blogging in GoodReader right away because it presented me with a full-screen text editor and my documents were always saved locally. I wrote up dozens of articles in GoodReader and then pasted each article into the WordPress web browser editor for publishing, which only took a minute. The only downside of using GoodReader was in the creation and naming of new files. By default, new text files are saved as “New File.txt”. In order to change the name of an article, you have to exit out of writing, open the file management interface, select the file, rename it, close the file management interface, and re-open the file. I would have preferred a more direct approach, such as offering me the chance to name the file when I created it. Also, a spell-checker after I had finished typing would have been nice.

3. iPad + Keyboard
Prior to this conference, I had never used my iPad with a keyboard. After writing thousands of words with the wireless keyboard, I can honestly say I would never go back to touch-typing for blogging. With the keyboard, the iPad became much closer to a real laptop — or more accurately a netbook — but was much smaller, lighter, and lasted a lot longer on a single charge than my full-sized MacBook Pro.

Advantages:

  • Easy access to special characters such as @, #, $, often used in developer presentations. Also easy access to HTML brackets for writing HTML tags quickly.
  • Arrow keys for easy navigation, particularly on web-pages with missing scroll bars. Side note: Jeanne discovered you can use two fingers to scroll in HTML windows with missing scroll bars.
  • Command-Up and Command-Down worked as Home/End keys moving the cursor to the top/bottom of the window.
  • Special keys give instant access to control brightness to prevent people from viewing what I write if I wanted to check my mail.
  • I could type faster with fewer mistakes; tactile feedback means I don’t need to look at my hands while typing.
  • Shortcut keys! I never realized how much I relied on Copy/Paste/Cut/Select All while writing until they were taken away!
  • Shortcut to show/hide on-screen keyboard using the eject button.

Limitations/Notes

  • Turn off AutoCorrect. On a keyboard mistakes are far less common and AutoCorrect often makes mistakes with technical words. Rejecting AutoCorrect suggestions interrupted typing and slowed it to a crawl since it required an on-screen click.
  • No Command-F for find, much needed feature.
  • Command-S for saving with the application. Had to touch the screen to save. This is more likely a limitation of the software than iOS, although it’s difficult know for sure.
  • The Apple Wireless Keyboard desperately needs an “Off” switch. I had a lot of issues on the final day with putting the iPad in my bag only to discover later that the battery had been drained by 10% when I wasn’t using it due to the keyboard waking up and activating.

Conclusion
I loved typing with an iPad, so long as a wireless keyboard was available. Contrasting this to JavaOne two years ago, where I had to go from presentation to presentation hunting power outlets because my MacBook could barely go half the day without power. I could honestly see taking it to business meetings and typing for hours on it. While there are still some additions I’d like to see to iOS, such as Command-F for find, the experience was quite enjoyable.