Want to Build applications that run on PS3 or Blu-ray player in your living room?

Give it a shot!

It's now possible to create Java programs for Blu-ray players without a disc burner. You can go to BDLive.com hosted by Sun and RCDb and sign up for a free Blu-ray developer disk. This disk comes with a bootstrap application that enables you to run your own Blu-ray Java programs on the player.

During Java One 2008 it was announced that the developer disk you get from BDLive.com will provide a code for registering on BDlive.com.This will enable you to upload your Blu-ray Java programs on BDLive.com. The next step is to stick in the disk on your player which will automatically download your program from BDLive.com and run it on the player. This is made possible with the BD Live feature available on profile 2 Blu-ray players.

I'm waiting for my disk to be delivered to check out if it works as expected. I'm going to post more blogs on how to create fun and useful Blu-ray Java programs.

Posted at 12:53PM May 29, 2008 by jaya_hangal in Java  | 

Check out what Mustang offers in the I/O libraries

Mustang release has small but very useful enhancements in the core libraries area.
Here is a brief look at  some of them in the I/O area that you must have heard about during the  JavaOne 2005 talk given by Mark Reinhold.

Free Diskspace:

One can now discover the amount of disk space left in the partition named by
the given file. This is one of the highly voted RFE (697 votes). This is a very
handy feature, for example, installers can now determine beforehand
how much diskspace is available on a partition that it's going to install the stuff on.

Three new methods have been added to java.io.File class:

     getFreeSpace()
     getUsableSpace()
     getTotalSpace()

Using these methods one can do something like:

import java.io.*;
    :
    :
    :
  File dir;
  System.out.println("Total MB     Free    Usable");
 System.out.format(" %6d    %6d   %6d\n",
        (dir.getTotalSpace() >> 20),
        (dir.getFreeSpace() >> 20),
        (dir.getUsableSpace() >> 20));

---

Changing File Attributes:

In Mustang the java.io.File API provides access to the file attributes for changing its readability, ability to write and ability to make it executable. Check out the following methods for playing around with file attributes:

Changing readability:                            owner-only, owner or everybody
Making it writable or read-only:              owner-only, owner or everybody
Making it executable or not executable: owner-only, owner or everybody

 

---

Password Prompting:

This is one of the highly voted RFE (438 votes) as well, that fixed the good old problem of password input being echoed on a system console. This is useful for command line tools that accept password from system console, eg: keytool.

The new class  java.io.Console enables reading the password from the console
without echoing it. Here is a small code snipped that shows this:

import java.io.*;
    :
    :
    Console cons;
    char[] passwd = null;
    if ((cons = System.console()) != null)
        passwd = cons.readPassword("[%s]", "Password:");
          :
          :

---

Posted at 08:17AM Feb 16, 2006 by jaya_hangal in Java  |  Comments[1]

New bytes in Mustang release of JNDI/LDAP Service Provider

LDAP response timeout:

When an LDAP request is made by a client to a server and the server
does not respond for some reason, the client waits forever for the
server response till the TCP timeouts.
On the client-side what the user experiences is esentially a process
hang. In order to control the LDAP request in a timely manner, a read
timeout can be configured for the Sun JNDI/LDAP Service Provider
since Java SE 6, i.e mustang.

The property com.sun.jndi.ldap.read.timeout is used to specify the read
timeout.The value of this property is the string representation of an integer
representing the read timeout in milliseconds for LDAP operations.
If the LDAP provider cannot get a LDAP response within that period,
it aborts the read attempt. The integer should be greater than zero.
An integer less than or equal to zero means no read timeout is specified
which is equivalent to waiting for the response infinitely until it is received.

If this property is not specified, the default is to wait for the response until
it is received.

For example,

env.put("com.sun.jndi.ldap.read.timeout", "5000");

causes the LDAP service provider to abort the read attempt if the server
does not respond with a reply within 5 seconds.

---

Pooling Custom socket factory:

The JNDI/LDAP Service Provider allows connections from custom socket
factories to be pooled since Java SE 6 (Mustang).

Pooling of connections from a custom socket factory is allowed when
java.naming.ldap.factory.socket  environment property is set
and the custom socket factory to be pooled implements the Comparator
interface. The LDAP Service Provider calls Comparator.compare()
method for equality comparison of the socket factories whose connections
are being checked for equality by the pooling mechanism.The socket factory
comparison should ensure that the socket factory parameters that influence
the connection equality are being compared. This comparison is made
in addition to the connection identity comparison described in
How Connections are Pooled. A custom socket factory class should have
the following structure if its connections were to be pooled:

    public class CustomSocketFactory extends SocketFactory
                implements Comparator<SocketFactory> { 
       :
       :
       public int compare(SocketFactory sf1, SocketFactory sf2) {
	   :
	   :
	   // do whatever comparison that's required
       }
    }

If the socket factory class does not implement Comparator interface,
the connections from that socket factory class do not get pooled.
This requirement for implementing the Comparator interface is to ensure
that the LDAP Service Provider does the necessary checks when
comparing connections from different socket factories whose
implementation is not known to the provider.

