Re: RFR: 8257733: Move module-specific data from make to respective module

[mark . reinhold]

2020/12/4 6:08:13 -0800, er...@openjdk.java.net:
> On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman  wrote:
>>> And I can certainly move jdwp.spec to java.base instead. That's the
>>> reason I need input on this: All I know is that is definitely not
>>> the responsibility of the Build Group to maintain that document, and
>>> I made my best guess at where to place it.
>> 
>>> And I can certainly move jdwp.spec to java.base instead.
>> 
>> If jdwp.spec has to move to the src tree then src/java.se is probably
>> the most suitable home because Java SE specifies JDWP as an optional
>> interface. So nothing to do with java.base and the build will need to
>> continue to generate the sources for the front-end (jdk.jdi) and
>> back-end (jdk.jdwp.agent) as they implement the protocol.
> 
> My understanding of JEPs is that they should be viewed as living
> documents. In this case, I think it's perfectly valid to update JEP
> 201 with additional source code layout. Both for this and for the
> other missing dirs.

Feature JEPs are living documents until such time as they are delivered.
In this case it would not be appropriate to update JEP 201, which is as
much about the transition from the old source-code layout as it is about
the new layout as of 2014.

At this point, and given that we’d already gone beyond JEP 201 prior to
this change (with `man` and `lib` subdirectories), what’d make the most
sense is a new informational JEP that documents the source-code layout.
Informational JEPs can, within reason, be updated over time.

- Mark

Re: 15 RFR (XXS) 8250216: The README need not mention retrieving source code

[mark . reinhold]

2020/7/23 10:33:34 -0700, iris.cl...@oracle.com:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250216
>> 
>> [ ... ]
>> 
>> Patch below.
> 
> Looks good.
> 
> I think it would be nice if you could reference the JDK Project page
> (ojn/projects/jdk), not just ojn.

Good idea ... but I just pushed the changeset.  I’ll fix that later.

- Mark

15 RFR (XXS) 8250216: The README need not mention retrieving source code

[mark . reinhold]

Bug: https://bugs.openjdk.java.net/browse/JDK-8250216

The README at the root of the source tree says, “For information about
building the JDK, including how to retrieve all of the source code,
please see ...” yet we haven’t needed instructions on how to retrieve
the rest of the source code since JDK 10, when we consolidated
everything into a single repository.

(Also, the http://openjdk.java.net/ URL should be https://...)

Patch below.

Thanks,
- Mark



diff --git a/README b/README
--- a/README
+++ b/README
@@ -2,11 +2,10 @@
 Welcome to the JDK!
 ===
 
-For information about building the JDK, including how to retrieve all
-of the source code, please see either of these files:
+For build instructions, please see either of these files:
 
   * doc/building.html   (html version)
   * doc/building.md (markdown version)
 
-See http://openjdk.java.net/ for more information about the OpenJDK
+See https://openjdk.java.net/ for more information about the OpenJDK
 Community and the JDK.

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

[mark . reinhold]

2019/10/23 12:37:56 -0700, bob.vande...@oracle.com:
>> On Oct 23, 2019, at 3:07 PM, mark.reinh...@oracle.com wrote:
>> ...
>> 
>> Addendum: To keep things sane for JFR and the serviceability agent,
>> I had to propagate this change through to those subsystems.
>> 
>> Relative patch below; original webrev updated in place
>> (https://cr.openjdk.java.net/~mr/rev/8232080/).
>> 
>> Okay?
> 
> Looks good.  I’m sure you did this but I scanned the entire JDK
> sources and didn’t see any other uses of JVMFlag:: that would need to
> be updated.

Yep, I did that, and didn’t see anything else either.

Thanks,
- Mark

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

[mark . reinhold]

2019/10/22 15:36:28 -0700, mark.reinh...@oracle.com:
> 2019/10/22 12:43:42 -0700, bob.vande...@oracle.com:
>>> On Oct 22, 2019, at 3:22 PM, mark.reinh...@oracle.com wrote:
>>> 2019/10/22 10:31:55 -0700, bob.vande...@oracle.com:
 In arguments.cpp, could you use a new JVMFlag to declare options
 that came from this resource as RESOURCE?
 
 - jint result = parse_each_vm_init_arg(vm_options_args, 
 _mod_javabase, JVMFlag::INTERNAL);
 + jint result = parse_each_vm_init_arg(vm_options_args, 
 _mod_javabase, JVMFlag::RESOURCE);
 
 This will require some minor changes to jvmFlags.hpp
 
 ...
>>> 
>>> Yes, that’d make sense, in which case I’d also change JVMFlag::print_origin
>>> to handle the RESOURCE case (which is easy).
>>> 
>>> Is “RESOURCE” the best name here?  Sounds awfully generic.  How about
>>> “JIMAGE” or “JIMAGE_RESOURCE”?
>> 
>> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE  works for me.
> 
> JIMAGE_RESOURCE it is, then.  Relative patch below; original webrev
> updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/).

Addendum: To keep things sane for JFR and the serviceability agent,
I had to propagate this change through to those subsystems.

Relative patch below; original webrev updated in place
(https://cr.openjdk.java.net/~mr/rev/8232080/).

Okay?

- Mark



# HG changeset patch
# Parent  d3f05e3b0d76e1a74a10cee180d8953d3045b6c8
Addendum 3 (propagate JIMAGE_RESOURCE): 8232080: jlink plugins for vendor 
information and run-time options

diff --git a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp 
b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
--- a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
+++ b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
@@ -134,6 +134,7 @@
 case JVMFlag::ERGONOMIC: return "Ergonomic";
 case JVMFlag::ATTACH_ON_DEMAND: return "Attach on demand";
 case JVMFlag::INTERNAL: return "Internal";
+case JVMFlag::JIMAGE_RESOURCE: return "JImage resource";
 default: ShouldNotReachHere(); return "";
   }
 }
diff --git a/src/hotspot/share/runtime/vmStructs.cpp 
b/src/hotspot/share/runtime/vmStructs.cpp
--- a/src/hotspot/share/runtime/vmStructs.cpp
+++ b/src/hotspot/share/runtime/vmStructs.cpp
@@ -2612,6 +2612,7 @@
   declare_constant(JVMFlag::ERGONOMIC)\
   declare_constant(JVMFlag::ATTACH_ON_DEMAND) \
   declare_constant(JVMFlag::INTERNAL) \
+  declare_constant(JVMFlag::JIMAGE_RESOURCE)  \
   declare_constant(JVMFlag::VALUE_ORIGIN_MASK)\
   declare_constant(JVMFlag::ORIG_COMMAND_LINE)
 
diff --git 
a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java 
b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java
--- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java
+++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java
@@ -35,7 +35,8 @@
   MANAGEMENT ("Management"),
   ERGONOMIC ("Ergonomic"),
   ATTACH_ON_DEMAND ("Attach on demand"),
-  INTERNAL ("Internal");
+  INTERNAL ("Internal"),
+  JIMAGE_RESOURCE ("JImage");
 
   private final String value;
 
diff --git 
a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java 
b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java
--- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java
+++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java
@@ -114,6 +114,7 @@
   public static intFlags_ERGONOMIC;
   public static intFlags_ATTACH_ON_DEMAND;
   public static intFlags_INTERNAL;
+  public static intFlags_JIMAGE_RESOURCE;
   private static int   Flags_VALUE_ORIGIN_MASK;
   private static int   Flags_ORIG_COMMAND_LINE;
   /** This is only present in a non-core build */
@@ -200,6 +201,8 @@
 return "attach";
 } else if (origin == Flags_INTERNAL) {
 return "internal";
+} else if (origin == Flags_JIMAGE_RESOURCE) {
+return "jimage";
 } else {
 throw new IllegalStateException(
 "Unknown flag origin " + origin + " is detected in " + name);
@@ -484,6 +487,7 @@
 Flags_ERGONOMIC = db.lookupIntConstant("JVMFlag::ERGONOMIC").intValue();
 Flags_ATTACH_ON_DEMAND = 
db.lookupIntConstant("JVMFlag::ATTACH_ON_DEMAND").intValue();
 Flags_INTERNAL = db.lookupIntConstant("JVMFlag::INTERNAL").intValue();
+Flags_JIMAGE_RESOURCE = db.lookupIntConstant("JVMFlag::JIMAGE").intValue();
 Flags_VALUE_ORIGIN_MASK = 
db.lookupIntConstant("JVMFlag::VALUE_ORIGIN_MASK").intValue();
 Flags_ORIG_COMMAND_LINE = 
db.lookupIntConstant("JVMFlag::ORIG_COMMAND_LINE").intValue();
 oopSize  = db.lookupIntConstant("oopSize").intValue();

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

[mark . reinhold]

2019/10/22 12:43:42 -0700, bob.vande...@oracle.com:
>> On Oct 22, 2019, at 3:22 PM, mark.reinh...@oracle.com wrote:
>> 2019/10/22 10:31:55 -0700, bob.vande...@oracle.com:
>>> In arguments.cpp, could you use a new JVMFlag to declare options
>>> that came from this resource as RESOURCE?
>>> 
>>> - jint result = parse_each_vm_init_arg(vm_options_args, 
>>> _mod_javabase, JVMFlag::INTERNAL);
>>> + jint result = parse_each_vm_init_arg(vm_options_args, 
>>> _mod_javabase, JVMFlag::RESOURCE);
>>> 
>>> This will require some minor changes to jvmFlags.hpp
>>> 
>>> ...
>> 
>> Yes, that’d make sense, in which case I’d also change JVMFlag::print_origin
>> to handle the RESOURCE case (which is easy).
>> 
>> Is “RESOURCE” the best name here?  Sounds awfully generic.  How about
>> “JIMAGE” or “JIMAGE_RESOURCE”?
> 
> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE  works for me.

JIMAGE_RESOURCE it is, then.  Relative patch below; original webrev
updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/).

- Mark




# HG changeset patch
# Parent  efca1844245ad7351418ef41efc86c5055ac3edf
Addendum 1 (JVMFlags): 8232080: jlink plugins for vendor information and 
run-time options

diff --git a/src/hotspot/share/runtime/arguments.cpp 
b/src/hotspot/share/runtime/arguments.cpp
--- a/src/hotspot/share/runtime/arguments.cpp
+++ b/src/hotspot/share/runtime/arguments.cpp
@@ -2203,7 +2203,7 @@
   set_mode_flags(_mixed);
 
   // Parse args structure generated from java.base vm options resource
-  jint result = parse_each_vm_init_arg(vm_options_args, _mod_javabase, 
JVMFlag::INTERNAL);
+  jint result = parse_each_vm_init_arg(vm_options_args, _mod_javabase, 
JVMFlag::JIMAGE_RESOURCE);
   if (result != JNI_OK) {
 return result;
   }
diff --git a/src/hotspot/share/runtime/flags/jvmFlag.cpp 
b/src/hotspot/share/runtime/flags/jvmFlag.cpp
--- a/src/hotspot/share/runtime/flags/jvmFlag.cpp
+++ b/src/hotspot/share/runtime/flags/jvmFlag.cpp
@@ -697,6 +697,8 @@
   st->print("attach"); break;
 case INTERNAL:
   st->print("internal"); break;
+case JIMAGE_RESOURCE:
+  st->print("jimage"); break;
   }
   st->print("}");
 }
diff --git a/src/hotspot/share/runtime/flags/jvmFlag.hpp 
b/src/hotspot/share/runtime/flags/jvmFlag.hpp
--- a/src/hotspot/share/runtime/flags/jvmFlag.hpp
+++ b/src/hotspot/share/runtime/flags/jvmFlag.hpp
@@ -44,8 +44,9 @@
 ERGONOMIC= 5,
 ATTACH_ON_DEMAND = 6,
 INTERNAL = 7,
+JIMAGE_RESOURCE  = 8,
 
-LAST_VALUE_ORIGIN = INTERNAL,
+LAST_VALUE_ORIGIN = JIMAGE_RESOURCE,
 VALUE_ORIGIN_BITS = 4,
 VALUE_ORIGIN_MASK = right_n_bits(VALUE_ORIGIN_BITS),
 

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

