Problem with applet in IE7

Had problems with loading a applet(that tries to connect using socket) in IE7 using JRE1.5. It used to work in IE6. Was getting the socketPermission error although the java.policy file in the user home had socketPermission for accept, connect, resolve. Then I added the same socketPermission entry in the java.policy file under the security folder of the JRE installed directory. It then worked. Thus, IE7 doesn't check the java.policy file present in the user home. Instead it checks the same present in the JRe installed directory. Bug or enhancement in IE7?

Java Tips

Cases when a closing curly brace is followed by semi-colon

1. anonymous inner class
2. array initialization using {}

Difference between Stored Procedure and Function

Stored Procedure :supports deffered name resoultion Example while writing a stored procedure that uses table named tabl1 and tabl2 etc..but actually not exists in database is allowed only in during creation but runtime throws error
Function wont support deffered name resolution. Stored procedure returns always integer value by default zero. where as function return type could be scalar or table or table values(SQL Server).Stored Procedure is pre compiled exuction plan where as functions are not.

Bug in asList method of class Arrays - Java Tiger: Reply

Not a bug, but I agree it's very surprising. Look at the declaration of asList():

public static <T> List<T> asList(T... a)

"T", like all generic type parameters, has to be a reference type. If you pass an array of reference types, then T becomes the type of that reference, and the individual array elements become the arguments to the function.

But if you pass a primitive array to this function, "T" is assigned the primitive array type itself -- int[], in your example -- and the function sees a single argument of that type. It has to be so, because T can't be assigned to type "int". That "1" is therefore indicating that the function saw the array as a single unit.

Bug in asList method of class Arrays - Java Tiger

asList method of Arrays returns a list. This list corresponding to the primitive array has a odd behaviour. E.g.,

String[] sa = {"one", "two", "three", "four"};
List sList = Arrays.asList(sa);
System.out.println("size of list : " + sList.size());

This prints the size as 4. This is fine. However, the same code for primitive array produces the size as always 1.

int[] ia = {1,2,3};
List iList = Arrays.asList(ia);
System.out.println("size of primitive list : " + iList.size());

This prints the size as 1. Is this a bug?

Making trace files available

There is an undocumented parameter _trace_files_public that if set to true changes the file permissions in the user_dump_dest directory when trace files are created to allow everyone to read them. This parameter can be checked with the following SQL. You can set this parameter by adding the following line to the init.ora file:
# allow trace files to be created with public permissions
_trace_files_public=true
SQL to check the value of this parameter:
SQL> select x.ksppinm name,y.ksppstvl value
from sys.x$ksppi x,sys.x$ksppcv y
where x.inst_id=userenv('Instance')
and y.inst_id=userenv('Instance')
and x.indx=y.indx
and x.ksppinm='_trace_files_public';

Who eats my Temp Space

Many a times we get the error : "TEMP SEGMENT MAXIMUM EXTENT EXCEEDED". The following script will provide a list of users and which processes occupy space in the TEMP tablespace.

SET pagesize 10000; 
    SET linesize 133; 
    column tablespace format a15 heading 'Tablespace Name'; 
    column segfile# format 9,999 heading 'File|ID'; 
    column spid format 9,999 heading 'Unix|ID'; 
    column segblk# format 999,999,999 heading 'Block|ID'; 
    column size_mb format 999,999,990.00 heading "Mbytes|Used"; 
    column username format a15; 
    column program format a15; 
SELECT 
    b.tablespace,
    b.segfile#,
    b.segblk#,
    round(((b.blocks*p.value)/1024/1024),2 ) size_mb ,
    a.sid,
    a.serial#,
    a.username,
    a.osuser,
    a.program,
    a.status 
FROM v$session a ,
    v$sort_usage b ,
    v$process c ,
    v$parameter p 
WHERE p.name='db_block_size' 
    AND a.saddr = b.session_addr 
    AND a.paddr=c.addr 
ORDER BY b.tablespace,
    b.segfile#,
    b.segblk#,
    b.blocks 
/

Confirmed my understanding

In the earlier blog, the character not being displayed properly by the browser is the browser issue and the code to deal with supplementary character is correct. The link http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=10177 shows the character that will be displayed in browser(which is the one present in xml file when opened by browser). So, to work with supplementary characters, create new String by passing character[] containing the low and high surrogate pairs or the byte[] specifying the encoding. The byte[] can for any code point can be obtained using the link :
Byte for codepoint

