Web services are dead -- long live REST.

Once, an endless parade of Web service protocols promised to guarantee any system could talk to any other. In the end, we got much of that interoperability via simpler means

Remember the heyday of Web services, when we were always just one specification away from perfect interoperability? Ultimately, that towering stack of protocols collapsed under its own weight. SOAP and XML generally are ridiculously verbose protocols that began with a commitment to simplicity and gave way to mind-numbing levels of complexity. Add to that the service repository mess: UDDI died an ignominious death, and OASIS's S-RAMP committee can't even create a website that isn't all broken links.

Interoperability Nirvana remains out of reach. What do we have instead? We have the registry called "the freaking Internet." Services are registered as URL handlers, and we execute against them. The XML transmission format was replaced by the format that your browser and mobile devices all learned to speak: JavaScript Object Notation. REST plus JSON over HTTP/HTTPS is the new Web services -- strangely, it's more interoperable without an explicit specification. Instead we make it work like the Internet, and DNS is your service registry.

[ Also on InfoWorld: 9 app dev projects you should cancel in 2013. | Download InfoWorld's PDF of tips and trends programmers need to know in our Developers' Survival Guide. | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]

We use JQuery/JavaScript/JSON for our UIs nowadays. We can even use Node.js for our business logic. Databases like Couchbase 2.0 and MongoDB speak JavaScript and JSON (or a direct derivative) natively. The beauty of this as an architecture is that we can drop entire layers of object binding and data transformation from our code.

Brought to you by the InternetWhat does this look like? Consider your Order/Line items example.

Save or update the order:

POST http://infoworld.com/example/Order/123

{
   "firstName": "Andrew",
   "middle": "C",
   "lastName": "Oliver",
   "address": {
       "streetAddress": "345 West Main St, Suite 201",
       "city": "Durham",
       "state": "NC",
       "postalCode": 27701
   },
   "LineItems": {
       {
           "type": "widget",
           "sku": "123-456"
       },
       {
           "type": "widget",
           "number": "452-123"
       }
   }
}

Replace the line items of the order:

PUT http://infoworld/example/Order/123/LineItems
{
       {
           "type": "widgetTypeA",
           "sku": "123-456"
       },
       {
           "type": "widgetTypeB",
           "number": "452-123"
       }
   }

More: http://www.infoworld.com/d/application-development/web-services-are-dead-long-live-rest-211395 

Smartly load your properties.

Q: What is the best strategy for loading property and configuration files in Java?

A:

When you think about how to load an external resource in Java, several options immediately come to mind: files, classpath resources, and URLs. Although all of them eventually get the job done, experience shows that classpath resources and URLs are by far the most flexible and user-friendly options.

In general, a configuration file can have an arbitrarily complex structure (e.g., an XML schema definition file). But for simplicity, I assume below that we're dealing with a flat list of name-value pairs (the familiar .properties format). There's no reason, however, why you can't apply the ideas shown below in other situations, as long as the resource in question is constructed from an InputStream.

Evil java.io.File