[mark . reinhold]

2019/10/22 14:12:18 -0700, mandy.ch...@oracle.com:
> On 10/21/19 8:22 PM, mark.reinh...@oracle.com wrote:
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
>> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
> 
> Looks good to me. One minor comment:
> 
> AddResourcePlugin isn't really a FILTER, probably best to add a new 
> category for new resource file. jlink hardcodes the order of the 
> categories that determines the order of the plugins to be executed (I 
> see the existing implementation could be cleaned up in the future).  I 
> think we didn't want to the options resource to be filtered by 
> --exclude-resources plugin and so the add-options plugin should run 
> after all filter plugins.

Good point -- that makes sense.

Relative patch below; original webrev updated in place.

Thanks,
- Mark



# HG changeset patch
# Parent  43f160bda3c7a2a7009df91afa37469760d42333
Addendum 2 (jlink ADDER): 8232080: jlink plugins for vendor information and 
run-time options

diff --git 
a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java
 
b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java
--- 
a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java
+++ 
b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java
@@ -50,6 +50,7 @@
 
 static {
 CATEGORIES_ORDER.add(Category.FILTER);
+CATEGORIES_ORDER.add(Category.ADDER);
 CATEGORIES_ORDER.add(Category.TRANSFORMER);
 CATEGORIES_ORDER.add(Category.MODULEINFO_TRANSFORMER);
 CATEGORIES_ORDER.add(Category.SORTER);
diff --git 
a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java
 
b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java
--- 
a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java
+++ 
b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java
@@ -58,7 +58,7 @@
 
 @Override
 public Category getType() {
-return Category.FILTER;
+return Category.ADDER;
 }
 
 @Override
diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java 
b/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java
--- a/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java
+++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java
@@ -39,6 +39,7 @@
  * Order of categories matches the plugin sort order.
  * 
  * FILTER: Filter in/out resources or files.
+ * ADDER: Add resources or files.
  * TRANSFORMER: Transform resources or files(eg: refactoring, bytecode
  * manipulation).
  * MODULEINFO_TRANSFORMER: Transform only module-info.class
@@ -52,6 +53,7 @@
  */
 public enum Category {
 FILTER("FILTER"),
+ADDER("ADDER"),
 TRANSFORMER("TRANSFORMER"),
 MODULEINFO_TRANSFORMER("MODULEINFO_TRANSFORMER"),
 SORTER("SORTER"),

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

[mark . reinhold]

2019/10/22 7:15:10 -0700, alan.bate...@oracle.com:
> On 22/10/2019 04:22, mark.reinh...@oracle.com wrote:
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
>> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
> 
> I've read through the code for the new jlink plugins and the changes to 
> VersionProps and it looks good.
> 
> An alternative for VersionProps would have been to generate a helper 
> class at link time rather than extending the static initilizer to set 
> the fields. That would allow the VENDOR* fields to be final (but I don't 
> think it makes too much difference and it may be a bit more complicated 
> due to having 4 plugins contributing code).

Yes, that would’ve been more complex, and the finality of these fields
isn’t critical.

> The need for a plugin per CLI option may be motivation to explore (in 
> the future) having a single plugin expose multiple options.

Agreed.

Thanks,
- Mark

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

[mark . reinhold]

2019/10/22 10:31:55 -0700, bob.vande...@oracle.com:
> In arguments.cpp, could you use a new JVMFlag to declare options that came 
> from this resource as RESOURCE?
> 
> - jint result = parse_each_vm_init_arg(vm_options_args, _mod_javabase, 
> JVMFlag::INTERNAL);
> + jint result = parse_each_vm_init_arg(vm_options_args, _mod_javabase, 
> JVMFlag::RESOURCE);
> 
> This will require some minor changes to jvmFlags.hpp
> 
>   34 struct JVMFlag {
>   35   enum Flags {
>   36 // latest value origin
>   37 DEFAULT  = 0,
>   38 COMMAND_LINE = 1,
>   39 ENVIRON_VAR  = 2,
>   40 CONFIG_FILE  = 3,
>   41 MANAGEMENT   = 4,
>   42 ERGONOMIC= 5,
>   43 ATTACH_ON_DEMAND = 6,
>   44 INTERNAL = 7,
> 
> +  45 RESOURCE = 8,
> 
>   46 
> 
> -  47  LAST_VALUE_ORIGIN = INTERNAL,
>  + 47 LAST_VALUE_ORIGIN = RESOURCE,

Yes, that’d make sense, in which case I’d also change JVMFlag::print_origin
to handle the RESOURCE case (which is easy).

Is “RESOURCE” the best name here?  Sounds awfully generic.  How about
“JIMAGE” or “JIMAGE_RESOURCE”?

- Mark

14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

[mark . reinhold]

RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/

This change implements jlink plugins, and associated changes in the VM
and libraries, to support the following new jlink options:

  - --vendor-bug-url= overrides the vendor bug URL baked
into the build.  The value of the system property "java.vendor.url.bug"
will be .

  - --vendor-vm-bug-url= overrides the vendor VM bug
URL baked into the build.  This value will be displayed in VM error
logs.

  - --vendor-version= overrides the vendor version string
baked into the build, if any.  The value of the system property
"java.vendor.version" will be .  This value will be
displayed in the output of java --version.

  - --add-options= prepends the specified  string,
which may include whitespace, before any other options when invoking
the VM in the resulting image.

The vendor-information plugins work by using the JDK’s internal ASM
library to redefine static fields in the java.lang.VersionProps class.
The VM reads the vendor-version and vendor-vm-bug-url strings from that
class during startup.

The add-options plugin works by storing the requested options in an
internal resource, /java.base/jdk/internal/vm/options.  The VM loads that
resource from the lib/modules jimage file during startup and prepends any
options found there to those given on the command line.

Passes tier1-3 and JCK on {linux,macos,windows}-x64.

Thanks,
- Mark

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[mark . reinhold]

2018/10/3 12:13:15 -0700, kim.barr...@oracle.com:
> ...
> 
> https://bugs.openjdk.java.net/browse/JDK-8208089

Or, more readably: https://openjdk.java.net/jeps/8208089

- Mark

Re: RFR 8208183: update HSDIS plugin license to UPL

[mark . reinhold]

2018/8/21 7:25:58 -0700, volker.simo...@gmail.com:
> On Tue, Aug 21, 2018 at 12:14 PM, magnus.ihse.bur...@oracle.com wrote:
>> ...
>> 
>> I can easily add a new make target to build hsdis.
>> 
>> Adding a new binary to the OpenJDK images will require a CSR.
> 
> Do we really need a CSR for hsdis? hsdis is a shared library/DLL and
> not a "binary" which can be called by the user or executed
> stand-alone. The functionality offered by hsdis is only accessible by
> already existing command line parameters (like -XX:+PrintAssembly).
> 
> The CSR FAQ [1] only mentions (among others):
> 
> - Adding or removing a command in $JDK/bin
> - Adding, removing, or changing a command line option
> 
> which both don't seem to be applicable to hsdis.

The mere addition or removal of a shared library within the JDK image
does not, of itself, require a CSR -- unless it’s a shared library that
external code is expected to link against, which isn’t the case here.

If we wind up building hsdis by default, however, and thus including it
in the JDK image, then we’d effectively modify the behavior of the
existing -XX:+PrintAssembly option.  It’s a change to diagnostic
information, and so strictly speaking a CSR is not required, but it
would be both visible to and of potential interest to many developers,
so a CSR (and a release note) would be helpful.

If we wind up not building hsdis by default then it’s even more of a
borderline case.  If we think that many implementors would enable it
in their builds then a CSR would be helpful; if not, then I wouldn’t
bother.

- Mark

Re: RFR 8208183: update HSDIS plugin license to UPL

[mark . reinhold]

2018/8/21 11:11:00 -0700, john.r.r...@oracle.com:
> On Aug 21, 2018, at 9:41 AM, Andrew Haley  wrote:
>> On 08/21/2018 11:14 AM, Magnus Ihse Bursie wrote:
>>> Am I correct in understanding that there are no more legal barriers 
>>> towards doing such a thing anymore?
>> 
>> You'd still be linking GPLv2-only code (libjvm) against GPLv3-or-later
>> code (binutils).  IANAL, but I suspect you can't get around the GPLv3
>> that easily.
> 
> IANAL2 but bringing in a new set of source code into the OpenJDK build
> always requires care with IP issues, which AFAIK need to be triple checked
> by real Ls.

Indeed.

Magnus -- I suggest you hold off on this until interested contributors
can check with their legal teams.  (I’ll help you with Oracle’s legal
team.)

- Mark

Re: 11 RFR (XS) 8205956: Fix usage of “OpenJDK” in build and test instructions

[mark . reinhold]

2018/6/29 3:03:09 -0700, volker.simo...@gmail.com:
> This still doesn't explain why replacing one trademark with another
> one is helpful here.

Perhaps some trademarks are more important than others.

> After Phil's remark, OpenJDK doesn't even seem to be registered as a
> trademark, so in that sense the old version "Building the OpenJDK"
> seemed to be even more trademark law compliant.

I’m not qualified to engage in a legal argument, in this or any other
forum, and neither is Phil.  In this matter I am following the advice of
Oracle’s legal department regarding the usage of Oracle’s trademarks.

> And by the way, I totally agree with Aleksey that changes shouldn't be
> pushed if reviewers raise concerns (at least not before these concerns
> have been addressed).

My apologies.  I had no idea this would turn out to be such a volatile
issue.

- Mark

Re: 11 RFR (XS) 8205956: Fix usage of “OpenJDK” in build and test instructions

[mark . reinhold]

2018/6/27 23:21:34 -0700, volker.simo...@gmail.com:
> On Thu, Jun 28, 2018 at 12:08 AM, mark.reinh...@oracle.com wrote:
>> ...
>> 
>> “OpenJDK” is a trademarked term, per the OpenJDK Trademark Notice [1].
>> As such it should be used only as an adjective, and not as a noun.
>> Phrases such as “the OpenJDK” could be replaced by the more correct,
>> and much more verbose, “the OpenJDK JDK,” or “the open-source JDK,”
>> but in most cases the context is sufficiently clear that we can just
>> write “the JDK.”
>> 
> 
> Sorry, but I don't see any sense in this change!

Trademark law doesn’t always make a lot of sense.

> Do you plan to do the same for the OpenJDK web pages and the OpenJDK
> Wiki.

Yes, on a best-effort basis, but priority will be given to more-prominent
documents such as these.

>   Do you plan to scan all the OpenJDK mails and reject them if
> they use "OpenJDK" inappropriately?

No, of course not.  That’d be silly.

> And by the way, "JDK" is an Oracle trademark as well (see [1]) so this
> change is basically a NOP.

Trademark law doesn’t always make a lot of sense.

- Mark

Re: 11 RFR (XS) 8205956: Fix usage of “OpenJDK” in build and test instructions

[mark . reinhold]

2018/6/28 0:14:26 -0700, Aleksey Shipilev :
> On 06/28/2018 08:21 AM, Volker Simonis wrote:
>> Sorry, but I don't see any sense in this change!
> 
> +1
> 
> Also, "(open-source) JDK" is way too generic, and does awkwardly apply
> to other JDK's in the wild, including IBM's, Azul's, Excelsior's,
> etc.

Agreed.  That’s another reason not to use that term.

>  It stands to reason that build/test instruction for OpenJDK
> project use "OpenJDK" to describe what those instructions apply to. It
> seems less confusing to find the appropriate noun to go with
> "OpenJDK", e.g. "OpenJDK build", "OpenJDK binary", "OpenJDK
> workspace", etc?

Yes, we could do that, but why use even more words to describe what
everyone knows is just “the JDK”?

When we started the OpenJDK Community we intentionally chose not to
use “OpenJDK” in the names of the Projects that produce JDK feature and
update releases.  That’d just be redundant: “The OpenJDK Project in the
OpenJDK Community”?

Similar reasoning applies here.  The context of these instructions makes
it clear that they’re for the source code to a JDK implementation that
you found in the OpenJDK Community.  There’s no need to insert “OpenJDK”
everywhere.

- Mark

Re: 11 RFR (XS) 8205956: Fix usage of “OpenJDK” in build and test instructions

[mark . reinhold]

2018/6/27 16:19:58 -0700, tim.b...@oracle.com:
> Looks good to me as well.
> 
> Tim
> 
> On 06/27/18 15:33, Erik Joelsson wrote:
>> Looks good.
>> 
>> /Erik

Thanks!

- Mark

11 RFR (XS) 8205956: Fix usage of “OpenJDK” in build and test instructions

[mark . reinhold]

Bug: https://bugs.openjdk.java.net/browse/JDK-8205956
Webrev: http://cr.openjdk.java.net/~mr/rev/8205956/

Quick links to handier HTML diffs:

  http://cr.openjdk.java.net/~mr/rev/8205956/doc/building.html.hdiff.html
  http://cr.openjdk.java.net/~mr/rev/8205956/doc/testing.html.hdiff.html

“OpenJDK” is a trademarked term, per the OpenJDK Trademark Notice [1].
As such it should be used only as an adjective, and not as a noun.
Phrases such as “the OpenJDK” could be replaced by the more correct,
and much more verbose, “the OpenJDK JDK,” or “the open-source JDK,”
but in most cases the context is sufficiently clear that we can just
write “the JDK.”

- Mark


[1] http://openjdk.java.net/legal/openjdk-trademark-notice.html

Re: License and Usage Terms of generated API documentation

[mark . reinhold]

2018/5/3 13:16:11 +0100, volker.simo...@gmail.com:
> On Thu, May 3, 2018 at 12:21 PM, magnus.ihse.bur...@oracle.com wrote:
>> ...
>> 
>> Until a consensus of a better solution for hosting the generated
>> documentation is reached, I'd like to avoid changing the build code. That
>> will just open for an uneccessary split in what constitutes the proper
>> documentation URL.
> 
> The JAVADOC_BASE_URL is the minor issue here and I agree that it would
> be not easy to create a community driven documentation of the same or
> at least similar quality as we have today from Oracle.

We should publish the API Javadoc somewhere on OpenJDK at some point,
but that’s not something that we can do today -- if nothing else, we’d
have to set up a CDN to front these very popular pages.

>Nevertheless I
> don't see why we shouldn't be able to make this URL configurable at
> configure time.

Agreed.

> The main issue are the two links to "LICENSE_URL" and
> "REDISTRIBUTION_URL" which clearly refer to the API-docs published by
> Oracle. I just want to be able to publish these API-docs myself
> without having to refer to these restrictive licenses. The change
> itself, to make these URLs configurable at configure time, would be
> trivial (and again, I'm not against leaving the default "as-is" if
> this is important for you).

Making these things configurable is a fine idea, but I agree with Magnus
that it’d be simpler for now to retain the current values as defaults.

- Mark

Re: 10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build

[mark . reinhold]

2017/12/18 20:40:19 -0800, Martin Buchholz :
> On Mon, Dec 18, 2017 at 3:50 PM, mark.reinh...@oracle.com wrote:
>> I didn't know you'd requested this -- is there an existing issue?
> 
> https://bugs.openjdk.java.net/browse/JDK-8189761

Thanks.  I cross-linked that with 8193764, which addresses part of your
request, and added a comment to summarize what remains to be done.

- Mark

Re: 10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build

[mark . reinhold]

2017/12/18 15:36:03 -0800, Martin Buchholz :
> Mark, thanks for implementing my little feature request.  Looks good to me.

I didn't know you'd requested this -- is there an existing issue?

- Mark

10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build

[mark . reinhold]

Bug: https://bugs.openjdk.java.net/browse/JDK-8193764
Webrev: http://cr.openjdk.java.net/~mr/rev/8193764/

You can set COMPANY_NAME in make/autoconf/version-numbers, but you can't
set it when configuring a build, so it's impossible to change the value
of IMPLEMENTOR in the $JAVA_HOME/release file without patching the
source code.

This patch simply adds the obvious --with-vendor-name option to the
configure script.

(Motivation: I'm trying to arrange for IMPLEMENTOR to be "Oracle
 Corporation" in builds produced by Oracle, but this option may prove
 useful to other implementors.)

- Mark

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

[mark . reinhold]

2017/12/13 15:49:53 -0800, paul.san...@oracle.com:
> On 13 Dec 2017, at 14:36, mark.reinh...@oracle.com wrote:
>> I understand that other incoming changes are waiting for the 11 version
>> bump, but can't we at least do the straightforward parameterizations and
>> introduce _CURRENT constants in this round?  We can leave anything that
>> requires code generation to post-11.
> 
> On the lang tools side that does seem easy, but I’ll defer to Joe.
> 
> With some guidance from the build engineers i would gladly consolidate
> class file version declaration in C/++ files with a passed in macro,
> if this can be expediently worked out. I wanna push condy as early as
> possible in 11 :-)

Understood, but let's do the right thing (or at least closer to that)
with this yak while we're here.

> If we could do something in jvm.h that would be ideal. We already have
> the definitions JVM_CLASSFILE_MAJOR_VERSION and
> JVM_CLASSFILE_MINOR_VERSION pulled in via classfile_constants.h, so
> how can the build process inject values into those macros?

I just went through this for the versioning changes.  The attached patch
(against d2a837cf9ff1) does what you want, I think.

> For class file versions embedded in Java code it would make it easier
> if we had programmatic access. Perhaps we could have static methods on
> Runtime.Version to get the major/minor class file versions?

Sure, or maybe better to make them instance methods of Runtime.  Parsing
`System.getProperty("java.class.version")` every time is no fun.

- Mark
# HG changeset patch
# User mr
# Parent  d2a837cf9ff114d58612d4709766db989be6157e
Define the class-file version in make/autoconf/version-numbers

diff --git a/make/autoconf/generated-configure.sh b/make/autoconf/generated-configure.sh
--- a/make/autoconf/generated-configure.sh
+++ b/make/autoconf/generated-configure.sh
@@ -887,6 +887,8 @@
 BOOT_JDK
 JAVA_CHECK
 JAVAC_CHECK
+VERSION_CLASSFILE_MINOR
+VERSION_CLASSFILE_MAJOR
 VENDOR_VERSION_STRING
 VERSION_DATE
 VERSION_IS_GA
@@ -5185,7 +5187,7 @@
 #CUSTOM_AUTOCONF_INCLUDE
 
 # Do not change or remove the following line, it is needed for consistency checks:
-DATE_WHEN_GENERATED=1513206608
+DATE_WHEN_GENERATED=1513221877
 
 ###
 #
@@ -25457,6 +25459,10 @@
 VENDOR_VERSION_STRING="$with_vendor_version_string"
   fi
 
+  # We could define --with flags for these, if really needed
+  VERSION_CLASSFILE_MAJOR="$DEFAULT_VERSION_CLASSFILE_MAJOR"
+  VERSION_CLASSFILE_MINOR="$DEFAULT_VERSION_CLASSFILE_MINOR"
+
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for version string" >&5
 $as_echo_n "checking for version string... " >&6; }
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: $VERSION_STRING" >&5
@@ -25478,6 +25484,9 @@
 
 
 
+
+
+
 ###
 #
 # Setup BootJDK, used to bootstrap the build.
diff --git a/make/autoconf/jdk-version.m4 b/make/autoconf/jdk-version.m4
--- a/make/autoconf/jdk-version.m4
+++ b/make/autoconf/jdk-version.m4
@@ -331,6 +331,10 @@
 VENDOR_VERSION_STRING="$with_vendor_version_string"
   fi
 
+  # We could define --with flags for these, if really needed
+  VERSION_CLASSFILE_MAJOR="$DEFAULT_VERSION_CLASSFILE_MAJOR"
+  VERSION_CLASSFILE_MINOR="$DEFAULT_VERSION_CLASSFILE_MINOR"
+
   AC_MSG_CHECKING([for version string])
   AC_MSG_RESULT([$VERSION_STRING])
 
@@ -348,4 +352,7 @@
   AC_SUBST(VERSION_IS_GA)
   AC_SUBST(VERSION_DATE)
   AC_SUBST(VENDOR_VERSION_STRING)
+  AC_SUBST(VERSION_CLASSFILE_MAJOR)
+  AC_SUBST(VERSION_CLASSFILE_MINOR)
+
 ])