Some code to illustrate the unicode support by Character class

public class UnicodeTest{
public static void main(String... args) throws IOException
{
System.out.println("is valid codepoint : " + Character.isValidCodePoint(0x10FFFF));
System.out.println("is valid codepoint : " + Character.isValidCodePoint(0x20FFFF));
int cp = 0x10177;
System.out.println("is valid codepoint : " + Character.isValidCodePoint(cp));
char[] ch = new char[2];
ch = Character.toChars(cp);
int low = ch[0];
int high = ch[1];
System.out.println("Low Surrogate Pair : " + low + " Hexadecimal : " + Integer.toHexString(low) + " Binary String : " + Integer.toBinaryString(low));
System.out.println("High Surrogate Pair : " + high + " Hexadecimal : " + Integer.toHexString(high) + " Binary String : " + Integer.toBinaryString(high));
String st = new String(ch);
BufferedWriter out = new BufferedWriter(new OutputStreamWriter(new FileOutputStream("krishna.xml"), "UTF-8"));
out.write("");
out.write("");
out.write(st);
out.write("");
out.close();

}
}

In the above case, the supplementary character written in xml was not the one it is intended to be. Don't know whether it is the limitation of browser to display the supplementary characters or anything wrong in the way a supplementary character be handled in java code.

Some more understandings on java unicode support

From the start, java had used UTF-16 encoding for encoding the characters. Thus, in the earlier stages when the unicode character set was limited to 16 bits and hence was given full support by java character which was using the utf-16 encoding. Once the unicode was extended to support till the range U+10FFFF, the earlier UTF-16 encoded characters cannot represent characters more than U+FFFF. Hence, in J2se5, support was provided through the Character class. So, the primitive char still supports only the characters till code point: UTF+FFFF. The Java 2 platform uses the UTF-16 representation in char arrays and in the String and StringBuffer classes. In this representation, supplementary characters are represented as a pair of char values, the first from the high-surrogates range, (\uD800-\uDBFF), the second from the low-surrogates range (\uDC00-\uDFFF).

A char value, therefore, represents Basic Multilingual Plane (BMP) code points, including the surrogate code points, or code units of the UTF-16 encoding. An int value represents all Unicode code points, including supplementary code points. The lower (least significant) 21 bits of int are used to represent Unicode code points and the upper (most significant) 11 bits must be zero. Unless otherwise specified, the behavior with respect to supplementary characters and surrogate char values is as follows:

* The methods that only accept a char value cannot support supplementary characters. They treat char values from the surrogate ranges as undefined characters. For example, Character.isLetter('\uD840') returns false, even though this specific value if followed by any low-surrogate value in a string would represent a letter.
* The methods that accept an int value support all Unicode characters, including supplementary characters. For example, Character.isLetter(0x2F81A) returns true because the code point value represents a letter (a CJK ideograph).

Back to Unicode support in java

Again got confused in unicode. Some of the terms used are:
1. Coded Character Set
A character Set(collection of characters) where each character has been assigned a unique number. E.g., Unicode character set, where every character is assigned a hexadecimal number.
2. Code Points
The numbers that can be used in a coded character set. Valid code points for Unicode character set is : U+0000 to U+10FFFF (Unicode :4 standard)
3. Supplementary Characters
Characters that could not be represented in the original 16-bit design of Unicode. U+0000 to U+FFFF are referred to as Base Multilingual Plane(BMP) and the others are supplementary characters.
4. Character Encoding Scheme
Mapping from the numbers of one or more coded character sets to sequences of one or more fixed-width code units. e.g., UTF-32, UTF-16, and UTF-8
4. Character Encoding
Mapping from a set of characters to sequences of code units. e.g., UTF-8, ISO-8859-1, GB18030, Shift_JIS.

UTF-16
UTF-16 uses sequences of one or two unsigned 16-bit code units to encode Unicode code points. Values U+0000 to U+FFFF are encoded in one 16-bit unit with the same value. Supplementary characters are encoded in two code units, the first from the high-surrogates range (U+D800 to U+DBFF), the second from the low-surrogates range (U+DC00 to U+DFFF). This may seem similar in concept to multi-byte encodings, but there is an important difference: The values U+D800 to U+DFFF are reserved for use in UTF-16; no characters are assigned to them as code points. This means, software can tell for each individual code unit in a string whether it represents a one-unit character or whether it is the first or second unit of a two-unit character. This is a significant improvement over some traditional multi-byte character encodings, where the byte value 0x41 could mean the letter "A" or be the second byte of a two-byte character.

