March 2016 - jpms-spec-comments

Module fragments and deployment scope
by Ali Ebrahimi 28 Mar '16

28 Mar '16

If you followed jigsaw-dev list you noticed some difficulties raised when testing java9 modules. For reference you can follow jigsaw-dev. I have one suggestion for this and that is Module fragments. If you familiar with OSGI fragments, module fragments is attached to (or embeded in) main (host) module. So we can implements test source code as module fragments that can have its own additional dependencies. module-fragment-info.java fragment com.foo.test for com.foo{ requires org.junit; } Even we can add module deployment scope (or type) or runtime mode and fragments can be enabled or disabled based on module system running mode. module-fragment-info.java fragment com.foo.test for com.foo{ requires org.junit; deployment-scope: test } So fragment com.foo.test would be enabled when module system running in test mode. I think module fragments can have other use cases, such as when we have one big module that should have support multiple OSs or Archs. Each OS or Arch can have its own specific code (and native). -- Best Regards, Ali Ebrahimi

1 0

Alternative to -XaddExports command-line option
by Simon Nash 24 Mar '16

24 Mar '16

Dear EG members, I would like to raise an issue with the current use of a command-line option in the Jigsaw codebase as the only way to enable an application to access non-exported APIs within the JDK. Setting addExports via the command line is very problematical for some applications. For example, I have developed an application that at present requires access to a few internal JDK APIs. This application needs to run on 7 different platforms and support both graphical and console interfaces. Each platform has different packaging requirements and launch arrangements and these would need to be substantially reworked in order to add the -XaddExports option. In at least one case (launching via the .jar file association on Windows), it isn't possible to add any command-line JVM options. Using the -XaddExports command-line option is also a problem for application packages that need to run on Java 9 and also on earlier versions of Java. If the launch script in the application package specifies the -XaddExports option, the application won't run on Java 7 or Java 8 because these versions don't understand this option. I would like to ask the Expert Group to consider defining some alternative means of setting addExports values in addition to the -XaddExports option. For example, the JDK could provide a new runtime API that the application can call if it detects that it is running on Java 9. Another option is to support a new manifest entry in the application's executable JAR file that would be recognized by Java 9 and ignored by previous versions of Java. Best regards, Simon

1 0

Java Platform Module System : Potential Additional Issue s
by Andrew Dinn 24 Mar '16

24 Mar '16