diff --git a/make/autoconf/spec.gmk.in b/make/autoconf/spec.gmk.in
--- a/make/autoconf/spec.gmk.in
+++ b/make/autoconf/spec.gmk.in
@@ -175,6 +175,10 @@
 # Vendor version string
 VENDOR_VERSION_STRING := @VENDOR_VERSION_STRING@
 
+# Class-file version
+VERSION_CLASSFILE_MAJOR := @VERSION_CLASSFILE_MAJOR@
+VERSION_CLASSFILE_MINOR := @VERSION_CLASSFILE_MINOR@
+
 # Convenience CFLAGS settings for passing version information into native programs.
 VERSION_CFLAGS := \
 -DVERSION_FEATURE=$(VERSION_FEATURE) \
@@ -190,6 +194,8 @@
 -DVERSION_SPECIFICATION='"$(VERSION_SPECIFICATION)"' \
 -DVERSION_DATE='"$(VERSION_DATE)"' \
 -DVENDOR_VERSION_STRING='"$(VENDOR_VERSION_STRING)"' \
+-DVERSION_CLASSFILE_MAJOR=$(VERSION_CLASSFILE_MAJOR) \
+-DVERSION_CLASSFILE_MINOR=$(VERSION_CLASSFILE_MINOR) \
 #
 
 # Platform naming variables
diff --git a/make/autoconf/version-numbers b/make/autoconf/version-numbers
--- a/make/autoconf/version-numbers
+++ b/make/autoconf/version-numbers
@@ -30,6 +30,8 @@
 DEFAULT_VERSION_UPDATE=0
 DEFAULT_VERSION_PATCH=0
 DEFAULT_VERSION_DATE=2018-03-20
+DEFAULT_VERSION_CLASSFILE_MAJOR=56  # "`$EXPR $DEFAULT_VERSION_FEATURE + 44`"
+DEFAULT_VERSION_CLASSFILE_MINOR=2
 
 LAUNCHER_NAME=openjdk
 PRODUCT_NAME=OpenJDK
diff --git a/src/java.base/share/native/include/classfile_constants.h 

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

[mark . reinhold]

2017/12/13 14:09:44 -0800, paul.san...@oracle.com:
>> On 13 Dec 2017, at 13:18, mark.reinh...@oracle.com wrote:
>> How much of this can we parameterize and/or automate?
> 
> I suspect quite a bit, as you present below, and i agree we should try
> and automate as much as possible. At the moment it’s very
> spaghetti-like and quite fragile.
> 
> I suggest we get the initial version bump for 11 out of the way as
> soon as JDK 10 branches off from the mainline then work on automation
> for subsequent releases.

I understand that other incoming changes are waiting for the 11 version
bump, but can't we at least do the straightforward parameterizations and
introduce _CURRENT constants in this round?  We can leave anything that
requires code generation to post-11.

- Mark

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

[mark . reinhold]

2017/12/13 8:44:33 -0800, paul.san...@oracle.com:
>> On 12 Dec 2017, at 20:56, david.hol...@oracle.com wrote:
>> 
>> Anyway, none of the proposed changes have any impact on hotspot
>> AFAICT. It is only when the actual version is updated to 11 that
>> hotspot, and other entities will have to be updated. I'm still
>> unclear if someone is actually driving the entire "update to version
>> 11" process? Is there an umbrella issue for it?
> 
> No yet, i was hoping we could consolidate as much as possible under
> one issue thereby minimising coordination/process i.e. combine the
> release and class file versions under one patch. Then stand back and
> see what is missing e.g. ctsym stuff etc.

How much of this can we parameterize and/or automate?  We are going to
have to do it every six months, after all.

