Thoughts on the code from the frontal lobe
My take on software engineering. Y'know?
Thursday 8 May 2008, 12:13 AM
JavaOne: notes from the classroom
This blog continues the reports I’m making on perceptions of JavaOne which I am attending this week in San Francisco.
'
TS-6623 More Effective Java
Following my session experience previously detailed in my husband Adrian Bridgwater’s blog, I decided that it might advantageous to get some insight into becoming a more effective Java developer.
From this session, I took away several good practices to help my Java become more effective. First, I realized the benefits of using Enum types versus using Bit Fields. As a former C, C++ developer, I have always been very comfortable using Bit Fields (i.e. long[], long [] [] ) to represent Enums and EnumMaps. But, what I didn’t consider when using this representation was that:
1.) Bit Fields are not typesafe as there isn’t a namespace associated with them.
2.) Bit Fields do not scale beyond 64 bits.
3.) Iterating over Bit Fields is a rather tricky logic.
4.) Bit Fields can be cryptic and difficult for your fellow developers to maintain.
On the other hand, by using Enums, Jumbo Enum Sets and EnumMaps, all of the above issues are reconciled with the same fast system performance as if I were using my old-style Bit Fields.
Also, this session provided me with some insight into using generics, which was fantastic as I haven’t had a lot of practice with the generic specification. One handy mnemonic that I learned that will surely be useful is PECS (Producer Extends Consumer Super). PECS can help you remember when to employ ‘extend’ and when to employ ‘super’.
Finally, this session suggested the use of 'Lazy Initialization' when appropriate. 'Lazy Initialization' involves delaying the initialization of an object until the value is actually needed. If you want to insure a higher performance or you want to reconcile an initialization circularity, you should definitely think about this tip! I know I am!
- - - - - -
TS-5581 Upcoming Java Programming Language Changes
Moving forward with my learning objectives, I thought it was beneficial for me to push ahead and attend the upcoming Java Programming Language Changes session. This session provided me with insight into the evolutionary process as well an inkling as to what the possible new features might be.
To start with, a definite distinction was illustrated between an Application and a Language. The key difference is that an Application is rich with many features and a Language is pure and simple with few features. Moreover, creativity in a Language design can be deleterious.
To insure that the Language maintains its purity, I became aware of the three conditions that must always be adhered to. These conditions include:
1.) Respect the Past – insure that adding, modifying or removing new features does not break existing features.
2.) Respect the Future – insure that you leave room for the syntax to breath.
3.) Respect the Model – insure that the model maintains its principles with respect to OO (classes), Interfaces (Abstraction) and Actors (IPC).
Following these purity conditions, this session relayed four principles of a language evolution. These principles are as follows:
1.) Language evolution should encourage high-level languages.
2.) Language evolution should encourage code clean – more code readers than writers.
3.) Language evolution should encourage the use of static types - increases confidence in code.
4.) Language evolution should be cognizant of the fact that the language is more widespread than the APIs, which are often deprecated.
Lastly, to everyone's anticipation, this session sketched out a few of the possible new features that may be soon incorporated into the Java Programming Language. Some of these features include extensions in annotations, a multi-catch statement, a safe re-throw and a great focus on modularity in terms of packages, access controls and interfaces.
To aid with the new modularity feature, a new restricted keyword is suppose to be incorporated. This new keyword is 'module' and it is expected to be released in SE7! By using 'module', developers can create modules at the top-level package level. How exciting is that?!?
- - - - - -
I hope to report tomorrow on the below…
TS-6589 Defective Java Code: Tuning WTF Code into a Learning Experience