I have a couple of concerns regarding the proposals in JEP 261. I know this is still only a candidate but it still seems appropriate to place these concerns on the record. Details are provided after my signature. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) Issue: The first point at issue in JEP 261 arises under heading/subheading "Removed: Bootstrap class-path options/Open design issues" where it says: "Should the -Xbootclasspath/a option, and the corresponding JVM TI API, be deprecated in JDK 9 with the intent to remove them in JDK 10?" Problem: Byteman requires the JVMTI API in order to be able to instrument classes which belong to the bootstrap. The byteman agent jar (and, possibly, other agent 'helper' jars) can be hoisted into the bootstrap path during agent loading so that Byteman classes can be referenced from injected code (specifically, 3 Byteman exception classes need to be referenced form injected code). Injection into bootstrap classes is critical when it comes to engineering many common fault injection scenarios during testing. For example, Byteman is commonly used to force file stream operations to throw synthetic exceptions in order to exercise error handling code. Injection into bootstrap code is also critical to being able to inject code which traces and monitors execution of errant programs. For example, tracing of calls to Thread.setInterrupted has been used in the past to identify errors in 3rd party libraries which fail to handle InterruptedException correctly. Possible Resolution: Retain this privileged API for JVMTI agents Issue: The second point at issue in JEP 261 arises under heading "Risks and Assumptions" where it says "The java.lang.reflect.AccessibleObject::setAccessible method cannot be used to gain access to members of packages that are not exported by their defining modules; an InaccessibleObjectException will be thrown. If a framework library, such as a serializer, needs access to such members then the relevant packages must be exported to the framework module either via exports declarations in module descriptors or the -XaddExports command-line option." Problem: Byteman relies upon the use of reflective access via setAccessible to enable injected code to invoke non-public methods and read or update non-public fields. Such access is critical to support both tracing, monitoring and debugging of application behaviour and engineering of fault injection scenarios. Since Byteman is frequently used ad hoc when an error situation arises it will not normally be possible to pre-specify either the necessary exports declaration or suitable -XaddExports command-line options when using Byteman for tracing, monitoring and debugging. Although these options are available when implementing fault injection testing they significantly complicate test setup and management. n.b. I have looked at recent implementations of JDK9 which include code laid down in preparation for Jigsaw and I notice that something of this sort appears already to have been implemented. setAccessible now includes a check to ensure that the calling class and member are 'module-compatible'. The present code does not seem to be stopping the Byteman agent from accessing private members of classes which belong to modules (whether that's jdk.base or others). So, I am not sure if there is a real problem here which has not yet manifested because the implementation is incomplete or whether a get-out for JVMTI agent code is already implemented. Possible Resolution: Provide agent code with special permissions to employ the setAccessible API without risking an InaccessibleObjectException.

2 2

Fwd: Why can modules not be annotated?
by Paul Benedict 23 Mar '16

23 Mar '16

Mark, Here's a different spin on things... Since we've already seen the creep towards generating the Module Descriptor at build time, I think the area of tooling should not be neglected. Given that Oracle wants one file to express the module declaration, that doesn't mean Oracle can't help the tooling community by providing some standard annotations. In particular: *) Create @javax.tools.Export annotation that is @Target(PACKAGE) and @Retention(SOURCE) to avoid competing frameworks from providing their own. This is going to happen if Oracle doesn't. Notice I am recommending it be placed in "javax.tools" to indicate tooling support, and, it's discarded by the compiler. The latter will prevent any confusion about it existing in the binary. *) Allow annotations on the module to express the custom attributes that you've spec-ed out. I advocate this as a happy medium. There are three wins in this proposal: 1) The module declaration is fully self-expressible in one file (as-is today) 2) Tools have a standard way of generating the exports list from packages 3) Tools have a standard way of customizing the module declaration at the source level I would like the EG to consider my proposal for the sake of tooling and automatic code generation. Cheers, Paul ---------- Forwarded message ---------- From: <mark.reinhold(a)oracle.com> Date: Wed, Dec 9, 2015 at 7:25 PM Subject: Re: Why can modules not be annotated? To: peter.kriens(a)aqute.biz Cc: jpms-spec-experts(a)openjdk.java.net 2015/10/12 9:56 -0700, peter.kriens(a)aqute.biz: > I understand the trade offs. > > That said, I am a bit curious how we are going to handle the > discussing these trade offs in the design? I had actually expected > that more things were set in stone but in this discussion it seems > there are still some open areas. Are we going to have phone > conferences, a face to face? As stated in the original JSR, this EG will work exclusively via e-mail, on this list. I will soon start gathering a list of open issues for us to discuss and work through before publishing the EDR. > Anyway, thanks for all the responses. It did clarify things for me. Glad to hear it. - Mark

2 2

Re: Fwd: Why can modules not be annotated?
by Paul Benedict 23 Mar '16

23 Mar '16