Could we define a CLASSFILE_VERSION in make/autoconf/version-numbers and
then propagate that value everywhere else?  (In any actual release it'll
be VERSION_FEATURE + 44, but make it a separate variable to allow for
experimentation as with, e.g., MVT.)

Looking at Joe's webrev, many of the changes from 10 to 11 could instead
be changed to Runtime.getRuntime().version().major() (in Java code) or
VERSION_FEATURE (in Makefiles).

In javax.lang.model.SourceVersion we could define a new constant, say
RELEASE_CURRENT, whose value is that of the latest release.  Then
annotations such as

  @SupportedSourceVersion(SourceVersion.RELEASE_11)

could be replaced by

  @SupportedSourceVersion(SourceVersion.RELEASE_CURRENT)

Similarly, JDK_CURRENT could be defined in com.sun.tools.javac.Target
and then many references to JDK10 could instead refer to that.

In cases where additional code is needed, can we generate it during
the build via another Gensrc*.gmk Makefile?  That'd be more work now,
but it could save us a lot of time in the long run.

- Mark

Re: RFR(XXS): 8189919: Update link to license in Docs.gmk

[mark . reinhold]

2017/10/26 9:11:08 -0700, iris.cl...@oracle.com:
> Please review this small change to update the link to the
> 
> Specification license referenced by the JavaDoc API.  For
> 
> JDK 10, we should reference the 10 redirect.
> 
> Bug:
> 
>  
> 
> 8189919: Update link to license in Docs.gmk
> 
> https://bugs.openjdk.java.net/browse/JDK-8189919
> 
>  
> 
> webrev:
> 
>  
> 
> http://cr.openjdk.java.net/~iris/8189919/webrev/

Looks good to me.

- Mark

Re: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes

[mark . reinhold]

2017/6/30 16:08:09 -0700, jonathan.gibb...@oracle.com:
> Mark,
> 
> The font-family settings in the  nodes were deliberate, and a 
> workaround for not having time to create a proper taglet for tool guides.
> 
> If you remove the style attribute, you'll see in your sample output that 
> the "Tool Guides" header is in Serif font, but the immediately following 
> "Since: "  header is in the standard Sans Serif font.
> 
> See, for example, this page:
> http://cr.openjdk.java.net/~mr/rev/8182776/api/jdk.compiler-summary.html

You're right, but the problem with placing the style attribute on the
`` elements is that it forces the `` text into the sans-serif
font.  That's fine for the tool-guide links, since they're tool names,
but it's wrong for provider descriptions, which are free text (see the
attached image).

The right fix is to repair the Javadoc stylesheet, but the expedient fix
is to tweak the style attributes just where needed, so I've updated the
patch to do the latter:

  http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch
  http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output)

- Mark

RFR 8182776/8183161/8183251: Miscellaneous API doc fixes

[mark . reinhold]

8182776: Fix typo "upgradeble" in the javadoc of upgradeable modules
8183161: Remove extraneous font-family style attributes from module declarations
8183251: Meta "keywords" tag malformed in overview-summary.html and related 
pages

http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch
http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output)

None of these is truly P1 but they're all fairly embarrassing and the
fixes are low-risk, so since we know we're going to do another build next
week anyway I'd like to include this patch.

The fix for 8183251 doesn't solve the problem of `` occurring inside
``, but this only ever happens in the frame-summary pages and appears
to do no harm when rendered.

This patch includes a few minor editorial fixes, e.g., changing `@link`
tags to `@linkplain` where appropriate in module declarations.

Thanks,
- Mark

Re: RFR 8167227: Simplify the JDK 9 API-specification overview page (docs only)

[mark . reinhold]

2017/6/19 10:41:09 +0200, erik.joels...@oracle.com:
> Looks good to me.
> 
> The change to the log message is a bit weird. Was this meant as a 
> temporary way for finding the output file?

Good catch -- yes, that was temporary.  I'll remove it.

Thanks,
- Mark

RFR 8167227: Simplify the JDK 9 API-specification overview page (docs only)

[mark . reinhold]

http://cr.openjdk.java.net/~mr/rev/8182408/
https://bugs.openjdk.java.net/browse/JDK-8182408

This is a follow-on to Magnus's changes for 8175824.

Oracle's legal department has recently advised that the liberal use of
trademark symbols on the API-specification overview page is not required.
We should, rather, just include a registered-trademark symbol ()
after the first prominent instance of "Java". The warnings about the
provisional nature of the API can also be simplified.

The webrev page contains links to example Javadoc output for different
variants: GA vs. ad-hoc, and SE + JDK + FX vs. SE + JDK vs. just SE.

Current output, for reference:
http://download.java.net/java/jdk9/docs/api/overview-summary.html

Thanks,
- Mark

Re: RFR: JDK-8172312 Update docs target and image for new combined docs

[mark . reinhold]

2017/4/4 12:28:18 -0700, jonathan.gibb...@oracle.com:
> Don't we need the JEP to be moved from "Proposed To Target" to 
> "Targetted" before we can push?

Yep.  Coming right up ...

- Mark

Re: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

[mark . reinhold]

2017/4/4 8:22:50 -0700, a...@redhat.com:
> On 04/04/17 16:12, mark.reinh...@oracle.com wrote:
>> The trouble here is that "arm64" and "aarch64" are effectively synonyms
>> for the ISA, but in the JDK we've wound up using them as the names of
>> two different ports.
>> 
>> A JMOD file built for the 64-bit ARM architecture will (one hopes) run
>> equally well on either port.  Which name should we use in JMOD files,
>> "arm64" or "aarch64"?  My sense is that "arm64" is more immediately
>> understood by developers at large even if "aarch64" is more correct
>> in the eyes of ARM Holdings plc, but I could be wrong.
> 
> I think that you are wrong.
> 
>> For what it's worth, the Linux distros aren't consistent: Debian-based
>> distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64".
> 
> The name of the processor architecture is "AArch64".  The name of the
> Linux kernel architecture is "arm64"; the name of all of userspace is
> "aarch64", on all distros.  The kernel is out of step here, for no
> better reason than Linus Torvalds didn't like "aarch64".

Thanks for the background -- I wasn't aware of that.

Given that "os.arch" is "aarch64" for both ports, as Bob points out,
then we should use "aarch64" in JMOD files as well.

This does raise another question, though: Should we use "aarch32"
instead of "arm32" for the 32-bit ARM architecture?

- Mark

Re: RFR: JDK-8172312 Update docs target and image for new combined docs

[mark . reinhold]

2017/4/4 4:47:58 -0700, magnus.ihse.bur...@oracle.com:
> Here is an updated webrev:
> http://cr.openjdk.java.net/~ihse/JDK-8172312-combined-javadocs/webrev.03
> 
> The only change compared to the previous webrev is that I have updated 
> the title for the JDK javadocs so it does not claim to be Java SE.
> 
> I have filed the following follow-up bugs to address Mark's concerns, 
> and concerns expressed elsewhere:
> 
> * JDK-8178043 Group Java SE, JDK and JavaFX modules in unified javadoc [1]
> * JDK-8178037 Move information from jdi-overview.html into jdk.jdi 
> module-info.java [2]
> * JDK-8178038 Copy jdwp-protocol.html to proper location [3]
> * JDK-8178039 Copy jvmti.html to proper location [4]
> 
> I hope JDK-8178043 captures the intent of the solution I understand that 
> Mark and Jon seemed to agree upon.

Yes, I think it does.  Thanks for filing it.

- Mark

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

[mark . reinhold]

2017/4/4 1:04:22 -0700, magnus.ihse.bur...@oracle.com:
> On 2017-04-03 23:50, Mandy Chung wrote:
>> ...
>> 
>>JDK 8   JDK 9
>>-   -
>> OS_NAMELinux   linux
>>SunOS   solaris
>>Darwin  macos
>>Windows windows
>> 
>> OS_ARCHi386,x86x86
>>i586,amd64,x86_64   amd64
>>sparcv9 sparcv9
>>arm arm32
>>aarch64 arm64
> 
> If we are making changes to the original proposal from JDK-8175819, then 
> I just want to add my few cents:
> 
> Why change from the well-established "aarch64" to the virtually unused 
> "arm64"? As far as I know, using the name "arm64" for the aarch64 
> platform is something that has only been done in the (recently opened) 
> closed Oracle port. This change, however, proposes to change the value 
> in the release file even for the open aarch64 port, which has always 
> been known by that name.

The trouble here is that "arm64" and "aarch64" are effectively synonyms
for the ISA, but in the JDK we've wound up using them as the names of
two different ports.

A JMOD file built for the 64-bit ARM architecture will (one hopes) run
equally well on either port.  Which name should we use in JMOD files,
"arm64" or "aarch64"?  My sense is that "arm64" is more immediately
understood by developers at large even if "aarch64" is more correct
in the eyes of ARM Holdings plc, but I could be wrong.

For what it's worth, the Linux distros aren't consistent: Debian-based
distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64".

- Mark

Re: RFR: JDK-8172312 Update docs target and image for new combined docs

[mark . reinhold]

2017/4/3 11:01:13 -0700, jonathan.gibb...@oracle.com:
> I agree there will need to be some cosmetic cleanup with respect to 
> headings. Given the optionality of whether or not the build is set to 
> import JavaFX, the headings and content of the new overview page will 
> need to be somewhat synthesized.

Is it possible to have (up to) three sections of modules on the front
page, where the first is headed by an orange "Java SE Modules" box, the
second is "JavaFX Modules", and the third is "JDK Modules"?

That, plus an updated title and some prose to explain that the first
section is standard and the rest are not, would probably do the trick.

> The advantage of being able to generate a single big bundle is that the 
> new "javadoc Search" feature will work as expected.  If we partition the 
> docs, then the scope of any search will be restricted to the subset of 
> docs currently being viewed.

I agree that a unified search experience is very useful.

- Mark

Re: RFR: JDK-8172312 Update docs target and image for new combined docs

[mark . reinhold]

2017/4/3 3:24:52 -0700, magnus.ihse.bur...@oracle.com:
> I think the distinction you ask for is already there. The two separate 
> make targets "docs-javadoc" and "docs-reference" builds two distinct 
> images "docs" and "javase-docs", respectively. The first of these builds 
> the complete Java SE + JDK documentation, the second build just the Java 
> SE documentation.

I'm glad that there's an SE-only target, but that's not what I asked
for.

> I do not think it's a good idea to go further and actually *remove* the 
> Java SE part from the complete "docs" image.

That's not what I asked for, either.  I suggested making a stronger
distinction between the specifications of the SE APIs and those of the
rest of the JDK, by putting the latter in a subdirectory of the same
image.  Sorry if that wasn't clear.

>  Upholding such a formal 
> difference between different parts of the JDK is likely to be just 
> confusing to common Java developers. I believe that enforcing such a cut 
> would eliminate much of the work that has been put into giving the the 
> Java developer community a unified access to all releveant documentation.

I see your point, but failing to make a strong distinction could also
confuse developers, since it may lead some to use JDK-specific APIs when
they really want to write code that's portable to any SE implementation.

Still, there may be better ways to make that distinction, as Jon suggests
nearby.

> With that said, we should change the heading so that only the 
> javase-docs image claims to be the SE specification.

Yes, we must do that, at a bare minimum.

- Mark

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

[mark . reinhold]

2017/4/3 14:50:52 -0700, mandy.ch...@oracle.com:
>> On Apr 3, 2017, at 2:39 PM, mark.reinh...@oracle.com wrote:
>> 2017/4/3 13:35:30 -0700, si...@cjnash.com:
>>> ...
>>> 
>>> I am not sure why we would change to osx for Mac when the Mac developers
>>> have recently dropped the Mac OS X terminology and changed it to macOS.
>> 
>> Agreed -- we should change OS_NAME from "Darwin" to "macos”.
> 
> OK.  Should the bundle names be updated to reflect this change?

Probably not worth doing at this late stage in 9; let's fix these in 10.

> In any case, it is a separate issue.

Yep.

