6609441 : Ch] Enumerated types for general category and directionality in Character class
Hello All,
I would like to work on this RFE.
This change is quite simple and gives greater value to the Character class.
The change can be done without breaking any existing code by adding
the following enums in the Character class.
/**
* An enum for all the GeneralCategory values. The ordinal values
for these enums are compatible with the
* corresponding byte values as returned by the getType method.
* @since 1.7
*/
public enum GeneralCategory {
/**
* General category Cn in the Unicode specification.
* @since 1.7
*/
UNASSIGNED(Cn),// = 0;
/**
* General category Lu in the Unicode specification.
* @since 1.7
*/
UPPERCASE_LETTER(Lu),//= 1;
/**
* General category Ll in the Unicode specification.
* @since 1.7
*/
LOWERCASE_LETTER(Ll),//= 2;
/**
* General category Lt in the Unicode specification.
* @since 1.7
*/
TITLECASE_LETTER(Lt),//= 3;
/**
* General category Lm in the Unicode specification.
* @since 1.7
*/
MODIFIER_LETTER(Lm),// = 4;
/**
* General category Lo in the Unicode specification.
* @since 1.7
*/
OTHER_LETTER(Lo),//= 5;
/**
* General category Mn in the Unicode specification.
* @since 1.7
*/
NON_SPACING_MARK(Mn),//= 6;
/**
* General category Me in the Unicode specification.
* @since 1.7
*/
ENCLOSING_MARK(Me),// = 7;
/**
* General category Mc in the Unicode specification.
* @since 1.7
*/
COMBINING_SPACING_MARK(Mc),// = 8;
/**
* General category Nd in the Unicode specification.
* @since 1.7
*/
DECIMAL_DIGIT_NUMBER(Nd),//= 9;
/**
* General category Nl in the Unicode specification.
* @since 1.7
*/
LETTER_NUMBER(Nl),// = 10;
/**
* General category No in the Unicode specification.
* @since 1.7
*/
OTHER_NUMBER(No),//= 11;
/**
* General category Zs in the Unicode specification.
* @since 1.7
*/
SPACE_SEPARATOR(Zs),// = 12;
/**
* General category Zl in the Unicode specification.
* @since 1.7
*/
LINE_SEPARATOR(Zl),// = 13;
/**
* General category Zp in the Unicode specification.
* @since 1.7
*/
PARAGRAPH_SEPARATOR(Zp),// = 14;
/**
* General category Cc in the Unicode specification.
* @since 1.7
*/
CONTROL(Cc),// = 15;
/**
* General category Cf in the Unicode specification.
* @since 1.7
*/
FORMAT(Cf),// = 16;
/**
* Filler
* @since 1.7
*/
UNKNOWN(null),// = 17;
/**
* General category Co in the Unicode specification.
* @since 1.7
*/
PRIVATE_USE(Co),// = 18;
/**
* General category Cs in the Unicode specification.
* @since 1.7
*/
SURROGATE(Cs),// = 19;
/**
* General category Pd in the Unicode specification.
* @since 1.7
*/
DASH_PUNCTUATION(Pd),//= 20;
/**
* General category Ps in the Unicode specification.
* @since 1.7
*/
START_PUNCTUATION(Ps),// = 21;
/**
* General category Pe in the Unicode specification.
* @since 1.7
*/
END_PUNCTUATION(Pe),// = 22;
/**
* General category Pc in the Unicode specification.
* @since 1.7
*/
CONNECTOR_PUNCTUATION(Pc),// = 23;
/**
* General category Po in the Unicode specification.
* @since 1.7
*/
OTHER_PUNCTUATION(Po),// = 24;
/**
* General category Sm in the Unicode specification.
* @since 1.7
*/
MATH_SYMBOL(Sm),// = 25;
/**
* General category Sc in the Unicode specification.
* @since 1.7
*/
CURRENCY_SYMBOL(Sc),// = 26;
/**
* General category Sk in the Unicode specification.
* @since 1.7
*/
New methods in jdk7
Since i heard you were looking for suggestions, i think i might have a useful one that i think is impossible nowadays without native code. public void restart(); At first i thought it could be simulated just by calling the main class again in a shutdown hook, but i don't think all the static state is destroyed then. ProcessBuilder shenanigans wouldn't work, because when the parent jvm dies the child must too right?
Re: Review request for 6612680 (Remove classloader dependency on jkernel)
Mandy Chung wrote: Alan, Karen, Can you review the fix for: 6612680: Remove classloader dependency on jkernel Webrev at: http://cr.openjdk.java.net/~mchung/6612680/ java.lang.ClassLoader and sun.misc.Launcher have explicit dependencies on the jkernel code. While the performance impact of this is minimal (the calls basically amount to nops when the JRE is complete), it's still undesirable. To eliminate the static dependency on jkernel, this adds a boot classloader hook interface that is invoked in the ClassLoader findClass, getSystemResource, and other methods. The hook is null by default. The jkernel VM will call the static DownloadManager.setBootClassLoaderHook() method and only the jkernel environment will have a non-null boot class loader hook. Since jkernel is a separate build including the bundles and VM, as we discussed, the jkernel VM is a reasonable place to inject the DownloadManager as the boot class loader hook. I'm hoping to make TL b74 which is code freeze by 10 pm PT Monday. Good to see this dependency going away. A couple of comments: - In thread.cpp, do you need to check if klass is NULL (sun.jkernel.DownloadManager not present). - In thread.cpp, you set the hook after the system classes have been initialized. Do I have this right? (looks like you double check in setHook). You might want to check with the deployment folks to make sure that they understand the implications of this - for example it might have change the contents of the core bundle. - Do these changes mean we can remove sun.misc.VM.isBootedKernelVM? - Is the removal of CLASSDESTDIR from make/sun/jkernel/Makefile related or just clean-up (as it doesn't seem to be used)? Minor nit but you've add a blank line at line 46. - ZipEntry: the idea that a class loader hook overrides the zip file time is a bit strange. I see you have a few FIXME comments in the code to revisit but maybe for this push it might be neater to just have BootClassLoaderHook define a isCurrentThreadPrefetching or some such method that returns a boolean to indicate if the current thread is fetching and if so, set it to some pre-defined value (I don't know if there is any significance to the value of KERNEL_STATIC_MODTIME). - In ICC_Profile would it be neater to do: BootClassLoaderHook hook = BootClassLoaderHook.getHook(); if (hook != null) hook.prefetchFile(...) - Minor nit but you've added a few blank lines to DownloadManager. - I agree with Rémi comment that DownloadManager.instance doesn't seem to be needed. - In BootClassLoaderHook's class description they may be a typo - I think you meant to say into the bootstrap class loader. Also, I assume you meant to say In other JDK builds Otherwise, I think this is okay. I'll do another pass on it today as I know you want to get this over the finish line by tonight. -Alan.
Re: JSR-292: Why not java.lang.dyn?
I think this is somewhat of a red herring. After all, there are many classes which live in java.lang which are fundamental to the operation of the platform, and which any language which lived on top of the VM would have an intimate relationship with (eg Object, Class, String, etc). If we are moving to a point of view in which the Java language is not central to the platform, but rather first among equals (by removing all direct dependencies of the JVM spec on the JLS, etc), then in an ideal world these classes would live in java.core or java.platform or something. That would of course break the whole world, so is clearly not going to happen. The best we can do is not make the situation worse for future amendments, by not placing additional classes which are not specific to the Java language into java.lang. I am puzzled, however, by your assertion that dynamic invocation is closer to the language than 'not', ie closer to the language than the platform. Non-Java languages have been making use (and shipping support for, in some cases) of dynamic invocation for quite a few months now. The experience of those language's implementors has been integral to the development process of this feature. The Java language has been playing catch-up throughout. It's fantastic that it's in the JLS now and I look forward to seeing some first-class implementations of it, but this feature really wasn't crafted with Java as the pre-eminent use case. Ben On Mon, Oct 5, 2009 at 1:27 AM, Paul Benedict pbened...@apache.org wrote: Stepan, That is a very good observation. I wonder what others have to say about it? As you pointed out, there are other java.lang.* sub-packages that have no impact on the Java language. I am in agreement that java.dyn is closer to the language than not -- hence I think java.lang.dyn is natural. Paul On Sun, Oct 4, 2009 at 6:34 PM, Stepan Koltsov y...@mx1.ru wrote: On Sun, Oct 4, 2009 at 15:40, Rémi Forax fo...@univ-mlv.fr wrote: Le 04/10/2009 11:39, Christian Thalinger a écrit : On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote: I've always found it a bit perplexing that java.lang was never chosen for the parent package of the Dynamic API. Why is that? Dynamic types are now part of the language as proven by spec itself and exotic identifiers. Will this be reconsidered? [I'm forwarding this question to mlvm-dev.] I think John Rose or another member of the EG should have an answer to this. -- Christian java.lang = Java the language (not the platform) Exotic identifiers and MethodHandle.invoke calling rules in Java (the language) are not part of the JSR292 spec. JSR 292 = method handle API for any (dynamic?) language So why java.dyn API should be a 'part' of java.lang ? java.lang.reflect also deals with JVM objects, not Java language. But it still java.lang.reflect, not java.reflect. java.lang.Class is also closer to JVM then to the java language. java.lang has lots of JVM stuff. I also think, that package name should be java.lang.dyc, although it is not absolutely correct. java root package has lots of libraries (java.io, java.sql), and these libraries should not be mixed with JVM interface. If you think java.lang.dyn is inappropriate, then java.vm.dyn is better, because next JVM interface (what ever it will be) can be placed into java.vm package too and won't be lost among all java.* stuff. S. ___ mlvm-dev mailing list mlvm-...@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
New Methods/Features in JDK7
Hey, Are there any current listings of new language features/broad API changes so far in OpenJDK7. I understand they might not be permanent, and could change in a wink, though I'm curious to see what could possibly be in the next Java. Quintin Beukes
Re: New Methods/Features in JDK7
Unofficial: http://tech.puredanger.com/java7 On Mon, Oct 5, 2009 at 14:10, Quintin Beukes quin...@last.za.net wrote: Hey, Are there any current listings of new language features/broad API changes so far in OpenJDK7. I understand they might not be permanent, and could change in a wink, though I'm curious to see what could possibly be in the next Java. Quintin Beukes
hg: jdk7/tl/jdk: 6885204: JSSE should not require Kerberos to be present
Changeset: 54118c8e0ebe Author:vinnie Date: 2009-10-05 23:42 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/54118c8e0ebe 6885204: JSSE should not require Kerberos to be present Reviewed-by: wetmore, alanb ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/JsseJce.java
Re: Review request for 6612680 (Remove classloader dependency on jkernel)
Alan, Rémi, Thanks for the review. The revised webrev is at: http://cr.openjdk.java.net/~mchung/6612680/jdk-webrev.01/ http://cr.openjdk.java.net/~mchung/6612680/hotspot-webrev.01/ Alan Bateman wrote: Good to see this dependency going away. A couple of comments: - In thread.cpp, do you need to check if klass is NULL (sun.jkernel.DownloadManager not present). Yes, we need that so that jkernel VM can run with other JDKs with no DownloadManager. Thanks for catching it. - In thread.cpp, you set the hook after the system classes have been initialized. Do I have this right? (looks like you double check in setHook). You might want to check with the deployment folks to make sure that they understand the implications of this - for example it might have change the contents of the core bundle. Yes. I set the hook after the system classes have been initialized. I added the check in the setHook() method to catch if a new hook would be added in the future before the system is initialized. - Do these changes mean we can remove sun.misc.VM.isBootedKernelVM? I clean that up. We no longer need this method that was put as a workaround. - Is the removal of CLASSDESTDIR from make/sun/jkernel/Makefile related or just clean-up (as it doesn't seem to be used)? Minor nit but you've add a blank line at line 46. This is to fix the jdk and deploy build failure when we eliminate the dependency to jkernel. If the sun.jkernel.* classes were built in the tmp directory, javah fail to find the sun.jkernel.* classes to generate the .h files. Usually we only set CLASSDESTDIR to TEMPDIR when we want to package classes in a different jar file. This is not the case for sun.jkernel.* since they are included in rt.jar and that's a bug. I guess why it worked in the past is because sun.jkernel.* get compiled when compiling the system classes that reference DownloadManager and the sun.jkernel.* classes were put in the usual class destination directory. - ZipEntry: the idea that a class loader hook overrides the zip file time is a bit strange. I see you have a few FIXME comments in the code to revisit but maybe for this push it might be neater to just have BootClassLoaderHook define a isCurrentThreadPrefetching or some such method that returns a boolean to indicate if the current thread is fetching and if so, set it to some pre-defined value (I don't know if there is any significance to the value of KERNEL_STATIC_MODTIME). - In ICC_Profile would it be neater to do: BootClassLoaderHook hook = BootClassLoaderHook.getHook(); if (hook != null) hook.prefetchFile(...) - Minor nit but you've added a few blank lines to DownloadManager. - I agree with Rémi comment that DownloadManager.instance doesn't seem to be needed. - In BootClassLoaderHook's class description they may be a typo - I think you meant to say into the bootstrap class loader. Also, I assume you meant to say In other JDK builds Otherwise, I think this is okay. I'll do another pass on it today as I know you want to get this over the finish line by tonight. I clean up the code per your suggestion and ready to push the fix. Mandy -Alan.