Using good old files (via FileInputStream, FileReader, andRandomAccessFile) is simple enough and certainly the obvious route to consider for anyone without a Java background. But it is the worst option in terms of ease of Java application deployment. Using absolute filenames in your code is not the way to write portable and disk position-independent code. Using relative filenames seems like a better alternative, but remember that they are resolved relative to the JVM's current directory. This directory setting depends on the details of the JVM's launch process, which can be obfuscated by startup shell scripts, etc. Determining the setting places an unfair amount of configuration burden on the eventual user (and in some cases, an unjustified amount of trust in the user's abilities). And in other contexts (such an Enterprise JavaBeans (EJB)/Web application server), neither you nor the user has much control over the JVM's current directory in the first place.

An ideal Java module is something you add to the classpath, and it's ready to go. Think EJB jars, Web applications packaged in .warfiles, and other similarly convenient deployment strategies.java.io.File is the least platform-independent area of Java. Unless you absolutely must use them, just say no to files.

Classpath resources

Having dispensed with the above diatribe, let's talk about a better option: loading resources through classloaders. This is much better because classloaders essentially act as a layer of abstraction between a resource name and its actual location on disk (or elsewhere).

Let's say you need to load a classpath resource that corresponds to a some/pkg/resource.properties file. I use classpath resource to mean something that's packaged in one of the application jars or added to the classpath before the application launches. You can add to the classpath via the -classpath JVM option each time the application starts or by placing the file in the <jre home>\classesdirectory once and for all. The key point is that deploying a classpath resource is similar to deploying a compiled Java class, and therein lies the convenience.

You can get at some/pkg/resource.properties programmatically from your Java code in several ways. First, try:

  ClassLoader.getResourceAsStream ("some/pkg/resource.properties");
  Class.getResourceAsStream ("/some/pkg/resource.properties");
  ResourceBundle.getBundle ("some.pkg.resource");

Additionally, if the code is in a class within a some.pkg Java package, then the following works as well:

  Class.getResourceAsStream ("resource.properties");

Read more : http://www.javaworld.com/javaqa/2003-08/01-qa-0808-property.html?page=2

Guarded Blocks

http://docs.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html

Top 30 Eclipse Keyboard Shortcuts for Java Programmer

Eclipse Keyboard Shortcuts

1)      Ctrl + T for finding class even from jar

This keyboard shortcut in Eclipse is my most used and favorite shortcut. While working with high speed trading system which has complex code I often need to find classes with just blink of eye and this eclipse keyboard shortcut is just made for that. No matter whether you have class in your application or inside any JAR, this shortcut will find it.

2)      Ctrl + R for finding any resource (file) including config xml files

This is similar to above Eclipse shortcut with only difference that it can find out not only Java files but any files including xml, configs and many others, but this eclipse shortcut only finds files from your workspace and doesn’t dig at jar level.

3)      Ctrl + 1 for quick fix

This is another beautiful Eclipse shortcut which can fix up any error for you in Eclipse. Whether it’s missing declaration, missing semi colon or any import related error this eclipse shortcut will help you to quickly short that out.

4)      Ctrl + Shift + o for organize imports

Another Eclipse keyboard shortcut for fixing missing imports. Particularly helpful if you copy some code from other file and what to import all dependencies.

Eclipse Shortcut for Quick Navigation

In this section we will see some eclipse keyboard shortcut which helps to quickly navigate within file and between file while reading and writing code in Eclipse.

7) Ctrl + o for quick outline going quickly to method

9) Alt + right and Alt + left for going back and forth while editing.

12) Alt + Shift + W for show in package explorer

13) Ctrl + Shift + Up and down for navigating from member to member (variables and methods)

15) Ctrl + k and Ctrl + Shift +K for find next/previous

24) Go to a type declaration: F3, This Eclipse shortcut is very useful to see function definition very quickly.

 

Eclipse Shortcut for Editing Code

These Eclipse shortcuts are very helpful for editing code in Eclipse.

5) Ctrl + / for commenting, un commenting lines and blocks

6) Ctrl + Shift + / for commenting, un commenting lines with block comment

8) Selecting class and pressing F4 to see its Type hierarchy

10) Ctrl + F4 or Ctrl + w for closing current file

11) Ctrl+Shirt+W for closing all files.

14) Ctrl + l go to line

16) Select text and press Ctrl + Shift + F for formatting.

17) Ctrl + F for find, find/replace

18) Ctrl + D to delete a line

19) Ctrl + Q for going to last edited place

Miscellaneous Eclipse Shortcuts

These are different Eclipse keyboard shortcuts which doesn’t fit on any category but quite helpful and make life very easy while working in Eclipse.

20) Ctrl + T for toggling between super type and subtype

21) Go to other open editors: Ctrl + E.