>JDK 8   JDK 9
>-   -
> OS_NAMELinux   linux
>SunOS   solaris
>Darwin  macos
>Windows windows
> 
> OS_ARCHi386,x86x86
>i586,amd64,x86_64   amd64
>sparcv9 sparcv9
>arm arm32
>aarch64 arm64

Looks good.

Thanks,
- Mark

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

[mark . reinhold]

2017/4/3 13:35:30 -0700, si...@cjnash.com:
> On 03/04/2017 21:15, mark.reinh...@oracle.com wrote:
>> 2017/4/3 11:41:03 -0700, mandy.ch...@oracle.com:
>>> Webrev:
>>>  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
>>> 
>>> ...
>>> 
>>> This shows the old and new value of OS_NAME/OS_ARCH properties
>>> in the `release` file:
>>> 
>>>JDK 8   JDK 9
>>>-   -
>>> OS_NAME Linux   linux
>>>SunOS   solaris
>>>Darwin  osx
>>>Windows windows
>>> 
>>> OS_ARCH i386,x86x86
>>>i586,amd64,x86_64   x64
>>>sparcv9 sparcv9
>>>arm arm32
>>>aarch64 arm64
> 
> I am not sure why we would change to osx for Mac when the Mac developers
> have recently dropped the Mac OS X terminology and changed it to macOS.

Agreed -- we should change OS_NAME from "Darwin" to "macos".

- Mark

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

[mark . reinhold]

2017/4/3 11:41:03 -0700, mandy.ch...@oracle.com:
> Webrev:
>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
> 
> ...
> 
> This shows the old and new value of OS_NAME/OS_ARCH properties
> in the `release` file:
> 
> JDK 8   JDK 9
> -   -
> OS_NAME Linux   linux
> SunOS   solaris
> Darwin  osx
> Windows windows
>  
> OS_ARCH i386,x86x86
> i586,amd64,x86_64   x64
> sparcv9 sparcv9
> arm arm32
> aarch64 arm64

I suggest we use "amd64" instead of "x64" (or any other variants).
"x64" is confusingly close to "x86", and while it's used by some
companies (including Oracle), it's not used all that widely.  "amd64" is
better known, matches the long-standing value of the "os.arch" system
property (on Linux and Windows, anyway) and, as a side benefit, honors
the originators of the architecture.

- Mark

Re: RFR: JDK-8172312 Update docs target and image for new combined docs

[mark . reinhold]

2017/3/30 6:05:43 -0700, magnus.ihse.bur...@oracle.com:
> As a part of JEP 299, we should build the Javadoc as a single combined 
> output, instead of a dozen or so individual javadoc bundles. This bug 
> fixes this. The selection on what to include is now based on modules 
> instead of packages.

I'm worried that perhaps we've unified a bit too much here.

This patch does build all the Javadoc together, as advertised, but that
places the `jdk.*` modules together with the `java.*` modules under the
heading "Java Platform, Standard Edition 9 API Specification", and of
course the `jdk.*` modules aren't part of that spec.

JDK 9 is the "Reference Implementation" (in JCP terms) of Java SE 9, so
it's important to keep a clear distinction between the SE-standard parts
of the spec and those that are JDK-specific.

Would it make sense instead to have `docs/api` be just for the SE (i.e.,
`java.*`) modules, and then place the Javadoc for the `jdk.*` modules
under `docs/api/jdk`?  There could be a helpful link from the SE API
title page to the JDK API title page, but it should make it clear that
the JDK APIs aren't part of the SE spec.

- Mark

Re: New lead for the JDK 6 Project: Andrew Brygin

[mark . reinhold]

2017/1/6 7:30:28 -0800, tim.b...@oracle.com:
> Andrew Haley has resigned as lead for the JDK 6 Project [1].
> 
> Under the bylaws for Project Roles [2], a new Project Lead may be
> nominated by the Group Leads of the Project's sponsoring groups.
> 
> The Build Infrastructure Group is sponsor of the project.  As Group
> Leader, I would like to nominate Andrew Brygin [3] to be the new
> Project Lead.
> 
> The Build Infrastructure Group is the only sponsoring group for this
> project.  I believe that makes the nomination automatically approved.

So recorded.

- Mark

Re: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version

[mark . reinhold]

2015/5/21 12:01 -0700, jan.lah...@oracle.com:
 This is a patch adding a new option, -platform, to javac.
 
 Patch for the top-level repository is here:
 http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/
 
 Patch for the langtools repository is here:
 http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/
 
 These changes also require additional langtools changes as their 
 prerequisite:
 http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/

Nice work -- I'm glad to see this coming in.

What's the rationale for putting the symbol generator and all its data
in the top-level repo?  That'll add quite a bit of heft to a repo that's
always been intended to remain fairly lightweight.  Wouldn't it make
more sense for this code and data to be placed in the langtools repo?
Or is there some sort of build-bootstrapping issue here?

- Mark

Re: OpenJDK Governing Board CFV: New Build Group Lead: Tim Bell

[mark . reinhold]

2015/1/20 9:28 -0800, mark.reinh...@oracle.com:
 Kelly O'Hair resigned as the Lead of the Build Group in April 2014 [1].
 Tim Bell was voted in as the new Group Lead shortly thereafter [2].
 (Unfortunately this particular change slipped through the cracks, which
  is why you're only hearing about it now.  My apologies.)
 
 Governing Board members: Please vote on whether to ratify this change, as
 required by the Bylaws [3].  Votes are due in one week, by 18:00 UTC next
 Tuesday, 27 January 2015.  Votes must be cast in the open by replying to
 this message.

Thank you for your votes.  A majority have voted in favor of
ratification, so this vote can close early.

Tim Bell is now the Lead of the Build Group.

- Mark

Re: Adding Microbenchmarks to the JDK forest/trees (JEP-230)

[mark . reinhold]

2014/12/4 9:51 -0800, staffan.frib...@oracle.com:
 On 12/03/2014 02:58 AM, Magnus Ihse Bursie wrote:
 ...
 
 My suggestion is that the microbenchmarks are put in the top-level 
 repo, if only for the reason that it seems fully possible to split 
 them out to a separate repo some time in the future if it grows too 
 much, but it seems much more unlikely that it will ever be moved back 
 into the top-level repo if we realized it was a stupid idea to put it 
 in a separate repo.
 
 I like this idea, and agree that shifting in the opposite direction is 
 probably something that would be much more work than breaking it out if 
 size becomes an issue further down the road.
 
 When moving a directory to a new sub-repository, is there any concern 
 about the diffs for that set of files still lingering in the top repo, 
 or can those be moved as well?

The files can be moved, but their earlier history will remain in the
top-level repo.

Given the forest structure that we have today, and the fact that this
set of tests could grow to a thousand or so files over time, I think it
makes more sense to place them in a new top-level repo of their own.

In the (very?) long term we might dramatically reduce the number of
repositories but that will be a huge change, and in the mean time adding
one more repo is a pretty minor change and also consistent with current
practice.

A pleasant property of the current root repo is that it's very small
( 9MB) and easy to understand, containing mostly makefiles, build
utilities, and some metadata.  Placing tests in it would start turning
it into more of a grab-bag.

I don't think it makes sense to split the microbenchmarks across
different repos, as we already do with the unit and regression tests.

The latter types of tests primarily address the correctness of the code
in one repo, on the assumption that any code in other repos upon which
that code depends is correct.  In most cases, therefore, it's pretty
easy to tell whether a unit or regression test is specific to, say, the
jdk repo, the langtools repo, or some other repo.

Microbenchmarks, by contrast, address the performance of a particular
API, language construct, or other programmatic interface and also all of
the code upon which it depends, regardless of which repo it came from.
By nature they're more holistic, and so less strongly associated with
the code in any particular repo.

- Mark

Re: Adding Microbenchmarks to the JDK forest/trees (JEP-230)

[mark . reinhold]

2014/12/1 4:08 -0800, staffan.frib...@oracle.com:
 Hopefully this is the right list for this discussion.

This change is going to affect many more people than just those
interested in the build.  Suggest you float this on jdk9-dev.

- Mark

Re: JDK-8025705

[mark . reinhold]

2014/4/22 21:23 -0700, kmcgui...@twitter.com:
 Yes, I did consider using some ifeq tricks like that -- but they are rather
 ugly and unreadable and have the same problem that you want to avoid:
 adding distribution-specific code into the open-source makefiles.
 
 My goal here is to have the public OpenJDK makefiles be in a state such
 that custom distribution code can be added (in make/closed, src/closed, or
 some such alternative location) without having to perform surgery on the
 Makefiles and maintain the private changes.  The mechanism is already in
 place,it's just some leftover OracleJDK that hasn't made it out of the open
 makefiles yet.  If we could just cordon that off somehow, then anyone could
 make a custom distribution by augmenting OpenJDK with 'closed' style
 repositories -- without having to maintain private, unrelated edits to jdk
 Makefiles.

I'm confused.

Even if we replace `ifndef OPENJDK` with `ifdef ORACLEJDK`, how does
this help you?  In those cases where you want an open Makefile to refer
to code in Twitter's internal src/closed directory aren't you still
going to have to create and maintain your own patches to the open
Makefile?

Just trying to understand the problem here ...

- Mark

Re: JDK-8025705

[mark . reinhold]

2014/4/16 14:52 -0700, david.hol...@oracle.com:
 src/closed is Oracle's custom source location (hotspot calls it 
 alt_src). If we never saw src/closed in the makefiles, only 
 CUSTOM_SRC_DIR, and guarded with an existence test for a specific 
 directory/file, then that should address your problem. That would be a 
 first step in moving things to the custom makefiles where they belong.
 
 I'm opposed to the ORACLEJDK variable because I want to maintain the 
 pressure to get this fixed properly. If we hack around it then it will 
 never get cleaned up.

I think it's wrong, in principle, for OpenJDK source code to contain
identifiers naming specific vendors of JDK implementations.  We're not
quite there at the moment, but let's please not add any more.

- Mark

Re: Code review request: 8031372 JDK 9 Specification-Version in jar files is still 1.8

[mark . reinhold]

2014/1/8 16:47 -0800, erik.joels...@oracle.com:
 ...
 
 For the future, is there a reason for not automatically generating the 
 specification-version based on the version numbers we have, or at 
 least move the definition of it to the version numbers file?

Excellent question.  We should try to minimize the number of places
where version numbers need to be changed.

- Mark

Re: J2SE est mort, vive Java SE!

[mark . reinhold]

2013/11/26 8:29 -0800, david.hol...@oracle.com:
 On 27/11/2013 8:49 AM, mark.reinh...@oracle.com wrote:
 Now that we've removed the old build system, can we please now
 remove the last vestiges of Sun's pre-Java 5 naming scheme?
 
 There are also a bunch of security libs with j2 in their names - should 
 these be renamed too, or will that cause too many compatibility issues?

