Unidentified subject!
<[EMAIL PROTECTED]> Thu Aug 29 03:58:05 2002 X-Envelope-Sender: [EMAIL PROTECTED] Received: (qmail 18759 invoked from network); 29 Aug 2002 08:58:04 - Received: from smtp11.dti.ne.jp (202.216.228.46) by murphy.debian.org with SMTP; 29 Aug 2002 08:58:04 - Received: from pc3 (PPPa3884.tokyo-ip.dti.ne.jp [218.225.244.134]) by smtp11.dti.ne.jp (3.08s) with SMTP id g7T8w2HP029611 for <[EMAIL PROTECTED]>; Thu, 29 Aug 2002 17:58:02 +0900 (JST) Date: Thu, 29 Aug 2002 17:58:02 +0900 (JST) Message-Id: <[EMAIL PROTECTED]> From: =?ISO-2022-JP?B?GyRCJCo2YkJfJDckXiQ5GyhC?= <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoGyhC?= MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.8 required=4.7 tests=NO_MX_FOR_FROM version=2.20 X-Spam-Level: * $B!c;v6Hhttp://www.vesta.dti.ne.jp/~taketu $B???4%-%c%C%7%s%0(B $B!|(B24$B;~4VfIW!)0lK\2=!&=i$a$F$NJ}4?7^(B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
comments on proposed java policy
Hi, I'm just subscribed to this list, but just caught the announcement and went through it. Some comments and questions: 1. why is there a difference between java1 and java2? Isn't java1 virtually obsolete? (I work on a java project where the life-cycle is short and customers upgrade rather quick, so it's easy to upgrade jvm). 2. why must java-compiler depend on java-runtime I propose to make this a suggestion. For example, gcj isn't a java class. Perhaps a note to enlighten naive readers like me? 3. I don't understand why 'auxliary classes' (section 2.3) must follow the naming for libraries. I can image that the name often is determined upstream. 4. what about JNI? As you note in the heading of chapter 2, java bytecode is portable. But packages may contain JNI. 5. what about j2ee? I propose to further make difference between java1, j2se, j2ee and j2me? I think we must be prepared for at least the ee version to be packaged. 6. How to handle apis? things like jaxp, jndi ext. These may be available as separate libraries or included in a runtime (see Suns JDK 1.4). Do we (and where) determine virtual packages for those? I guess that's enought for now... Good luck, Jan Evert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: comments on proposed java policy
Jan Evert van Grootheest wrote: > 2. why must java-compiler depend on java-runtime I propose to make > this a suggestion. For example, gcj isn't a java class. I'm not sure what you mean by this statement - presumably that gcj isn't a Java run-time. While the gcj *command* isn't a Java runtme, gcj comes with an associated interpreter and runtime. The command 'gij' is intended to be able to replace the 'java' command. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Unidentified subject!
<[EMAIL PROTECTED]> Thu Aug 29 03:58:05 2002 X-Envelope-Sender: [EMAIL PROTECTED] Received: (qmail 18759 invoked from network); 29 Aug 2002 08:58:04 - Received: from smtp11.dti.ne.jp (202.216.228.46) by murphy.debian.org with SMTP; 29 Aug 2002 08:58:04 - Received: from pc3 (PPPa3884.tokyo-ip.dti.ne.jp [218.225.244.134]) by smtp11.dti.ne.jp (3.08s) with SMTP id g7T8w2HP029611 for ; Thu, 29 Aug 2002 17:58:02 +0900 (JST) Date: Thu, 29 Aug 2002 17:58:02 +0900 (JST) Message-Id: <[EMAIL PROTECTED]> From: =?ISO-2022-JP?B?GyRCJCo2YkJfJDckXiQ5GyhC?= <[EMAIL PROTECTED]> To: Subject: =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoGyhC?= MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.8 required=4.7 tests=NO_MX_FOR_FROM version=2.20 X-Spam-Level: * $B!c;v6Hhttp://www.vesta.dti.ne.jp/~taketu $B???4%-%c%C%7%s%0(B $B!|(B24$B;~4VfIW!)0lK\2=!&=i$a$F$NJ}4?7^(B
comments on proposed java policy
Hi, I'm just subscribed to this list, but just caught the announcement and went through it. Some comments and questions: 1. why is there a difference between java1 and java2? Isn't java1 virtually obsolete? (I work on a java project where the life-cycle is short and customers upgrade rather quick, so it's easy to upgrade jvm). 2. why must java-compiler depend on java-runtime I propose to make this a suggestion. For example, gcj isn't a java class. Perhaps a note to enlighten naive readers like me? 3. I don't understand why 'auxliary classes' (section 2.3) must follow the naming for libraries. I can image that the name often is determined upstream. 4. what about JNI? As you note in the heading of chapter 2, java bytecode is portable. But packages may contain JNI. 5. what about j2ee? I propose to further make difference between java1, j2se, j2ee and j2me? I think we must be prepared for at least the ee version to be packaged. 6. How to handle apis? things like jaxp, jndi ext. These may be available as separate libraries or included in a runtime (see Suns JDK 1.4). Do we (and where) determine virtual packages for those? I guess that's enought for now... Good luck, Jan Evert
Re: comments on proposed java policy
Jan Evert van Grootheest wrote: 2. why must java-compiler depend on java-runtime I propose to make this a suggestion. For example, gcj isn't a java class. I'm not sure what you mean by this statement - presumably that gcj isn't a Java run-time. While the gcj *command* isn't a Java runtme, gcj comes with an associated interpreter and runtime. The command 'gij' is intended to be able to replace the 'java' command. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/