Mark, >> *) Allow annotations on the module to express the custom attributes that >>> you've spec-ed out. Ah, my apologies for amalgamating ideas. The heart of my proposal was regarding javax.tools annotations to synthesize module-info.java, but I accidentally snuck it something different. Hence, what I write below should clarify this bullet point. Please regard below as part of #ModuleAnnotations. Although tools will have the ability to manipulate bytecode to add custom attributes, I find it particularly limiting there is no way for developers to do the same in source. Assuming custom attributes are opaque strings, then I propose something like this: @Repeatable(ModuleAttributes.class) @Retention(RUNTIME) @Target(ElementType.MODULE) @Documented public @interface ModuleAttribute { String name(); String value(); } For example, Remi recently proposed an idea to deprecate modules [1]. I then opined Remi's proposal could be related to #StandardModuleAttributes [2], if there was a desire to give modules more information for tools to consume (such as the deprecated module name's replacement). Absent constant strings that specify standard module attribute names, I'll just specify my own: @Deprecated @ModuleAttribute("replacement", "org.xyz.qux.2") module org.xyz.qux { } PS: If you decide to let modules be annotated, and then allow @ModuleAttributes to exist, is there any point at all in "custom attributes" in the Module_attribute structure [3]? [1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-March/000263.… [2] http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-March/00032… [3] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html Cheers, Paul On Mon, Mar 21, 2016 at 6:49 PM, <mark.reinhold(a)oracle.com> wrote: > 2016/3/9 8:50 -0800, pbenedict(a)apache.org: > > I am proposing a standard set of source retention annotations that > > developers write and tools consume to build the module-info.java > > automatically. > > I think I understand your proposal for a javax.tools.Export annotation > for use on packages. The idea there is that a developer could write > @Export in a package-info.java file, and a tool could interpret that to > add an appropriate `exports` directive to a synthesized module-info.java > file. > > I'm still confused, however, by your earlier statement > > >>> *) Allow annotations on the module to express the custom attributes > that > >>> you've spec-ed out. > > Who's the "you" in this sentence? What annotations do you have in mind > here? > > > PS: This is a different issue than those who want to annotate statements > in > > module-info.java. > > Understood. > > - Mark >

2 1

Pluggability of automatic module name/version
by Paul Benedict 23 Mar '16

23 Mar '16

Dear EG members, One concern I have with finding automatic modules [1] is the algorithm, which determines the automatic module name and version, is baked into the JDK. It appears to me this should be pluggable through a service so that it could be customized. Although we can speculate what will happen with EE 8 and modules [2], pluggability would allow alternate implementations to perform custom naming/version based on other criteria. Such criteria, for example.... *) The GAV specified in META-INF/maven/.../pom.xml embedded in many Maven artifacts [3]. *) JBoss modules metadata from the EAP/WildFly shared modules directory [4]. *) WebSphere's shared libraries might also be applicable to this situation [5]. References: [1] http://download.java.net/java/jigsaw/docs/api/java/lang/module/ModuleFinder… [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/006795.html [3] https://maven.apache.org/guides/mini/guide-archive-configuration.html [4] https://docs.jboss.org/author/display/WFLY8/Class+Loading+in+WildFly [5] http://www.ibm.com/support/knowledgecenter/was_beta/com.ibm.websphere.base.… Cheers, Paul

2 1

Module name as new Manifest Entry
by Paul Benedict 23 Mar '16

23 Mar '16