Download mustang beta from here

Posted at 07:39AM Feb 15, 2006 by jaya_hangal in Java  |  Comments[1]

A Wild Chrismas with a little one!!

ZOO:

We saw colorful sparrows, two cobras twisted within each
other, black bears which were moving their necks in rotation
as if they were asked to do it repeatedly. We were hoping
that Rishabh would be thrilled watching all these animals. But
not all the times-- he was busy with something totally
different at times- like playing with the net kept  for the birds or
climbing the steps if he happen to come across any.

The Cheetas were sleeping but one of them was agile and was
 looking around. We tried hard for Rishabh to look at the
Cheeta but he was excited at a crow sitting next to it and ignored
our pleas to look at the Cheeta. He gets to see the crows everyday
in our backyard!!
The yellow haired monkeys that I had seen 8 years ago are were
quite amusing but now they have grown old with their hair shed off.
By then it was time to take the safari as it closes at 4:30pm.

SAFARI:

Our friends Durgam and Shachi had already got into the safari line
and we got our turn after waiting in the line for nearly 40 minutes.
But the safari ride paid for it.

In the first part of the safari, dears, bears, sambars were spotted.
But then came our wild friends tigers, cheetas and lions.
The lions and cheetas are caged. But not all the tigers are caged.

It was a thrilling experience to see the tigers gracefully walking on the
pathways, on the sides of the safari van just as if they are walking
on the roads with the traffic around. I had not seen tigers
in such a close vincinity until then. Some of them were really big ones,
and thier bodies waved as they walked. There is only one white tiger in
the park and that is left free as well. I believe in all we saw about
10-12 tigers that were freely moving about. The park is worth a visit
just for this unique experience.
The park has caged gates as you enter in which gives a feeling
of being in the Jurassic Park!

Our dear Rishabh for whose sake we went to the park promptly slept off
when the safari van took off and woke up as we were getting down
the van :) But anyway thanks to him for making us visit the park
on a bright chrismas day.

Posted at 12:29AM Dec 30, 2005 by jaya_hangal in General  | 

Problems with Pooling when using JNDI?

JNDI provides a mechanism where by the connections used by different contexts can be pooled for the purposes of sharing. Pooling is required in production systems that need to create thousands of connections.

The pooling mechanism requires that a JNDI application release resources i.e. Context references held by it by calling Context.close() and any NamingEnumeration instances created by the Context must also be closed. Closing the Context or the NamingEnumeration objects indicates to the pooling mechanism that the specific use of a connection by the Context object is over, and the connection can now be reused by a new Context that is waiting for it.

Keeping track of all the Context instances becomes cumbersome in a complex application. To aid tracking of Context objects in an application, I will try to enumerate below all the cases when a new reference to a Context is created
Developers can use this as a checklist when the connections are not being reused or released by the JNDI/LDAP pooling mechanism.

1. A Context object is obtained when lookup() methods and their variants are invoked.
   • Context.lookup()
   • Context.lookupLink()

   The lookup() method or any other API methods mentioned below returns by default a Context object unless the Service Provider finds an approrpiate Object Factory configured by the Application.

2. A Context object is returned by invoking createSubcontext() and its variant methods:
   • Context.createSubcontext()

3. A NamingEnumeration obtained as a result of any of the below API method invocation and their variants must be closed:
   • Context.list()
   • Context.listBindings()
   • DirContext.search()

4. It's not enough if the NamingEnumeration is closed, a next step is required in some cases. And some developers may not realise this step (as it's not obvious) When any of the following API methods are invoked on a Context:
   • Context.listBindings()
   • DirContext.search()

   and the search() method is configured to return Objects as below:

           SearchControls ctl = new SearchControls();
           ctl.setReturningObjFlag(true);
         

   The Object returned by the search() or the listBindings() methods could be of type Context and that needs to be closed as well:

       NamingEnumeration ne = ctx.search(...);
       while (ne.hasNext()) {
           SearchResult sr = ne.next();
           Context ctxObj = (Context) sr.getObject());
   
           // do whatever is required with ctxObj
   
           ctxObj.close();
       }
      

5. A DirContext is returned when the below Schema retrieval methods are invoked on it:
   • DirContext.getSchema()
   • DirContext.getSchemaClassDefinition()

6. A InitialLdapContext is used and a new instance of it is obtained by invoking the method:
   • InitialLdapContext.newInstance()

Posted at 12:00AM Dec 05, 2005 by jaya_hangal in Java  |  Comments[0]

$ whoami

I presently lead the JNDI API development activities at Sun. I work on Java Libraries as well. In the past I have worked on Java Security and Networking API development. In my blog here I am going to share tidbits of using the APIs/Technologies that I'm most familiar with so that the other developers can possibly benefit from it.

Posted at 11:43PM Dec 04, 2005 by jaya_hangal in General  |  Comments[0]