Those should be renamed too, eventually, but they're hardly visible and
so less urgent.

 ...
 
 Simple to fix in the build files, but probably somewhat more difficult 
 to coordinate with any necessary changes in external build/test systems. 
 :( Might also cause an issue for some that continue to use the same 
 build logic for 7u and 8u builds - but presumably this change is 
 targetted to 9.

No, 8.

- Mark

Re: J2SE est mort, vive Java SE!

[mark . reinhold]

2013/11/26 23:33 -0800, sean.mul...@oracle.com:
 On 11/27/2013 03:41 AM, Alan Bateman wrote:
 The security providers have vestiges of Sun in the provider names (SUN,
 SunPKCS11, SunJSSE ..) but these are documented and I don't think can be
 changed (although it not recommended to select services from specific
 providers). To my knowledge, the names of the shared libraries are not
 something that anyone should depend on, they are purely an
 implementation detail. I'm sure someone in the security area with jump
 to review any proposed changes here but I wouldn't expect it to cause
 problems.
 
 Changing the provider names is a very high risk change to make this late 
 in JDK 8. If we decided to change them, I would recommend deprecating 
 (but not removing) the existing Sun* providers for at least one major 
 release to allow apps to transition.
 
 Removing sun from the names of the JAR files (ex: sunjce_provider.jar, 
 sunpkcs11.jar, sunec.jar) is probably less risky from a compatibility 
 perspective, but I would still want to think about it some more and find 
 out if this would break anyone. Offhand, it  feels like this type of 
 change would be risky for JDK 8.

I didn't suggest that we remove the string sun from the names and
content of various artifacts in the build.  That's a risky and expensive
change.

I just want to stamp out the j2 prefix -- one of Sun's more egregious
marketing mistakes.

- Mark

J2SE est mort, vive Java SE!

[mark . reinhold]

Now that we've removed the old build system, can we please now
remove the last vestiges of Sun's pre-Java 5 naming scheme?

I refer in particular to these directories in a typical build:

  images/j2re-image
  images/j2sdk-image
  images/j2sdk-server-image

The j2 nomenclature hasn't been used since 1.4.2.  These should
be named jre-image, jdk-image, and jdk-server-image.

Thanks,
- Mark

Re: Le roi est mort, vive le roi!

[mark . reinhold]

2013/11/18 2:02 -0800, magnus.ihse.bur...@oracle.com:
 So, finally it has happened. The old build system is now removed. ...

Huzzah!

- Mark

Re: Removal of the old build system, partial review

[mark . reinhold]

2013/10/31 2:41 -0700, kellyoh...@gmail.com:
 With build logic, it is relatively easy to build before and after and
 verify the exact same resulting bits.
 
 So the risk is considerably less than in other areas of software
 development.  There might be more risk leaving it in, where the wrong
 build logic gets changed to fix an issue, or the old build logic
 continues to be used and maintained.
 
 Assuming that you may be supporting jdk8 updates for a long time, the
 long term maintenance cost could be significant. And if you declare
 that it won't be supported, why keep it.

I agree.  If it's too risky to remove the old build at this point
in JDK 8 then it will be too risky to remove it in any JDK 8 update
release, and we'll be stuck dragging this albatross around until
JDK 9.

- Mark

INFO: ENABLE_FULL_DEBUG_SYMBOLS=1, etc., in build log

[mark . reinhold]

The following lines are repeated over and over when building JDK 8:

  INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
  INFO: ALT_OBJCOPY=/usr/bin/objcopy 
  INFO: /usr/bin/objcopy cmd found so will create .debuginfo files.
  INFO: STRIP_POLICY=min_strip
  INFO: ZIP_DEBUGINFO_FILES=1

It seems like a lot of noise.  Is there a reason for it?

- Mark

Re: INFO: ENABLE_FULL_DEBUG_SYMBOLS=1, etc., in build log

[mark . reinhold]

2013/6/5 10:22 -0700, david.hol...@oracle.com:
 This comes from hotspot build. The FDS processing happens in a file that 
 is included a number of times due to the nested make invocations that 
 happen with hotspot. Consequently this gets repeated a few times 
 (actually fewer than it used to) for each JVM built.

I count 14 in a normal build of b92 -- it was a lot more in the past,
but maybe that was with the old build system.

 I think we should change this so that is only triggered when a more 
 verbose logging level is requested - and try to find a way to only 
 report it once.

Yes, that makes sense.

 I will file a bug.

Thanks!

- Mark

Re: Windows configure issues

[mark . reinhold]

2013/5/21 6:54 -0700, gnu.and...@redhat.com:
 On 05/21/2013 04:55 PM, Volker Simonis wrote:
 I always felt that having the build instructions checked in into the
 repository is somewhat to heavyweight.
 
 There are two good reasons to do this.
 
 Firstly, it's a free software tradition: I expect to find a README with
 build instructions in the repo.  Secondly, the build instructions will
 change over time, so of they're on a Wiki there will have to be
 multiple versions.
 
 Andrew.
 
 Another reason is it makes the software self-contained; I don't need Internet
 access and a web browser to be able to build it.

I agree, on all three counts.  How-to-build documents, just like unit
tests, belong with the code to which they apply.  Posting them on a
wiki just increases inconvenience and invites confusion.

- Mark

Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds)

[mark . reinhold]

2013/5/9 2:10 -0700, gnu.and...@redhat.com:
 Indeed.  I do this with the Oracle patches when applying them to IcedTea.
 The problem is how this gets done is down to the sponsor; I've had ones
 that have been imported, ones where I've just been giving the Contributed-by
 attribution (despite having commit rights) and at least one with no credit at
 ...
 
 An example I just came across when looking into an issue:
 
 changeset:   2657:46cb9a7b8b01
 parent:  2647:ca1f1753c866
 user:dsamersoff
 date:Wed Aug 10 15:04:21 2011 +0400
 files:   src/share/vm/runtime/os.cpp
 description:
 7073913: The fix for 7017193 causes segfaults
 Summary: Buffer overflow in os::get_line_chars
 Reviewed-by: coleenp, dholmes, dcubed
 Contributed-by: a...@redhat.com
 
 That should have had 'aph' as the user.  If you get the default output:
 
 changeset:   2657:46cb9a7b8b01
 parent:  2647:ca1f1753c866
 user:dsamersoff
 date:Wed Aug 10 15:04:21 2011 +0400
 summary: 7073913: The fix for 7017193 causes segfaults
 
 it looks like Dmitry wrote the fix.

I'm sure there was no intent on Dmitry's part to try to claim credit for
this fix.

The most important principle to be maintained here is that people get
proper credit for their work, as you wrote earlier.

Beyond that, it's reasonable to prefer that credit be given in the most
obvious way, in particular by using proper usernames, when available,
in changesets.  If a sponsor makes a mistake, however, and winds up
using a Contributed-by: line instead, then that's unfortunate but not,
in my view, the end of the world.

In general, if you have the Author role (or higher) in some OpenJDK
Project then when you submit a change that requires a sponsor's help you
should send a Mercurial patch (hg export) or bundle (hg bundle) with the
proper username, summary, etc.  In normal circumstances the sponsor
should not change the patch but merely make sure that it's properly
tested, merged, and pushed.  If a change is required then the sponsor
should ask the submitter to create a new patch or bundle.  If for some
reason the sponsor must modify the patch directly then the hg -u option
should be used, as appropriate, to preserve the submitter's user name in
the changeset.  (Yes, this is one of those rare cases in which a sponsor
should use the -u option.)

Iris -- Could you please make a note to add guidance on this issue to
the next revision of the developers' guide?  Thanks.

- Mark

Re: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds)

[mark . reinhold]

2013/5/9 8:14 -0700, philip.r...@oracle.com:
 (Yes, this is one of those rare cases in which a sponsor should use 
 the -u option.)
 
 I'd hazard a guess that there are number of people who overlook this option
 in part because they don't realise you can do
 
 hg commit -u SOMEBODY-ELSE ...
 
 I was kind of surprised myself when I first learned to do this as it
 seemed odd that someone else could claim a changeset was from
 another person. I thought you would need their private key to
 be able to do that.

No, your ssh key is used only to authenticate you to the hg server when
you do a push.  Modulo the constraints imposed by jcheck, you can use
the -u option to set the username string to anything you want.

FYI, in recent versions of Mercurial the -u option is, conveniently,
supported in commands other than commit, e.g., import, qnew, and qref.

- Mark

Re: Request for review: 8009529: Fix for 8006988 missed closed configure changes

[mark . reinhold]

2013/3/5 11:39 -0800, david.hol...@oracle.com:
 We need to regenerate the open and closed configure scripts in the tl 
 forest.
 
 The open change is trivial as it just updates the timestamp:
 
 hg diff
 diff -r c4901c0e0579 common/autoconf/generated-configure.sh
 --- a/common/autoconf/generated-configure.sh
 +++ b/common/autoconf/generated-configure.sh
 @@ -3725,7 +3725,7 @@
   #CUSTOM_AUTOCONF_INCLUDE
 
   # Do not change or remove the following line, it is needed for 
 consistency checks:
 -DATE_WHEN_GENERATED=1362517596
 +DATE_WHEN_GENERATED=1362540061
 
  
 ###
   #
 
 I need a nocturnal Reviewer please :)

Looks good to me.

(Sigh, we really need to fix this very brittle system ...)

- Mark

Re: invalid bug IDs aborting my pull

[mark . reinhold]

2012/11/14 8:17 -0800, peter.bru...@oracle.com:
 I looked in jcheck.py and see:
 
  if not (bs[0] in ['1','2','4','5','6','7']):
 ch.error(ctx, Invalid bugid: %s % bs)
 
 so either I don't have the latest or '8' needs to be added.  I'll try that.

You have an antique copy of jcheck.  Get a new one from here:

http://openjdk.java.net/projects/code-tools/jcheck/

(See step 1, Download the latest version )

- Mark

Re: [8] Review request for 8000693 Move jdk.tbom from jdk/make/closed to jdk repository

[mark . reinhold]

2012/10/10 16:21 -0700, michael.f...@oracle.com:
 This was originally submitted as 7196354 check-in jdk.tbom file to openjdk
 repo, but the file was checked in to the closedjdk repository.
 
 The automated translation drop system handles penjdk and closedjdk resource
 files separately as 2 different components. Having jdk.tbom file in closedjdk
 repository caused the system to not generate the translation drop for openjdk
 files. Therefore, I need to move the file to jdk repository under jdk/make.

Putting this file into an OpenJDK source tree is no more acceptable now
than it was when you first proposed it.  I think you need to get somebody
to fix Oracle's internal translation system instead.

- Mark

Re: [8] Review request for 7196354 check-in jdk.tbom file to openjdk repo

[mark . reinhold]

2012/9/10 14:26 -0700, michael.f...@oracle.com:
 I have updated the webrev:
 http://cr.openjdk.java.net/~mfang/7196354/webrev.01/
 
 ...
 
 I am also moving the file from root of source tree to
 jdk/make/jdk.tbom. SGT strongly recommends we follow the standard file
 naming convention used by the translation system, which is
 component-name.tbom. This is followed by all Oracle products requiring
 translation.
 
 We currently have no plan to publish the syntax and semantics to the openjdk
 community through JEP process. We would like to keep the syntax internal. When
 I review dev team's changes related to resource files, I will keep an eye on
 the files to be translated and translation language scope.

Thanks for the update.

A file whose syntax and semantics are not publicly documented, whose
content can only be validated by an employee of one company, and whose
very name is dictated by that company has no place in an OpenJDK code
repository.

Please work with other Oracle engineers to find a place for this file
in one of Oracle's related internal repositories.

- Mark

Re: [8] Review request for 7196354 check-in jdk.tbom file to openjdk repo

[mark . reinhold]

2012/9/5 14:08 -0700, michael.f...@oracle.com:
 Please help to review the new JDK8 file for the following CR:
 7196354 check-in jdk.tbom file to openjdk repo
 
 The webrev is located at:
 http://cr.openjdk.java.net/~mfang/7196354/webrev.00/

This file needs a more descriptive name, especially if it's going to be
in the root of the source tree.  Suggestion: translated-files.xml .

Is there a DTD or a schema for this file?  I can guess what most of it
means, but I might guess incorrectly.

[line 8] OpenJDK isn't a component, it's a community.  I think you mean
JDK here.

The JDK / JRE division in this file is somewhat artificial and likely
to become incorrect over time -- not every developer knows exactly which
files are in the JRE vs. the full JDK.  I suggest doing away with that
division and simply sorting the file-set elements by source file name.

At a glance it looks like the source and target attributes for any given
file are identical.  Do you expect there to be cases where they're
different?

 ...
 
 Mark:
 Since the dev team will need to maintain this file in the future (modifying it
 if you add or delete resource files), I temporarily put down your name as
 contact for the file. Please figure out the proper owner and we can update it
 again.

We don't put contact names in source code.  Please remove my name, and do
not add another.

 ...
 
 In the future, if any bug/rfe requires adding/deleting resource files, the dev
 work should include updating this file to reflect the correct resource file
 list. (and please ask me to review it).