For consideration by the EG: Based on some discussion [1], there is at least one tool like the Maven Compiler Plugin that only requires a Java 1.6 runtime. That means there is no native way for it to access the module name in a Java 1.9 JAR. One possible solution is to use a third-party class reader which knows how to interpret the new class file format. On the other hand, Java has supported reading the Manifest file since version 1.2. This API is available to older Java runtimes. If Java 9 allowed a new Manifest entry for the module name, older runtimes could then easily retrieve the module name using existing API. Furthermore, it would allow library providers who still support pre-Java 9 to provide a de facto module name when dropped in as an "automatic module" [2]. I personally don't find it tenable that artifacts in the Maven repository will ever be renamed to have a decent working module name that's usable in "automatic module" mode. PS: I am not proposing the Manifest entry replace the module name in module-info.java. This is only to ease migration of legacy libraries in "automatic module" mode. [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/006632.html [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/006683.html Cheers, Paul

2 2

Re: Fwd: Why can modules not be annotated?
by Paul Benedict 21 Mar '16

21 Mar '16

I am proposing a standard set of source retention annotations that developers write and tools consume to build the module-info.java automatically. PS: This is a different issue than those who want to annotate statements in module-info.java. Cheers, Paul On Mon, Feb 22, 2016 at 1:34 PM, <mark.reinhold(a)oracle.com> wrote: > 2015/12/11 8:58 -0800, Paul Benedict <pbenedict(a)apache.org>: > > Since we've already seen the creep towards generating the Module > Descriptor > > at build time, I think the area of tooling should not be neglected. Given > > that Oracle wants one file to express the module declaration, that > doesn't > > mean Oracle can't help the tooling community by providing some standard > > annotations. > > > > In particular: > > > > *) Create @javax.tools.Export annotation that is @Target(PACKAGE) and > > @Retention(SOURCE) to avoid competing frameworks from providing their > own. > > This is going to happen if Oracle doesn't. Notice I am recommending it be > > placed in "javax.tools" to indicate tooling support, and, it's discarded > by > > the compiler. The latter will prevent any confusion about it existing in > > the binary. > > > > *) Allow annotations on the module to express the custom attributes that > > you've spec-ed out. > > > > I advocate this as a happy medium. There are three wins in this proposal: > > 1) The module declaration is fully self-expressible in one file (as-is > > today) > > 2) Tools have a standard way of generating the exports list from packages > > 3) Tools have a standard way of customizing the module declaration at the > > source level > > > > I would like the EG to consider my proposal for the sake of tooling and > > automatic code generation. > > Can you please clarify exactly what it is that you propose? > > Do you want standard annotations in module-info.class files to repeat > the information presently encoded in attributes in such files? Or do > you want annotations to replace those attributes? Or something else? > > - Mark >

2 1

新規開拓営業リスト
by 顧客開拓クリスト 12 Mar '16

12 Mar '16

