You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/03/03 16:39:53 UTC
J2SE 5 Plan / Roadmap
We should probably start thinking about how we'll move forward. There
have been a few casual conversations, but lets start getting some things
down here.
Re: J2SE 5 Plan / Roadmap
Posted by Paulex Yang <pa...@gmail.com>.
Nathan Beyer wrote:
Excellent document!
> This can probably be split up into a couple pieces; here are some of my
> thoughts.
>
> * JLS3 bytecode support - Can the current VM load JLS3 class files? If not,
> what's missing (besides the major.minor version header)? Can some features
> be enabled/uplifted to allow APIs to move forward? Since generics are a
> compile-time feature, can code begin using generics by just allowing the
> JLS3 major.minor version? In any case, this probably breaks down into a
> couple topics: generics, annotations, enums, return-value-covariance and
> others.
>
So far, I am using the VM provided by IBM developerworks as test
environment, which seems don't support classes produced by 5.0
compatible compiler, which will throw UnsupportedClassVersionError.
Personally I don't know how much part is missing.
> * Java 5 APIs [NEW] - Most of the brand-new APIs have been identified
> (java.lang.management, etc) and some are already being checked in. It seems
> like there's already a undocumented process here, which is to uplift and
> build any APIs to the Java 5 specification and leaving out any Java
> 5-specific language features, like generification, enums and annotations.
>
I think so, using of generics, enums, etc., can be avoid temporarily
before we get VM support, and very similar binaries can be produced.
> * Java 5 APIs [Generfication] - Once we can allow code with generics to be
> compiled and loaded, then we could begin a phase of uplifting all of the
> newly generified APIs (Collections, etc).
>
Not sure if it is too risky just to mimic JLS3 class file support in VM
by loosening the version check, because it may encourage the JSE 5
feature overusing, and some of which(annotation, for example) will
produce different class binaries which may make the poor VM mad.
> * Java 5 APIs [Annotations] - I suspect, but could be wrong, that
> Annotations support will be more difficult to implement in the VM, as there
> is some runtime support. When this is available, another phase can be
> initiated to uplift all of the APIs with the appropriate Annotations
> (@deprecated, @override, etc).
>
The class data structure has been modified to contain the annotation
information, so I agree with you, this is more a VM issue, another
significant part may be the tool(APT).
> I'm not too familiar with the JAPI tool, but if Stuart can get the Harmony
> reports to run against the Java 5 specifications, I this would provide an
> enormous boost in the arena of new Java 5 APIs. Does JAPI support JLS3
> features, like generics, annotations and enum checking?
>
From my experience by checking the JAPI result, at least the generics
is supported pretty well.
> Those are some of my thoughts at least.
>
> BTW: JLS3 == Java Language Specification, 3rd Edition
>
> -Nathan
>
There are maybe some other class library new features which requiring VM
support, the one I can bring to mind immediately is Instrumentation,
which needs VM's support of JVMTI(another big new interface!)
>
>> -----Original Message-----
>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>> Sent: Friday, March 03, 2006 9:40 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: J2SE 5 Plan / Roadmap
>>
>> We should probably start thinking about how we'll move forward. There
>> have been a few casual conversations, but lets start getting some things
>> down here.
>>
>
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: J2SE 5 Plan / Roadmap
Posted by will pugh <wi...@sourcelabs.com>.
You might also want to mention the Memory Model changes that came as
part of JSR 133.
http://java.sun.com/docs/books/jls/third_edition/html/memory.html
--Will
Nathan Beyer wrote:
>Here's a good link with a summary of some of the new features:
>http://java.sun.com/developer/technicalArticles/releases/j2se15/
>
>One of the major pieces that I missed is uplifting everything to support the
>Unicode 4.0 updates; char is now UTF-16 encoded value, etc.
>
>
>
>>-----Original Message-----
>>From: Nathan Beyer [mailto:nbeyer@kc.rr.com]
>>Sent: Friday, March 03, 2006 6:19 PM
>>To: harmony-dev@incubator.apache.org
>>Subject: RE: J2SE 5 Plan / Roadmap
>>
>>This can probably be split up into a couple pieces; here are some of my
>>thoughts.
>>
>>* JLS3 bytecode support - Can the current VM load JLS3 class files? If
>>not,
>>what's missing (besides the major.minor version header)? Can some features
>>be enabled/uplifted to allow APIs to move forward? Since generics are a
>>compile-time feature, can code begin using generics by just allowing the
>>JLS3 major.minor version? In any case, this probably breaks down into a
>>couple topics: generics, annotations, enums, return-value-covariance and
>>others.
>>
>>* Java 5 APIs [NEW] - Most of the brand-new APIs have been identified
>>(java.lang.management, etc) and some are already being checked in. It
>>seems
>>like there's already a undocumented process here, which is to uplift and
>>build any APIs to the Java 5 specification and leaving out any Java
>>5-specific language features, like generification, enums and annotations.
>>
>>* Java 5 APIs [Generfication] - Once we can allow code with generics to be
>>compiled and loaded, then we could begin a phase of uplifting all of the
>>newly generified APIs (Collections, etc).
>>
>>* Java 5 APIs [Annotations] - I suspect, but could be wrong, that
>>Annotations support will be more difficult to implement in the VM, as
>>there
>>is some runtime support. When this is available, another phase can be
>>initiated to uplift all of the APIs with the appropriate Annotations
>>(@deprecated, @override, etc).
>>
>>I'm not too familiar with the JAPI tool, but if Stuart can get the Harmony
>>reports to run against the Java 5 specifications, I this would provide an
>>enormous boost in the arena of new Java 5 APIs. Does JAPI support JLS3
>>features, like generics, annotations and enum checking?
>>
>>Those are some of my thoughts at least.
>>
>>BTW: JLS3 == Java Language Specification, 3rd Edition
>>
>>-Nathan
>>
>>
>>
>>>-----Original Message-----
>>>From: Geir Magnusson Jr [mailto:geir@pobox.com]
>>>Sent: Friday, March 03, 2006 9:40 AM
>>>To: harmony-dev@incubator.apache.org
>>>Subject: J2SE 5 Plan / Roadmap
>>>
>>>We should probably start thinking about how we'll move forward. There
>>>have been a few casual conversations, but lets start getting some things
>>>down here.
>>>
>>>
>
>
>
Re: J2SE 5 Plan / Roadmap
Posted by Dalibor Topic <ro...@kaffe.org>.
On Mon, Mar 06, 2006 at 09:21:38PM -0600, Nathan Beyer wrote:
> Alright, more specifically a char is no longer guaranteed to be a single
> Unicode character, but rather two bytes of a UTF-16 sequence.
That wasn't the case before either. Some character representations can
only reasonably be converted to unicode using several code points, and
in that case there is nothing Java can do to 'compress' the character
to a single code point, since such a code point does not exist in unicode.
cheers,
dalibor topic
>
> -----Original Message-----
> From: Richard Liang [mailto:richard.liangyx@gmail.com]
> Sent: Monday, March 06, 2006 8:10 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: J2SE 5 Plan / Roadmap
>
> Nathan Beyer wrote:
> > Maybe I didn't read this article right, but my understanding is that in
> Java
> > 5, char or at least an array of char is considered a UTF-16 sequence:
> > http://java.sun.com/developer/technicalArticles/Intl/Supplementary/
> >
> Yes, Nathan. Char sequence and char array are considered as UTF-16
> sequence. But as a data type, 'char' cannot be UTF-16. How can you
> assign a char as a Unicode character U+10FFFF?
> > Here's the important quote from this article:
> >
> > "In the end, the decision was for a tiered approach:
> > * Use the primitive type int to represent code points in low-level
> APIs,
> > such as the static methods of the Character class.
> > * Interpret char sequences in all forms as UTF-16 sequences, and
> promote
> > their use in higher-level APIs.
> > * Provide APIs to easily convert between various char and code
> > point-based representations."
> >
> >
> >
> > -----Original Message-----
> > From: Richard Liang [mailto:richard.liangyx@gmail.com]
> > Sent: Monday, March 06, 2006 7:34 PM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: J2SE 5 Plan / Roadmap
> >
> > Nathan Beyer wrote:
> >
> >> Here's a good link with a summary of some of the new features:
> >> http://java.sun.com/developer/technicalArticles/releases/j2se15/
> >>
> >> One of the major pieces that I missed is uplifting everything to support
> >>
> > the
> >
> >> Unicode 4.0 updates; char is now UTF-16 encoded value, etc.
> >>
> >>
> > 'char' cannot be UTF-16 encoded value :-) As you know, char is 16-bit
> > value in Java. However, UTF-16 encoding algorithm is:
> > For characters in range U+0000 - U+FFFF (excluding U+D800 - U+DFFF) just
> > use the same unsigned 16-bit numeric value as their UTF-16 encoded
> > value; For example, the UTF-16 encoded value for character '\u4E2D' is
> > 0x4E2D.
> > For characters in U+10000 - U+10FFFF use a surrogate pair as their
> > UTF-16 encoded value. For example, the UTF-16 encoded value for
> > character U+10000 is a 32-bit value 0xD800 0xDC00.
> >
> > Please refer to "Glossary of Unicode Terms"
> http://www.unicode.org/glossary/
> >
> > Also please forgive my prolixity :-)
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: Nathan Beyer [mailto:nbeyer@kc.rr.com]
> >>> Sent: Friday, March 03, 2006 6:19 PM
> >>> To: harmony-dev@incubator.apache.org
> >>> Subject: RE: J2SE 5 Plan / Roadmap
> >>>
> >>> This can probably be split up into a couple pieces; here are some of my
> >>> thoughts.
> >>>
> >>> * JLS3 bytecode support - Can the current VM load JLS3 class files? If
> >>> not,
> >>> what's missing (besides the major.minor version header)? Can some
> >>>
> > features
> >
> >>> be enabled/uplifted to allow APIs to move forward? Since generics are a
> >>> compile-time feature, can code begin using generics by just allowing the
> >>> JLS3 major.minor version? In any case, this probably breaks down into a
> >>> couple topics: generics, annotations, enums, return-value-covariance and
> >>> others.
> >>>
> >>> * Java 5 APIs [NEW] - Most of the brand-new APIs have been identified
> >>> (java.lang.management, etc) and some are already being checked in. It
> >>> seems
> >>> like there's already a undocumented process here, which is to uplift and
> >>> build any APIs to the Java 5 specification and leaving out any Java
> >>> 5-specific language features, like generification, enums and
> annotations.
> >>>
> >>> * Java 5 APIs [Generfication] - Once we can allow code with generics to
> >>>
> > be
> >
> >>> compiled and loaded, then we could begin a phase of uplifting all of the
> >>> newly generified APIs (Collections, etc).
> >>>
> >>> * Java 5 APIs [Annotations] - I suspect, but could be wrong, that
> >>> Annotations support will be more difficult to implement in the VM, as
> >>> there
> >>> is some runtime support. When this is available, another phase can be
> >>> initiated to uplift all of the APIs with the appropriate Annotations
> >>> (@deprecated, @override, etc).
> >>>
> >>> I'm not too familiar with the JAPI tool, but if Stuart can get the
> >>>
> > Harmony
> >
> >>> reports to run against the Java 5 specifications, I this would provide
> an
> >>> enormous boost in the arena of new Java 5 APIs. Does JAPI support JLS3
> >>> features, like generics, annotations and enum checking?
> >>>
> >>> Those are some of my thoughts at least.
> >>>
> >>> BTW: JLS3 == Java Language Specification, 3rd Edition
> >>>
> >>> -Nathan
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> >>>> Sent: Friday, March 03, 2006 9:40 AM
> >>>> To: harmony-dev@incubator.apache.org
> >>>> Subject: J2SE 5 Plan / Roadmap
> >>>>
> >>>> We should probably start thinking about how we'll move forward. There
> >>>> have been a few casual conversations, but lets start getting some
> things
> >>>> down here.
> >>>>
> >>>>
> >>
> >>
> >
> >
> >
>
>
> --
> Richard Liang
> China Software Development Lab, IBM
>
>
Re: J2SE 5 Plan / Roadmap
Posted by Richard Liang <ri...@gmail.com>.
Nathan Beyer wrote:
> Alright, more specifically a char is no longer guaranteed to be a single
> Unicode character, but rather two bytes of a UTF-16 sequence.
>
Agree :-)
> -----Original Message-----
> From: Richard Liang [mailto:richard.liangyx@gmail.com]
> Sent: Monday, March 06, 2006 8:10 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: J2SE 5 Plan / Roadmap
>
> Nathan Beyer wrote:
>
>> Maybe I didn't read this article right, but my understanding is that in
>>
> Java
>
>> 5, char or at least an array of char is considered a UTF-16 sequence:
>> http://java.sun.com/developer/technicalArticles/Intl/Supplementary/
>>
>>
> Yes, Nathan. Char sequence and char array are considered as UTF-16
> sequence. But as a data type, 'char' cannot be UTF-16. How can you
> assign a char as a Unicode character U+10FFFF?
>
>> Here's the important quote from this article:
>>
>> "In the end, the decision was for a tiered approach:
>> * Use the primitive type int to represent code points in low-level
>>
> APIs,
>
>> such as the static methods of the Character class.
>> * Interpret char sequences in all forms as UTF-16 sequences, and
>>
> promote
>
>> their use in higher-level APIs.
>> * Provide APIs to easily convert between various char and code
>> point-based representations."
>>
>>
>>
>> -----Original Message-----
>> From: Richard Liang [mailto:richard.liangyx@gmail.com]
>> Sent: Monday, March 06, 2006 7:34 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: J2SE 5 Plan / Roadmap
>>
>> Nathan Beyer wrote:
>>
>>
>>> Here's a good link with a summary of some of the new features:
>>> http://java.sun.com/developer/technicalArticles/releases/j2se15/
>>>
>>> One of the major pieces that I missed is uplifting everything to support
>>>
>>>
>> the
>>
>>
>>> Unicode 4.0 updates; char is now UTF-16 encoded value, etc.
>>>
>>>
>>>
>> 'char' cannot be UTF-16 encoded value :-) As you know, char is 16-bit
>> value in Java. However, UTF-16 encoding algorithm is:
>> For characters in range U+0000 - U+FFFF (excluding U+D800 - U+DFFF) just
>> use the same unsigned 16-bit numeric value as their UTF-16 encoded
>> value; For example, the UTF-16 encoded value for character '\u4E2D' is
>> 0x4E2D.
>> For characters in U+10000 - U+10FFFF use a surrogate pair as their
>> UTF-16 encoded value. For example, the UTF-16 encoded value for
>> character U+10000 is a 32-bit value 0xD800 0xDC00.
>>
>> Please refer to "Glossary of Unicode Terms"
>>
> http://www.unicode.org/glossary/
>
>> Also please forgive my prolixity :-)
>>
>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Nathan Beyer [mailto:nbeyer@kc.rr.com]
>>>> Sent: Friday, March 03, 2006 6:19 PM
>>>> To: harmony-dev@incubator.apache.org
>>>> Subject: RE: J2SE 5 Plan / Roadmap
>>>>
>>>> This can probably be split up into a couple pieces; here are some of my
>>>> thoughts.
>>>>
>>>> * JLS3 bytecode support - Can the current VM load JLS3 class files? If
>>>> not,
>>>> what's missing (besides the major.minor version header)? Can some
>>>>
>>>>
>> features
>>
>>
>>>> be enabled/uplifted to allow APIs to move forward? Since generics are a
>>>> compile-time feature, can code begin using generics by just allowing the
>>>> JLS3 major.minor version? In any case, this probably breaks down into a
>>>> couple topics: generics, annotations, enums, return-value-covariance and
>>>> others.
>>>>
>>>> * Java 5 APIs [NEW] - Most of the brand-new APIs have been identified
>>>> (java.lang.management, etc) and some are already being checked in. It
>>>> seems
>>>> like there's already a undocumented process here, which is to uplift and
>>>> build any APIs to the Java 5 specification and leaving out any Java
>>>> 5-specific language features, like generification, enums and
>>>>
> annotations.
>
>>>> * Java 5 APIs [Generfication] - Once we can allow code with generics to
>>>>
>>>>
>> be
>>
>>
>>>> compiled and loaded, then we could begin a phase of uplifting all of the
>>>> newly generified APIs (Collections, etc).
>>>>
>>>> * Java 5 APIs [Annotations] - I suspect, but could be wrong, that
>>>> Annotations support will be more difficult to implement in the VM, as
>>>> there
>>>> is some runtime support. When this is available, another phase can be
>>>> initiated to uplift all of the APIs with the appropriate Annotations
>>>> (@deprecated, @override, etc).
>>>>
>>>> I'm not too familiar with the JAPI tool, but if Stuart can get the
>>>>
>>>>
>> Harmony
>>
>>
>>>> reports to run against the Java 5 specifications, I this would provide
>>>>
> an
>
>>>> enormous boost in the arena of new Java 5 APIs. Does JAPI support JLS3
>>>> features, like generics, annotations and enum checking?
>>>>
>>>> Those are some of my thoughts at least.
>>>>
>>>> BTW: JLS3 == Java Language Specification, 3rd Edition
>>>>
>>>> -Nathan
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>>>>> Sent: Friday, March 03, 2006 9:40 AM
>>>>> To: harmony-dev@incubator.apache.org
>>>>> Subject: J2SE 5 Plan / Roadmap
>>>>>
>>>>> We should probably start thinking about how we'll move forward. There
>>>>> have been a few casual conversations, but lets start getting some
>>>>>
> things
>
>>>>> down here.
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>
>
>
--
Richard Liang
China Software Development Lab, IBM
RE: J2SE 5 Plan / Roadmap
Posted by Nathan Beyer <nb...@kc.rr.com>.
Alright, more specifically a char is no longer guaranteed to be a single
Unicode character, but rather two bytes of a UTF-16 sequence.
-----Original Message-----
From: Richard Liang [mailto:richard.liangyx@gmail.com]
Sent: Monday, March 06, 2006 8:10 PM
To: harmony-dev@incubator.apache.org
Subject: Re: J2SE 5 Plan / Roadmap
Nathan Beyer wrote:
> Maybe I didn't read this article right, but my understanding is that in
Java
> 5, char or at least an array of char is considered a UTF-16 sequence:
> http://java.sun.com/developer/technicalArticles/Intl/Supplementary/
>
Yes, Nathan. Char sequence and char array are considered as UTF-16
sequence. But as a data type, 'char' cannot be UTF-16. How can you
assign a char as a Unicode character U+10FFFF?
> Here's the important quote from this article:
>
> "In the end, the decision was for a tiered approach:
> * Use the primitive type int to represent code points in low-level
APIs,
> such as the static methods of the Character class.
> * Interpret char sequences in all forms as UTF-16 sequences, and
promote
> their use in higher-level APIs.
> * Provide APIs to easily convert between various char and code
> point-based representations."
>
>
>
> -----Original Message-----
> From: Richard Liang [mailto:richard.liangyx@gmail.com]
> Sent: Monday, March 06, 2006 7:34 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: J2SE 5 Plan / Roadmap
>
> Nathan Beyer wrote:
>
>> Here's a good link with a summary of some of the new features:
>> http://java.sun.com/developer/technicalArticles/releases/j2se15/
>>
>> One of the major pieces that I missed is uplifting everything to support
>>
> the
>
>> Unicode 4.0 updates; char is now UTF-16 encoded value, etc.
>>
>>
> 'char' cannot be UTF-16 encoded value :-) As you know, char is 16-bit
> value in Java. However, UTF-16 encoding algorithm is:
> For characters in range U+0000 - U+FFFF (excluding U+D800 - U+DFFF) just
> use the same unsigned 16-bit numeric value as their UTF-16 encoded
> value; For example, the UTF-16 encoded value for character '\u4E2D' is
> 0x4E2D.
> For characters in U+10000 - U+10FFFF use a surrogate pair as their
> UTF-16 encoded value. For example, the UTF-16 encoded value for
> character U+10000 is a 32-bit value 0xD800 0xDC00.
>
> Please refer to "Glossary of Unicode Terms"
http://www.unicode.org/glossary/
>
> Also please forgive my prolixity :-)
>
>>
>>
>>> -----Original Message-----
>>> From: Nathan Beyer [mailto:nbeyer@kc.rr.com]
>>> Sent: Friday, March 03, 2006 6:19 PM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: RE: J2SE 5 Plan / Roadmap
>>>
>>> This can probably be split up into a couple pieces; here are some of my
>>> thoughts.
>>>
>>> * JLS3 bytecode support - Can the current VM load JLS3 class files? If
>>> not,
>>> what's missing (besides the major.minor version header)? Can some
>>>
> features
>
>>> be enabled/uplifted to allow APIs to move forward? Since generics are a
>>> compile-time feature, can code begin using generics by just allowing the
>>> JLS3 major.minor version? In any case, this probably breaks down into a
>>> couple topics: generics, annotations, enums, return-value-covariance and
>>> others.
>>>
>>> * Java 5 APIs [NEW] - Most of the brand-new APIs have been identified
>>> (java.lang.management, etc) and some are already being checked in. It
>>> seems
>>> like there's already a undocumented process here, which is to uplift and
>>> build any APIs to the Java 5 specification and leaving out any Java
>>> 5-specific language features, like generification, enums and
annotations.
>>>
>>> * Java 5 APIs [Generfication] - Once we can allow code with generics to
>>>
> be
>
>>> compiled and loaded, then we could begin a phase of uplifting all of the
>>> newly generified APIs (Collections, etc).
>>>
>>> * Java 5 APIs [Annotations] - I suspect, but could be wrong, that
>>> Annotations support will be more difficult to implement in the VM, as
>>> there
>>> is some runtime support. When this is available, another phase can be
>>> initiated to uplift all of the APIs with the appropriate Annotations
>>> (@deprecated, @override, etc).
>>>
>>> I'm not too familiar with the JAPI tool, but if Stuart can get the
>>>
> Harmony
>
>>> reports to run against the Java 5 specifications, I this would provide
an
>>> enormous boost in the arena of new Java 5 APIs. Does JAPI support JLS3
>>> features, like generics, annotations and enum checking?
>>>
>>> Those are some of my thoughts at least.
>>>
>>> BTW: JLS3 == Java Language Specification, 3rd Edition
>>>
>>> -Nathan
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>>>> Sent: Friday, March 03, 2006 9:40 AM
>>>> To: harmony-dev@incubator.apache.org
>>>> Subject: J2SE 5 Plan / Roadmap
>>>>
>>>> We should probably start thinking about how we'll move forward. There
>>>> have been a few casual conversations, but lets start getting some
things
>>>> down here.
>>>>
>>>>
>>
>>
>
>
>
--
Richard Liang
China Software Development Lab, IBM
Re: J2SE 5 Plan / Roadmap
Posted by Richard Liang <ri...@gmail.com>.
Nathan Beyer wrote:
> Maybe I didn't read this article right, but my understanding is that in Java
> 5, char or at least an array of char is considered a UTF-16 sequence:
> http://java.sun.com/developer/technicalArticles/Intl/Supplementary/
>
Yes, Nathan. Char sequence and char array are considered as UTF-16
sequence. But as a data type, 'char' cannot be UTF-16. How can you
assign a char as a Unicode character U+10FFFF?
> Here's the important quote from this article:
>
> "In the end, the decision was for a tiered approach:
> * Use the primitive type int to represent code points in low-level APIs,
> such as the static methods of the Character class.
> * Interpret char sequences in all forms as UTF-16 sequences, and promote
> their use in higher-level APIs.
> * Provide APIs to easily convert between various char and code
> point-based representations."
>
>
>
> -----Original Message-----
> From: Richard Liang [mailto:richard.liangyx@gmail.com]
> Sent: Monday, March 06, 2006 7:34 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: J2SE 5 Plan / Roadmap
>
> Nathan Beyer wrote:
>
>> Here's a good link with a summary of some of the new features:
>> http://java.sun.com/developer/technicalArticles/releases/j2se15/
>>
>> One of the major pieces that I missed is uplifting everything to support
>>
> the
>
>> Unicode 4.0 updates; char is now UTF-16 encoded value, etc.
>>
>>
> 'char' cannot be UTF-16 encoded value :-) As you know, char is 16-bit
> value in Java. However, UTF-16 encoding algorithm is:
> For characters in range U+0000 - U+FFFF (excluding U+D800 - U+DFFF) just
> use the same unsigned 16-bit numeric value as their UTF-16 encoded
> value; For example, the UTF-16 encoded value for character '\u4E2D' is
> 0x4E2D.
> For characters in U+10000 - U+10FFFF use a surrogate pair as their
> UTF-16 encoded value. For example, the UTF-16 encoded value for
> character U+10000 is a 32-bit value 0xD800 0xDC00.
>
> Please refer to "Glossary of Unicode Terms" http://www.unicode.org/glossary/
>
> Also please forgive my prolixity :-)
>
>>
>>
>>> -----Original Message-----
>>> From: Nathan Beyer [mailto:nbeyer@kc.rr.com]
>>> Sent: Friday, March 03, 2006 6:19 PM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: RE: J2SE 5 Plan / Roadmap
>>>
>>> This can probably be split up into a couple pieces; here are some of my
>>> thoughts.
>>>
>>> * JLS3 bytecode support - Can the current VM load JLS3 class files? If
>>> not,
>>> what's missing (besides the major.minor version header)? Can some
>>>
> features
>
>>> be enabled/uplifted to allow APIs to move forward? Since generics are a
>>> compile-time feature, can code begin using generics by just allowing the
>>> JLS3 major.minor version? In any case, this probably breaks down into a
>>> couple topics: generics, annotations, enums, return-value-covariance and
>>> others.
>>>
>>> * Java 5 APIs [NEW] - Most of the brand-new APIs have been identified
>>> (java.lang.management, etc) and some are already being checked in. It
>>> seems
>>> like there's already a undocumented process here, which is to uplift and
>>> build any APIs to the Java 5 specification and leaving out any Java
>>> 5-specific language features, like generification, enums and annotations.
>>>
>>> * Java 5 APIs [Generfication] - Once we can allow code with generics to
>>>
> be
>
>>> compiled and loaded, then we could begin a phase of uplifting all of the
>>> newly generified APIs (Collections, etc).
>>>
>>> * Java 5 APIs [Annotations] - I suspect, but could be wrong, that
>>> Annotations support will be more difficult to implement in the VM, as
>>> there
>>> is some runtime support. When this is available, another phase can be
>>> initiated to uplift all of the APIs with the appropriate Annotations
>>> (@deprecated, @override, etc).
>>>
>>> I'm not too familiar with the JAPI tool, but if Stuart can get the
>>>
> Harmony
>
>>> reports to run against the Java 5 specifications, I this would provide an
>>> enormous boost in the arena of new Java 5 APIs. Does JAPI support JLS3
>>> features, like generics, annotations and enum checking?
>>>
>>> Those are some of my thoughts at least.
>>>
>>> BTW: JLS3 == Java Language Specification, 3rd Edition
>>>
>>> -Nathan
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>>>> Sent: Friday, March 03, 2006 9:40 AM
>>>> To: harmony-dev@incubator.apache.org
>>>> Subject: J2SE 5 Plan / Roadmap
>>>>
>>>> We should probably start thinking about how we'll move forward. There
>>>> have been a few casual conversations, but lets start getting some things
>>>> down here.
>>>>
>>>>
>>
>>
>
>
>
--
Richard Liang
China Software Development Lab, IBM
RE: J2SE 5 Plan / Roadmap
Posted by Nathan Beyer <nb...@kc.rr.com>.
Maybe I didn't read this article right, but my understanding is that in Java
5, char or at least an array of char is considered a UTF-16 sequence:
http://java.sun.com/developer/technicalArticles/Intl/Supplementary/
Here's the important quote from this article:
"In the end, the decision was for a tiered approach:
* Use the primitive type int to represent code points in low-level APIs,
such as the static methods of the Character class.
* Interpret char sequences in all forms as UTF-16 sequences, and promote
their use in higher-level APIs.
* Provide APIs to easily convert between various char and code
point-based representations."
-----Original Message-----
From: Richard Liang [mailto:richard.liangyx@gmail.com]
Sent: Monday, March 06, 2006 7:34 PM
To: harmony-dev@incubator.apache.org
Subject: Re: J2SE 5 Plan / Roadmap
Nathan Beyer wrote:
> Here's a good link with a summary of some of the new features:
> http://java.sun.com/developer/technicalArticles/releases/j2se15/
>
> One of the major pieces that I missed is uplifting everything to support
the
> Unicode 4.0 updates; char is now UTF-16 encoded value, etc.
>
'char' cannot be UTF-16 encoded value :-) As you know, char is 16-bit
value in Java. However, UTF-16 encoding algorithm is:
For characters in range U+0000 - U+FFFF (excluding U+D800 - U+DFFF) just
use the same unsigned 16-bit numeric value as their UTF-16 encoded
value; For example, the UTF-16 encoded value for character '\u4E2D' is
0x4E2D.
For characters in U+10000 - U+10FFFF use a surrogate pair as their
UTF-16 encoded value. For example, the UTF-16 encoded value for
character U+10000 is a 32-bit value 0xD800 0xDC00.
Please refer to "Glossary of Unicode Terms" http://www.unicode.org/glossary/
Also please forgive my prolixity :-)
>
>> -----Original Message-----
>> From: Nathan Beyer [mailto:nbeyer@kc.rr.com]
>> Sent: Friday, March 03, 2006 6:19 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: RE: J2SE 5 Plan / Roadmap
>>
>> This can probably be split up into a couple pieces; here are some of my
>> thoughts.
>>
>> * JLS3 bytecode support - Can the current VM load JLS3 class files? If
>> not,
>> what's missing (besides the major.minor version header)? Can some
features
>> be enabled/uplifted to allow APIs to move forward? Since generics are a
>> compile-time feature, can code begin using generics by just allowing the
>> JLS3 major.minor version? In any case, this probably breaks down into a
>> couple topics: generics, annotations, enums, return-value-covariance and
>> others.
>>
>> * Java 5 APIs [NEW] - Most of the brand-new APIs have been identified
>> (java.lang.management, etc) and some are already being checked in. It
>> seems
>> like there's already a undocumented process here, which is to uplift and
>> build any APIs to the Java 5 specification and leaving out any Java
>> 5-specific language features, like generification, enums and annotations.
>>
>> * Java 5 APIs [Generfication] - Once we can allow code with generics to
be
>> compiled and loaded, then we could begin a phase of uplifting all of the
>> newly generified APIs (Collections, etc).
>>
>> * Java 5 APIs [Annotations] - I suspect, but could be wrong, that
>> Annotations support will be more difficult to implement in the VM, as
>> there
>> is some runtime support. When this is available, another phase can be
>> initiated to uplift all of the APIs with the appropriate Annotations
>> (@deprecated, @override, etc).
>>
>> I'm not too familiar with the JAPI tool, but if Stuart can get the
Harmony
>> reports to run against the Java 5 specifications, I this would provide an
>> enormous boost in the arena of new Java 5 APIs. Does JAPI support JLS3
>> features, like generics, annotations and enum checking?
>>
>> Those are some of my thoughts at least.
>>
>> BTW: JLS3 == Java Language Specification, 3rd Edition
>>
>> -Nathan
>>
>>
>>> -----Original Message-----
>>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>>> Sent: Friday, March 03, 2006 9:40 AM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: J2SE 5 Plan / Roadmap
>>>
>>> We should probably start thinking about how we'll move forward. There
>>> have been a few casual conversations, but lets start getting some things
>>> down here.
>>>
>
>
>
--
Richard Liang
China Software Development Lab, IBM
Re: J2SE 5 Plan / Roadmap
Posted by Richard Liang <ri...@gmail.com>.
Nathan Beyer wrote:
> Here's a good link with a summary of some of the new features:
> http://java.sun.com/developer/technicalArticles/releases/j2se15/
>
> One of the major pieces that I missed is uplifting everything to support the
> Unicode 4.0 updates; char is now UTF-16 encoded value, etc.
>
'char' cannot be UTF-16 encoded value :-) As you know, char is 16-bit
value in Java. However, UTF-16 encoding algorithm is:
For characters in range U+0000 - U+FFFF (excluding U+D800 - U+DFFF) just
use the same unsigned 16-bit numeric value as their UTF-16 encoded
value; For example, the UTF-16 encoded value for character '\u4E2D' is
0x4E2D.
For characters in U+10000 - U+10FFFF use a surrogate pair as their
UTF-16 encoded value. For example, the UTF-16 encoded value for
character U+10000 is a 32-bit value 0xD800 0xDC00.
Please refer to "Glossary of Unicode Terms" http://www.unicode.org/glossary/
Also please forgive my prolixity :-)
>
>> -----Original Message-----
>> From: Nathan Beyer [mailto:nbeyer@kc.rr.com]
>> Sent: Friday, March 03, 2006 6:19 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: RE: J2SE 5 Plan / Roadmap
>>
>> This can probably be split up into a couple pieces; here are some of my
>> thoughts.
>>
>> * JLS3 bytecode support - Can the current VM load JLS3 class files? If
>> not,
>> what's missing (besides the major.minor version header)? Can some features
>> be enabled/uplifted to allow APIs to move forward? Since generics are a
>> compile-time feature, can code begin using generics by just allowing the
>> JLS3 major.minor version? In any case, this probably breaks down into a
>> couple topics: generics, annotations, enums, return-value-covariance and
>> others.
>>
>> * Java 5 APIs [NEW] - Most of the brand-new APIs have been identified
>> (java.lang.management, etc) and some are already being checked in. It
>> seems
>> like there's already a undocumented process here, which is to uplift and
>> build any APIs to the Java 5 specification and leaving out any Java
>> 5-specific language features, like generification, enums and annotations.
>>
>> * Java 5 APIs [Generfication] - Once we can allow code with generics to be
>> compiled and loaded, then we could begin a phase of uplifting all of the
>> newly generified APIs (Collections, etc).
>>
>> * Java 5 APIs [Annotations] - I suspect, but could be wrong, that
>> Annotations support will be more difficult to implement in the VM, as
>> there
>> is some runtime support. When this is available, another phase can be
>> initiated to uplift all of the APIs with the appropriate Annotations
>> (@deprecated, @override, etc).
>>
>> I'm not too familiar with the JAPI tool, but if Stuart can get the Harmony
>> reports to run against the Java 5 specifications, I this would provide an
>> enormous boost in the arena of new Java 5 APIs. Does JAPI support JLS3
>> features, like generics, annotations and enum checking?
>>
>> Those are some of my thoughts at least.
>>
>> BTW: JLS3 == Java Language Specification, 3rd Edition
>>
>> -Nathan
>>
>>
>>> -----Original Message-----
>>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>>> Sent: Friday, March 03, 2006 9:40 AM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: J2SE 5 Plan / Roadmap
>>>
>>> We should probably start thinking about how we'll move forward. There
>>> have been a few casual conversations, but lets start getting some things
>>> down here.
>>>
>
>
>
--
Richard Liang
China Software Development Lab, IBM
RE: J2SE 5 Plan / Roadmap
Posted by Nathan Beyer <nb...@kc.rr.com>.
Here's a good link with a summary of some of the new features:
http://java.sun.com/developer/technicalArticles/releases/j2se15/
One of the major pieces that I missed is uplifting everything to support the
Unicode 4.0 updates; char is now UTF-16 encoded value, etc.
> -----Original Message-----
> From: Nathan Beyer [mailto:nbeyer@kc.rr.com]
> Sent: Friday, March 03, 2006 6:19 PM
> To: harmony-dev@incubator.apache.org
> Subject: RE: J2SE 5 Plan / Roadmap
>
> This can probably be split up into a couple pieces; here are some of my
> thoughts.
>
> * JLS3 bytecode support - Can the current VM load JLS3 class files? If
> not,
> what's missing (besides the major.minor version header)? Can some features
> be enabled/uplifted to allow APIs to move forward? Since generics are a
> compile-time feature, can code begin using generics by just allowing the
> JLS3 major.minor version? In any case, this probably breaks down into a
> couple topics: generics, annotations, enums, return-value-covariance and
> others.
>
> * Java 5 APIs [NEW] - Most of the brand-new APIs have been identified
> (java.lang.management, etc) and some are already being checked in. It
> seems
> like there's already a undocumented process here, which is to uplift and
> build any APIs to the Java 5 specification and leaving out any Java
> 5-specific language features, like generification, enums and annotations.
>
> * Java 5 APIs [Generfication] - Once we can allow code with generics to be
> compiled and loaded, then we could begin a phase of uplifting all of the
> newly generified APIs (Collections, etc).
>
> * Java 5 APIs [Annotations] - I suspect, but could be wrong, that
> Annotations support will be more difficult to implement in the VM, as
> there
> is some runtime support. When this is available, another phase can be
> initiated to uplift all of the APIs with the appropriate Annotations
> (@deprecated, @override, etc).
>
> I'm not too familiar with the JAPI tool, but if Stuart can get the Harmony
> reports to run against the Java 5 specifications, I this would provide an
> enormous boost in the arena of new Java 5 APIs. Does JAPI support JLS3
> features, like generics, annotations and enum checking?
>
> Those are some of my thoughts at least.
>
> BTW: JLS3 == Java Language Specification, 3rd Edition
>
> -Nathan
>
> > -----Original Message-----
> > From: Geir Magnusson Jr [mailto:geir@pobox.com]
> > Sent: Friday, March 03, 2006 9:40 AM
> > To: harmony-dev@incubator.apache.org
> > Subject: J2SE 5 Plan / Roadmap
> >
> > We should probably start thinking about how we'll move forward. There
> > have been a few casual conversations, but lets start getting some things
> > down here.
RE: J2SE 5 Plan / Roadmap
Posted by Nathan Beyer <nb...@kc.rr.com>.
This can probably be split up into a couple pieces; here are some of my
thoughts.
* JLS3 bytecode support - Can the current VM load JLS3 class files? If not,
what's missing (besides the major.minor version header)? Can some features
be enabled/uplifted to allow APIs to move forward? Since generics are a
compile-time feature, can code begin using generics by just allowing the
JLS3 major.minor version? In any case, this probably breaks down into a
couple topics: generics, annotations, enums, return-value-covariance and
others.
* Java 5 APIs [NEW] - Most of the brand-new APIs have been identified
(java.lang.management, etc) and some are already being checked in. It seems
like there's already a undocumented process here, which is to uplift and
build any APIs to the Java 5 specification and leaving out any Java
5-specific language features, like generification, enums and annotations.
* Java 5 APIs [Generfication] - Once we can allow code with generics to be
compiled and loaded, then we could begin a phase of uplifting all of the
newly generified APIs (Collections, etc).
* Java 5 APIs [Annotations] - I suspect, but could be wrong, that
Annotations support will be more difficult to implement in the VM, as there
is some runtime support. When this is available, another phase can be
initiated to uplift all of the APIs with the appropriate Annotations
(@deprecated, @override, etc).
I'm not too familiar with the JAPI tool, but if Stuart can get the Harmony
reports to run against the Java 5 specifications, I this would provide an
enormous boost in the arena of new Java 5 APIs. Does JAPI support JLS3
features, like generics, annotations and enum checking?
Those are some of my thoughts at least.
BTW: JLS3 == Java Language Specification, 3rd Edition
-Nathan
> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> Sent: Friday, March 03, 2006 9:40 AM
> To: harmony-dev@incubator.apache.org
> Subject: J2SE 5 Plan / Roadmap
>
> We should probably start thinking about how we'll move forward. There
> have been a few casual conversations, but lets start getting some things
> down here.