If you expect other people to update this file over time then you need
to document that expectation somewhere and, as importantly, you need to
document the syntax and semantics of the file.  Fortunately we have a
way to do that, namely the JEP process (http://openjdk.java.net/jeps/).
I suggest you draft a JEP for this and circulate it for review along
with the webrev.

- Mark

Re: Any plan to cleanup x86 arch names?

[mark . reinhold]

2012/8/15 4:52 -0700, magnus.ihse.bur...@oracle.com:
 Unfortunately, it is not that simple to just replace everything with x86.

Sad, but true.

 ...
 
 2) Changing names on files or directories (unfortunately) makes version 
 control
 harder. If files are to be moved around all over the place anyway with Jigsaw,
 we might as well fix some names. It is not clear if it's worth the effort to
 rename files before such a major restructuring.

Agreed.  Not only will Jigsaw restructure the source tree, but it will
change the layout of $JRE/lib and make other changes that will, no doubt,
affect some existing code.  If we're going to fix all our old arch names,
that would be the right time to do it.

- Mark

hg: jdk8/build/jdk: 7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems

[mark . reinhold]

Changeset: d3b334e376d3
Author:mr
Date:  2012-01-23 12:39 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/jdk/rev/d3b334e376d3

7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems
Reviewed-by: ohair

! make/javax/sound/jsoundalsa/Makefile

Re: Build openjdk in Ubuntu 11.10

[mark . reinhold]

2012/1/13 9:33 -0800, michael.j.silvers...@gmail.com:
 I am getting the following error when building openjdk 7.0 on ubuntu 11.10
 But I already have the package libasound2-dev installed.

This is 7110396.  You need this patch:

diff --git a/make/javax/sound/jsoundalsa/Makefile 
b/make/javax/sound/jsoundalsa/Makefile
--- a/make/javax/sound/jsoundalsa/Makefile
+++ b/make/javax/sound/jsoundalsa/Makefile
@@ -65,7 +65,7 @@
$(MIDIFILES_export) \
$(PORTFILES_export)
 
-LDFLAGS += -lasound
+OTHER_LDLIBS += -lasound
 
 CPPFLAGS += \
-DUSE_DAUDIO=TRUE \

This is a tiny revision of the patch I originally proposed [1].
If someone could review this then I'll merge and push it.

- Mark


[1] http://mail.openjdk.java.net/pipermail/build-dev/2011-November/005188.html

Re: Review request (XS): 7110396: Sound code fails to build on multiarch Linux systems

[mark . reinhold]

2011/11/10 4:49 -0800, robert.otten...@oracle.com:
 The patch is correct, but in order to follow the convention in most other
 makefiles, I advice to use OTHER_LDLIBS instead of EXTRA_LIBS.

Ah, thanks.  I missed that one when reading through the common makefiles.

2011/11/10 5:16 -0800, robert.otten...@oracle.com:
 I am also not entirely convinced that the new multiarch support is the reason
 for these failures, although it may trigger it.

Right.  It may be that newer versions of gcc would show this problem even
on a non-multiarch system, but it's not really worth investigating any
further.  I'll clarify the description in the bug report.

 The specification for GNU ld 
 is
 that dependencies on the link line should always be written left to right,
 i.e. object files before library files. See also
 http://stackoverflow.com/questions/45135/linker-order-gcc/409402#409402. With
 that it mind, I would not be surprised if we get similar failures in the 
 future
 and that is why I suggest that every linker line without circular dependencies
 should be ordered left to right.

That's what I've always done too, but then I didn't write the makefile in
question here.

  However, this will probably be satisfied in
 the near future as part of the new build-infra project that is converting each
 and every native library Makefile.

Looking forward to that ...

- Mark

Re: Review request (XS): 7110396: Sound code fails to build on multiarch Linux systems

[mark . reinhold]

2011/11/10 17:45 -0800, david.hol...@oracle.com:
 On 11/11/2011 1:47 AM, mark.reinh...@oracle.com wrote:
 2011/11/10 4:49 -0800, robert.otten...@oracle.com:
 The patch is correct, but in order to follow the convention in most other
 makefiles, I advice to use OTHER_LDLIBS instead of EXTRA_LIBS.
 
 The common/Defs-*.gmk files say explicitly to use EXTRA_LIBS in place of 
 LDLIBS
 or LDLIBS_COMMON (and seem ignorant of OTHER_LDLIBS).
 
 But if the intent was to ensure this link directive was at the end then I 
 don't
 think OTHER_LDLIBS will work as it is the first set of entries in LDLIBS, 
 while
 the last set is LDLIBS_COMMON to which EXTRA_LIBS is appended.

The intent is only to ensure that this link directive follows all object
files; it's fine for it to precede the other libraries being linked.

From a build log, OTHER_LDLIBS is doing exactly what's needed:

  /usr/bin/gcc -O2 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused \
  -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN -DNDEBUG \
  -DARCH='i586' -Di586 -DLINUX -DRELEASE='1.8.0-mr_2011.11.10.1106' \
  -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT \
  -I. -I/w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/CClassHeaders \
  -I../../../../src/solaris/javavm/export \
  -I../../../../src/share/javavm/export \
  -I../../../../src/share/native/common \
  -I../../../../src/solaris/native/common \
  -I../../../../src/share/native/javax/sound \
  -I../../../../src/solaris/native/javax/sound -DX_PLATFORM=X_LINUX \
  -DX_ARCH=X_I586 -DUSE_DAUDIO=TRUE -DUSE_PORTS=TRUE \
  -DUSE_PLATFORM_MIDI_OUT=TRUE -DUSE_PLATFORM_MIDI_IN=TRUE \
  -I../../../../src/share/native/com/sun/media/sound -Xlinker -O1 -Xlinker \
  -version-script=mapfile-vers -Wl,--hash-style=both -Xlinker -z -Xlinker \
  origin -Xlinker -rpath -Xlinker \$ORIGIN -Xlinker -z -Xlinker defs \
  -L/w/jdk8/build/lib/i386 -Wl,-soname=libjsoundalsa.so -shared \
  -mimpure-text -o /w/jdk8/build/lib/i386/libjsoundalsa.so \
  /w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/Utilities.o \
  /w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/DirectAudioDeviceProvider.o \
  /w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/DirectAudioDevice.o \
  /w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/MidiInDevice.o \
  /w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/MidiInDeviceProvider.o \
  /w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/MidiOutDevice.o \
  /w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/MidiOutDeviceProvider.o \
  /w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/PlatformMidi.o \
  /w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/PortMixerProvider.o \
  /w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/PortMixer.o \
  
/w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/PLATFORM_API_LinuxOS_ALSA_CommonUtils.o
 \
  
/w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/PLATFORM_API_LinuxOS_ALSA_PCM.o
 \
  
/w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/PLATFORM_API_LinuxOS_ALSA_PCMUtils.o
 \
  
/w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/PLATFORM_API_LinuxOS_ALSA_MidiIn.o
 \
  
/w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/PLATFORM_API_LinuxOS_ALSA_MidiOut.o
 \
  
/w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/PLATFORM_API_LinuxOS_ALSA_MidiUtils.o
 \
  
/w/jdk8/build/tmp/sun/javax.sound/jsoundalsa/obj/PLATFORM_API_LinuxOS_ALSA_Ports.o
 \
  -lasound -ljava -L/w/jdk8/build/lib/i386/server -ljvm -lc
  

(Without this fix, -lasound was appearing right before -shared.)

- Mark

Review request (XS): 7110396: Sound code fails to build on multiarch Linux systems

[mark . reinhold]

Some Linux distros have started to adopt a multiarch filesystem layout for
shared libraries in order to support the installation of packages for multiple
hardware architectures on a single system.  For more information see, e.g.,
http://wiki.debian.org/Multiarch.

In Ubuntu 11.10 the ALSA shared library, libasound2, was converted to the
multiarch format and so its files moved from their old location, /usr/lib,
to /usr/lib/${ARCH_TRIPLET}.  This caused the JDK build to fail when linking
the Java sound library.  The root cause appears to be that gcc only tries to
resolve undefined symbols against a multiarch library if the library is named
on the command line after the object files containing those symbols.

The fix is simply to move -lasound to the end of the gcc invocation.

I'll push this into JDK 8.  It would trivially backport to 7.

Patch:

--- a/make/javax/sound/jsoundalsa/Makefile
+++ b/make/javax/sound/jsoundalsa/Makefile
@@ -65,7 +65,7 @@
$(MIDIFILES_export) \
$(PORTFILES_export)
 
-LDFLAGS += -lasound
+EXTRA_LIBS += -lasound
 
 CPPFLAGS += \
-DUSE_DAUDIO=TRUE \

Thanks,
- Mark

Re: Should the Build Group sponsor the JDK 7 Update project?

[mark . reinhold]

Vote: yes

- Mark

Re: Build Group Membership vote

[mark . reinhold]

2011/5/11 10:20 -0700, kelly.oh...@oracle.com:
 Should the following person be added as a member of the OpenJDK Build Group?
 David Katleman http://db.openjdk.java.net/people/katleman

Vote: yes

- Mark

Re: Build Group Membership vote

[mark . reinhold]

2011/5/11 10:55 -0700, kelly.oh...@oracle.com:
 Should the following person be added as a member of the OpenJDK Build Group?
 Phil Race http://db.openjdk.java.net/people/prr

Vote: yes

- Mark

Re: Should the Build Group sponsor the Build Infrastructure Project?

[mark . reinhold]

2011/5/11 8:23 -0700, kelly.oh...@oracle.com:
 Should the Build Group sponsor the Build Infrastructure Project [1]?

Vote: yes

- Mark

Re: demo vs. sample directories in the jdk

[mark . reinhold]

2011/3/16 7:55 -0700, alan.bate...@oracle.com:
 ... Today we have a sample and a demo directory 
 and
 it's not always clear where to put new sample code. I'm trying to remember why
 we have two locations. I think, but might be wrong, that the demo directory is
 sample code that is compiled by the build so that both the source and
 ready-to-run binaries are in the JDK image. The sample directory on the 
 other
 hand is sample code that is not compiled by the build but instead is just
 copied into the JDK image along with a build.xml or projects files. Is that
 right?

Yep.

- Mark

Re: Need reviewer

[Mark Reinhold]

Okay, I can live with this.

(At the risk of stating the obvious: Please be sure to use hg mv when
 you rename these files, otherwise the historical changeset trail will
 be broken.)

- Mark

Re: Need reviewer

[Mark Reinhold]

 Date: Sun, 11 Oct 2009 17:35:31 -0700
 From: kelly.oh...@sun.com

 6888701: Change all template java source files to a .java.template file suffix
 
 http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/

Most of the files you are renaming in this change are in NIO, and the
names of those files were carefully chosen so as to be invalid Java
class names -- they all contain at least one dash character.

This approach has the advantage that when you visit the files in an
editor or IDE they're treated as Java source files without any further
effort.  This is a feature, not a bug as claimed in 6888701.

I'd like to understand more about the complications in Makefile logic
claimed in 6888701.  If this is such a problem then why are we just
now getting around to fixing it?

- Mark

Re: Should GNU make 3.81 be required?

[Mark Reinhold]

 Date: Tue, 15 Sep 2009 10:44:08 -0700
 From: joe.da...@sun.com

 For as long as I remember, we've used make 3.78.*.  I assume the most
 problematic platform to upgrade is windows.  However, if there are significant
 benefits build time benefits, I think upgrading the make version is justified.

I completely agree.

It's not like 3.81 is new or anything.  It was released in 2006.

- Mark

Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

[Mark Reinhold]

 Date: Thu, 21 May 2009 16:51:24 +0100
 From: Andrew John Hughes gnu_and...@member.fsf.org

 ...
 
 Looks like the Contributed-by info is wrong.  I tried adding the line
 as in the example and jcheck choked:
 
 remote:  Contributed-by: Andrew John Hughes ahughes at redhat.com
 remote:
 remote: Invalid contributor attribution
 remote:
 remote: abort: pretxnchangegroup.0.jcheck hook failed
 
 The example is Contributed-by: Ben Bitdiddle ben at bits.org

Right -- as Jon already pointed out, this is a bug in the example.