新規営業開拓用リストを安価で提供いたします。　　　　　２，８００万件の企業情報リストをご自由にお使い下さい。 □■□ ━━━━━━━━━━━━━━━━━━━━━━━━ □■□ 　　　　　　　　１１０，０００件無料体験でダウンロードＯＫ □■□ ━━━━━━━━━━━━━━━━━━━━━━━━ □■□ ★　企業情報リストを２つの方法でご提供　　A)　最新企業情報　２，８００万件が即時にダウンロード　　　　　　・　例　新規開拓用の情報　１００，０００件が２分で簡単にゲット出来るシステム　　　　　　　　　　　　　　　B)　企業情報リスト（県・業種・メール・ＦＡＸ　各別）ＣＳＶで提供致します。　　　　　　・　収録内容【業種・名称・〒・住所・電話・ＦＡＸ・メール・ホームページ・・・】　　　　　詳しくは ↓↓　こちらへ http://bf04.bfit.jp/~noa/index.html ★　A) の無料体験は　(11万件無料提供)↓↓　こちらへ　　　　　　　　http://bf04.bfit.jp/~noa/menu6.html#6-6 最大（10件　＊　47県　＊　244業種　＝　114,680件無料） ★　B) の価格表は　　　　　　　　　　↓↓　こちらへ http://bf04.bfit.jp/~noa/menu9.html ★　メールでのお問合せは　　　　　　↓↓　こちらへ　　　　　　　　noa(a)bf04.yanen.jp まで ★　電話お問合せは　　　　　　　　　↓↓　こちらへ　　　　　　　　052-971-0904　　担当　正木　まで ★　メール返信は　下記をご記入の上　↓↓　こちらへ　　　　　　　　　　　　　　　お│問│合│わ│せ│ 　　　　　　　　　　　　　　　─┘─┘─┘─┘─┘ ■■返信メールでのお問い合わせは下記ご記入の上お願いいたします。■■ 　☆　会社名　　　　　　−−−−−−−−−−−−−−−−−−−−−−−−−−−− 　☆　ご担当者　　　　　　　−−−−−−−−−−−−−−−−−−−−−−−−−−−− 　☆　電話番号　　　　　　　−−−−−−−−−−−−−−−−−−−−−−−−−−−− 　☆　E-mail　　　　　　　　　−−−−−−−−−−−−−−−−−−−−−−−−−−−− 　☆　ご希望の商品は　　　　　　　・　全国検索システム　　　　　　　・　県別の企業りスト　　　　　　　・　業種別企業りスト　　　　　　　・　メール企業りスト　　　　　　　・　ＦＡＸ番号企業りスト　　　　　　−−−−−−−−−−−−−−−−−−−−−−−−−−−− 　☆　その他ご意見　　　　　　−−−−−−−−−−−−−−−−−−−−−−−−−−−− ☆・・:・:・:・:・:・:・:☆:・:・:・:・:・:・:・☆:・:・:・:・:・:・:☆ 個人情報の収集と利用の目的を下記の通り定め、それ以外に利用することはいたしません。 1）個人情報の収集と利用の目的　　　弊社商品のＤＭ配信及び案内の発送　　　弊社によるアンケート、メールマガジンの送付、　　　各種サービスのご案内 2）個人情報の外部預託　　　個人情報を外部の業者に預託し、情報処理を行なう事はございません。　　　社内にて個人情報を適正に管理できるようにいたします。 3）個人情報の第三者への提供　　　個人情報をご本人の承諾を得ずに第三者に開示することはいたしません。 5）個人情報の確認、訂正、削除　　　個人情報の確認、訂正または削除のご依頼があった場合には、請求者がご本人であることを　　　確認させていただいたうえで、すみやかに対応いたします。　　　下記の窓口まで、文書もしくはE-mailでご連絡ください。 6）個人情報に関する問合せ先　　　個人情報に関するお問合せは、以下の個人情報相談窓口までご連絡ください。　　　苦情相談窓口担当者正木　電話　052-971-0904 ☆・・:・:・:・:・:・:・:☆:・:・:・:・:・:・:・☆:・:・:・:・:・:・:・☆・:・:・:・:・:・:・☆ jpms-spec-comments(a)openjdk.java.net 様配信停止及びアドレスの変更　　企業情報提供の購読頂き有り難うございました。　　配信停止及びアドレスの変更はお手数ですが以下のページにてお願いします。 http://noa-system.moo.jp/www/mag/index.cgi 上記アドレスから購読変更出来ない時は、弊社送信本文共にご返信いただきますようお願い申し上げます。ＢusinessＴargetＡdviser Ｍ＆m　担当　正木名古屋市中川区高畑５−６８　電話：052-971-0904　 (くわわてたふこ) E-mail：　　noa(a)bf04.yanen.jp ☆・・:・:・:・:・:・:・:☆:・:・:・:・:・:・:・☆:・:・:・:・:・:・:・☆280313:・:・:・☆

1 0

Follow Up-Security Software Users Marketing Data
by Amy Saunders 11 Mar '16

11 Mar '16

Hello, I wanted to follow-up in reference to my previous e-mail sent on 9th March about Security Software Users Global for Marketing Initiatives? If you had a chance to review the information below, please advice. Best Regards, Amy Saunders Marketing Executive _____ Hello, I hope you are the right person to discuss regarding our Security Software Users Contacts details for your Marketing Initiatives like Email Marketing, Tele Marketing and Direct mailings? Security Software Users: - Check Point, Web Sense, Sophos, Watch Guard, RSA, Palo Alto Networks, Cisco, Hexis Cyber Solutions, Tanium, Symantec, Blue Coat System Users and many more Our List Includes:- Company Name, Web Address, Contact Name, Verified Email, Job Title, Application Type, Complete Mailing Address, Phone Number, FAX Number, SIC Code, and Industry details. Other Technology Users: - Oracle User, Sales Force Users, SAP User, Citrix Users, Avaya Users, JD Edward Users, IBM Users, Microsoft Dynamic User, CRM User, ERP Users, Sage User, Sugar CRM User and many more. Kindly provide the following details so we could get back with the counts and the pricing details. Target Technology: Title: Geography: Thanks and looking forward to hear from you! Best Regards, Amy Saunders Marketing Executive _____ If you do not wish to receive further emails kindly reply with "Leave Out" or "Unsubscribe"

1 0