22) Move to one problem (i.e.: error, warning) to the next (or previous) in a file: Ctrl +. For next, and Ctrl +, for previous problem

23) Hop back and forth through the files you have visited: Alt + ← and Alt + →, respectively.

25) CTRL+Shift+G, which searches the workspace for references to the selected method or variable

26) Ctrl+Shift+L to view listing for all Eclipse keyboard shortcuts.

27) Alt + Shift + j to add javadoc at any place in java source file.

28) CTRL+SHIFT+P to find closing brace. Place the cursor at opening brace and use this.

29) Alt+Shift+X, Q to run Ant build file using keyboard shortcuts in Eclipse.

30) Ctrl + Shift +F for Autoformating.

Please post if you guys have some more useful Eclipse keyboard shortcuts as comments, I will include them in this list. These Eclipse shortcuts will mostly work almost all Eclipse versions e.g. 3.5, 3.6 Helios, Eclipse Ganymede and Indigo. Let me know if you face any issue while using these Eclipse shortcuts in any particular version of Eclipse IDE.

Asus Xtion Pro test using OpenNI & OpenCV

Apache Ivy

What is Apache Ivy™ ?

Apache Ivy™ is a powerful dependencies manager with transitive dependencies support and much more features.

With Apache Ivy you define the dependencies of your module in an xml file, called an ivy-file. Then you usually ask Apache Ivy to retrieve your dependencies to a local lib dir, and it does it for you by locating the artifacts of your dependencies in repositories, such as a maven2 repository for instance.

Why should I use a dependencies manager ?

Without a dependencies manager, two solutions are often used to store the dependencies of a project: a project lib dir or direct access to a shared repository.

The major drawback of the project lib dir is that the same dependencies are stored in multiple location if you have several projects using the same dependencies. Moreover, we often see project where dependencies revisions are not documented, which can cause problems for maintenance.
With the shared repository the problem is often to maintain the list of dependencies of the project. This list is often lost within the build file, which does not help maintenance. Moreover, this solution often requires a download of the whole repository, unless home made dependencies management solution has been used.

Another major drawback of these solutions is that they do not use transitive dependencies. Transitive dependencies are the dependencies of your dependencies. Managing transitive dependencies let you declare dependencies only on what you really need, and not what the module you use themselves need. This not only eases your dependencies declaration, but it also improves a lot the maintenability of your project, especially in multi-project environment. Imagine you develop a component used in several other projects. Then each time your component needs a new dependency, without transitive dependencies, you have to update all the projects using your component ! And this could really take a lot of time !

Why should I use Apache Ivy ?

If you are convinced of using a dependencies manager, you may wonder why using Apache Ivy and not another tool. We are not able to answer this question without being biased, but have a look at Apache Ivy features and the product comparison we provide, and you will certainly see that Apache Ivy is one of the best dependencies manager currently available ;-)

How does Apache Ivy differ from Apache Maven™ ?

The answer to this question is too long, so it deserves its own page here.

Top 5 Java programming books - Best of lot.

 These top Java programming books are very good Java books and I would say best of lot. Whenever a programmer starts learning Java first question he ask is "Which Java books should I refer for learning?", That itself says, how important Java books are for programmers. Despite so much free resource available in Java in terms of tutorials, tips, blogs and code example, Java books has there own place because of two reason :

1) They are written by programmers who are authority in subject
2)They cover the subject with more details and explanation.

These Java books are my personal favorites and whenever I get some time I prefer to read them, though I have read many of them already, I always learn something new when I read them again. They are kind of best Java books available today.

1) Head First Java 
2) Effective Java
3) Thinking in Java
4) Head First Design Pattern

5) Concurrency Practice in Java
6)Java performance from Binu John
7) Java Puzzlers
8) Head First Object Oriented Analysis and Design

Read more: http://javarevisited.blogspot.com/2013/01/top-5-java-programming-books-best-good.html#ixzz2HD4bYuRY