More the the point, however, you didn't need a Contributed-by line in
your comment since you are the author.  That line is meant to be used
only when the author of the changeset (in hg terms) is not the sole
author of the actual patch.

- Mark

Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

[Mark Reinhold]

 Date: Mon, 18 May 2009 19:17:21 +0100
 From: Andrew John Hughes gnu_and...@member.fsf.org

 Ok, new webrev created against jdk7/build:
 
 http://fuseyism.com/6841728/webrev.01/

Looks good to me -- go ahead and push when ready.

 I presume I need to wait a bit due to the current block on pushes though.

No, the group integration areas are already open for M4.

 Is the standard format for such messages documented somewhere?
 
 http://openjdk.java.net/guide/producingChangeset.html#changesetComment
 
 Thanks.  I'd forgotten about the developer guide.  It was been
 discussed for a while, but then things seemed to go quiet.  Is it now
 complete?

No, unfortunately no one's had time to work on it, except for minor
changes, since the first version.  What's there is still relatively
accurate.

- Mark

Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

[Mark Reinhold]

 Date: Fri, 15 May 2009 16:30:04 +0100
 From: Andrew John Hughes gnu_and...@member.fsf.org

 I was thinking this as I read your mail.  It should be easy enough to
 add this as an #else clause to the existing patch in Sanity.gmk.
 What's the best way to handle updating the patch, given that the
 existing patch is a committed changeset?  Do I need to somehow revert
 the changeset or is a pair of changesets feasible?

One changeset is best.  You need somehow to revert the changeset
anyway since it'd need a proper comment, with a Sun bug id, before
being pushed upstream.  (I just created one for you: 6841728.)

(I can't resist pointing out that if you were using Mercurial patch
 queues you could just pop to that patch, edit, re-test, finalize,
 and then push the resulting changeset upstream.)

- Mark

Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

[Mark Reinhold]

 Date: Fri, 15 May 2009 09:08:39 -0700
 From: jonathan.gibb...@sun.com

 What is your experience with the combination of mq and jcheck?

None, so far, since jcheck is disabled in the Jigsaw forest.

 I like having jcheck enabled as a preextension hook, but that
 didn't work well with mq.

Hmm, that bug might get fixed now that the jcheck maintainer
is heavily using mq.

- Mark

Re: Swing Dev Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

[Mark Reinhold]

 Date: Fri, 15 May 2009 20:19:47 +0400
 From: peter.zheleznia...@sun.com

 Mark Reinhold wrote:
 Date: Fri, 15 May 2009 07:16:01 -0700
 From: jonathan.gibb...@sun.com
 
 Yeah, tried that, didn't work for me; I had to do real work so I gave
 up and downloaded and went back to using 0.9.5. :-(
 
 Odd.  I've been hacking on Jigsaw using hg 1.1.2 on my Ubuntu 9.04 box,
 with the newest version of the forest extension, and it works fine.
 
 9.04 worked for me out-of-the-box, too (almost - i just had to install
 mercurial and extensions). But didn't upgrade, i installed Ubuntu from
 scratch. May be that was the difference.

Seems unlikely.  I upgraded from 8.10 to 9.04.  The hg in 8.10 (forget
which version it was) worked fine with the new forest extension too.

- Mark

Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

[Mark Reinhold]

 Date: Fri, 15 May 2009 18:32:14 +0100
 From: Andrew John Hughes gnu_and...@member.fsf.org

 2009/5/15 Mark Reinhold m...@sun.com:
 One changeset is best.  You need somehow to revert the changeset
 
 Somehow I thought that's what you were going to say.. :)
 Looks like I can do a hg backout to revert the last changeset, and
 then create a new one.  What's the preferred repo to work against?
 jdk7/jdk7?

The preferred repo is the one into which your change will be pushed.
In this case I'd suggest jdk7/build so that Xiomara's build testing,
which runs in the context of the release-engineering system that does
our product builds, has a chance to catch any problems (which seems
extremely unlikely in this case).

 I commit the changes because OpenJDK's documentation seems to suggest
 that this is prefered (patch submission says hg export -g is
 preferable, webrev does an (f)outgoing search first).

Ah, I was assuming you were going to push the change in yourself.  If
you'd rather just submit a patch that's fine too; whichever you prefer.

Do Sun
 engineers usually just have their
 patches as uncommitted changes?

No.  My impression (which may be incorrect) is that many Sun engineers
still aren't all that comfortable slinging patches, so instead they tend
to work on several different repos/forests, one per change in progress,
which was a common practice with the old internal TeamWare SCM.

 anyway since it'd need a proper comment, with a Sun bug id, before
 being pushed upstream.  (I just created one for you: 6841728.)
 
 It had a bug ID, just a Bugzilla one...

At the moment we're assigning inbound patches a Sun bug id for tracking
purposes, and still using Sun bug ids uniformly in changeset comments.
That will change, in time, as part of the Bugzilla migration project.

 Is the standard format for such messages documented somewhere?

http://openjdk.java.net/guide/producingChangeset.html#changesetComment

 (I can't resist pointing out that if you were using Mercurial patch
  queues you could just pop to that patch, edit, re-test, finalize,
  and then push the resulting changeset upstream.)
 
 Yeah, but can webrev use patch queues yet? ;)

There are no mq-specific features in webrev, but since an mq-managed
patch shows up as a regular changeset there's no reason you couldn't
create a webrev comparing that changeset to some other one using the
exicting capabilities of the webrev script.

- Mark

Re: make sanity RFE

[Mark Reinhold]

 Date: Thu, 28 Aug 2008 00:19:24 +0200
 From: [EMAIL PROTECTED]

 sudo apt-get build-dep openjdk-6
 
 should get you the necessary build dependencies installed.

Wow.  That is just too slick for words.

- Mark

Re: hg: jdk7/build/jdk: 2 new changesets

[Mark Reinhold]

 Date: Tue, 10 Jun 2008 18:09:10 -0700
 From: Martin Buchholz [EMAIL PROTECTED]

 I did my last hg push from a Google machine.
 I have no idea why mercurial notification thinks I am [EMAIL PROTECTED]

Because that's the address you entered when you originally registered.

 I'd like to have control over my identity, and these days
 I'd like to be known as Martin Buchholz [EMAIL PROTECTED].

In the long run we'll have a web interface which will allow you to update
such information.

For now I've updated the database manually.

- Mark

Re: Mercurial repositories offline?

[Mark Reinhold]

 Date: Tue, 22 Apr 2008 13:22:58 +0200
 From: Clemens Eisserer [EMAIL PROTECTED]

 It looks like the mercurial-servers are down, I only get 500 -
 Internal Server Error.
 Is this already known and when can I expect it to be fixed?

Exactly what are you trying to do, and with what URL?

Everything looks to be working fine from here.

- Mark

Re: Extending the pattern list in .hgignore to exclude webrev directories

[Mark Reinhold]

 Date: Fri, 01 Feb 2008 14:21:07 +0100
 From: [EMAIL PROTECTED]

 I'd like to suggest to extend .hgignore with these two lines:
 
 ^webrev/
 ^webrev_.*/
 
 It would make it possible to keep several webrevs in your working
 repository without polluting the output of 'hg status'
 
 Well, of course there's always the possibility to do
 'hg status | grep -v webrev'
 if others in this group feel that it is not good idea ;-/

A better way to do this is to add the following to your ~/.hgrc:

[ui]
ignore = ~/.hgignore

Then you can add whatever patterns you want to ~/.hgignore in
order to suit your personal working style.

- Mark

Re: Quick confirmation

[Mark Reinhold]

 Date: Fri, 25 Jan 2008 03:02:04 -0800
 From: [EMAIL PROTECTED]

 On Jan 25, 2008, at 2:20 AM, Volker Simonis wrote:
 I've also noticed that there are no updates in the Mercurial
 repositories since the inital b24 upload. Is this because of the
 distributed nature of mercurial and the fact that every team inside
 SUN keeps their own, private repositories?
 
 Yes and no.  There have been no integrations yet because the
 integration repos. and associated machinery are still being
 carefully tested.  Some of this stuff, like commit message format
 and the mechanical checking of project design rules,
 has to be right the first time.  At least, that's my understanding
 of the situation; I'm doing JVM work, not (currently incredibly
 important) software process work.
 
 ...
 
 Meanwhile (to continue the home building metaphor)
 we're camping out on the subfloor and eating out a lot.

Thanks John, I couldn't have said it better myself.  (I especially like
your metaphor.)

In retrospect it was, perhaps, premature to do the cutover in December,
without every last bit of the infrastructure up and running, but we are
where we are.

Those remaining bits should be done in the next week or two, at which
point the changesets can start flowing.

- Mark

Re: JDK 7 Project

[Mark Reinhold]

Vote: yes

(duh)

- Mark

Tags for promoted builds

[Mark Reinhold]

 Date: Sat, 10 Nov 2007 04:27:39 +
 From: [EMAIL PROTECTED]

 Changeset: 2e4d6d562de7
 Author:xdono
 Date:  2007-11-09 20:03 -0800
 URL:   http://hg.openjdk.java.net/jdk7/tl/rev/2e4d6d562de7
 
 Added tag jdk7-ea-b99 for changeset 8792e7dbf130

The problem with this tag format, which is based on our ancient
bundle-naming scheme, is that the middle token changes over time,
from ea to beta to (maybe) beta2 to rc to fcs.  This
makes it unnecessarily difficult to look up a changeset for a
specific build -- you also need to know in which phase of the
release cycle it was promoted.

I think it'd make more sense to use simple jdk7-bNN tags, and
then also tag specific milestones as jdk7-beta, jdk7-rc1,
jdk7-fcs, etc.

- Mark

Re: Sparse repositories and fclone/fpull

[Mark Reinhold]

 Date: Mon, 12 Nov 2007 14:58:16 -0800
 From: [EMAIL PROTECTED]

 ...
 
 Yep, the subrepository I deleted was recreated...sigh...looks like I
 have to keep everything around, or else clone each subrepository separately.
 
 So, is there an option to only update the subrepositories that are present?

Not so far as I know, but it wouldn't be hard to hack one into forest.py.

- Mark

Sandboxes available

[Mark Reinhold]

I've created a couple of sandbox trees on hg.openjdk.java.net.

sandbox/simple is a simple push/pull tree that works in the
obvious way.

sandbox/box is a gated tree; you pull from sandbox/box, and then push
(via ssh) to sandbox/box-gate.  If your new changesets pass the gate
checks then they'll automagically be pushed to the sandbox/box tree.
If they don't pass then your push transaction will be aborted.

(At the moment there are no gate checks; that will change soon.)

Notifications for these trees go to [EMAIL PROTECTED]
Feel free to subscribe.

If you'd like to play around with these -- even if you don't work at
Sun -- send an ssh public key to [EMAIL PROTECTED]

Have fun, and don't push anything huge or important or confidential
to these trees.  They will be reinitialized at random times.

- Mark

Re: Group forests created

[Mark Reinhold]

 Date: Wed, 07 Nov 2007 21:05:43 +0200
 From: Frederic Simon [EMAIL PROTECTED]

 Without hacking hgwebdir.cgi, you can eneter multiple ScriptAlias in apache
 conf that will point to different hgweb.config files (and each has a
 different set of repo path).

That'd work -- if we were running this on Apache.

Hacking hgwebdir.cgi isn't so hard really, it's just Python.

- Mark

Group forests created

[Mark Reinhold]

I've created and loaded a set of experimental group integration forests
on hg.openjdk.java.net.  These are the forests to which individual
developers will push their changes.  Group integrators are responsible
for periodically syncing with the master forest and pushing changes up
to the master after suitable testing.

At the moment the content of these forests is identical to jdk7/MASTER,
but that will change as we do some dry-run integrations over the next
week or so.

Notifications for all of these forests go to this list for now (I can
easily change that if people have objections).  We'll redirect them to
the appropriate Group lists once we complete the Mercurial cutover.

One thing that's abundantly clear is that I need to hack on hgwebdir.cgi
some more so that it understands Projects and forests.  The index page
on http://hg.openjdk.java.net takes too long to load and is too hard to
navigate.

- Mark