Least Integer to lose precision when converted to Floating point

The first integer at which assigning to float and casting back to int loses precision is : 16777217. The following code when run, gives the output as:

    class Q44 
    	   { 
    	      public static void main(String[] args) 
    	      { 
    		 int i=0, y;
    		 float j=0;
    		 while(true)
    		 {
    			 j = i;
    			 y=(int)j;
    			 if( (y-i) != 0)
    			 {
    				 System.out.println("i = " + i);
    				 break;
    			 }
    			 i++;
    		 }
    		 i = -1;
    		 while(true)
    		 {
    			 j = i;
    			 y=(int)j;
    			 if( (y-i) != 0)
    			 {
    				 System.out.println("i = " + i);
    				 break;
    			 }
    			 i--;
    		 }		 
    			 
    			 
    	     } 
    	   }    

i = 16777217
i = -16777217

Floating points are first converted to form : N = ± (1.b1b2b3b4 ...)2 x 2+E
The left most one is not stored(always 1). The bits b1b2b3 etc.,(upto 23 bits) is what goes into the mantissa part. Hence, the first maximum bit for an integer can be 24 successive one's. (23 One's for mantissa and one implicit 1). 24 successive one corresponds to the number : 16777215. The next number is 16777216 for which the bit pattern is : 1000000000000000000000000
ie., one followed by 24 zero. So, even though the 24th zero is not stored, precision is not lost. Because when we convert back it is restored. So, the maximum integer without losing precision that can be converted back from float is now : 16777216

Now, if we consider the next number (16777217) for which the bit pattern is : 1000000000000000000000001. This has 1 followed by 23 zeros and then a 1. Because of 1 in the 24th bit, the 23rd bit will be rounded to 1 and the first precision loss comes for this number. Thus, the number 16777217 is the first integer number which when converted to float and converted back to integer will lose the precision as proved by the output of the above code.

.Net Framework

Was feeling lazy to work today. Hence, looked at .net framework programming......Some highlights of points learnt for future reference
1. .Net currently supports around 20 languages to be compiled into IL(Intermediate Language) format.
2. For shift from J2EE to dot net, c# can be a better option.
3. A simple helloworld C# code is:
class App{
public static void Main(){
System.Console.WriteLine("Hello World!");
}
}
4. To compile the above code, type "csc filename.cs". This generates the filename.exe. (for vb, use vbc and for javascript, jsc)
5. Hierarchy : Managed Executable -> CLR(JIT compilation) -> OS
6. CLR is similar to the other execution engine like JVM for J2EE. The CLR supplies memory management, type safety, code verifiability, thread management and security.
7. Important points are

• Managed Code is never interpreted

• Managed code doesn't run in virtual machine.

8. CIL(Common IL) is the high level assembly language includes instructions for advanced programming concepts as instantiating objects or calling virtual functions.
9. The CLR translates these and every other IL instruction into a native machine language instruction at runtime, and then executes the code natively.
10. Metadata describes class definitions, method signatures, parameter types and return values.
11. The exe generated out of compiling the managed code contains the metadata and the IL. We can use the IL disassemebler(ILDASM) to view the structure of the managed exe.
12. At runtime, this exe is JIT compiled by the CLR and converted into the machine language instructions.
13. Some of the benchmarck results shows dot net executed code is 2-3 times faster than the J2EE...

JIT COMPILATION
The first time that a managed executable references a class or type (such as a structure, interface, enumerated type or primitive type) the system must load the code module or managed module that implements the type. At the point of loading, the JIT compiler creates method stubs in native machine language for every member method in the newly loaded class. These stubs include nothing but a jump into a special function in the JIT compiler.

Once the stub functions are created, the system fixes up any method calls in the referencing code to point to the new stub functions. At this time no JIT compilation of the type's code has occurred. However, if a managed application references a managed type, it is likely to call methods on this type (in fact it is almost inevitable).

When one of the stub functions is called the stub causes execution to jump into the JIT compiler. The JIT compiler looks up the source code (IL and metadata) in the associated managed module, and builds native machine code for the function on the fly. Then, it replaces the stub function with a jump to the newly JIT compiled function. The next time this same method is called in source code, it will be executed full speed without any need for compilation or extra steps.

The good thing about this approach is that the system never wastes time JIT compiling methods that won't be called by this run of your application.