Re: RFR JDK-8197533 move javax.transaction.xa into its own module

> On Feb 28, 2018, at 1:22 PM, Lance Andersen wrote: > >> >> On Feb 28, 2018, at 2:20 PM, Lance Andersen > > wrote: >> >> Hi Paul, >> >> Thank you for the review. >>> On Feb 28, 2018, at 1:40 PM, Paul Sandoz >> > wrote: >>> >>

RFR: JDK-8198862 Stop doing funky compilation stuff for dtrace

We're doing a lot of weird compilation stuff for dtrace. With this patch, most of the weirdness is removed. The remaining calls to $(CC) -E has been changed to $(CPP) to clarify that we do not compile, we just use the precompiler. One of the changes I made was to actually split up the last and

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

Hi Lance, I'd prefer if src/java.sql/share/classes/javax/transaction/xa/package.html was replaced by a package-info.java files as opposed to another package.html file in the new module. Thanks, -Joe On 2/28/2018 1:22 PM, Lance Andersen wrote: On Feb 28, 2018, at 2:20 PM, Lance Andersen

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

On 2018-02-28 19:25, Lance Andersen wrote: Hi all, This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

> On Feb 28, 2018, at 2:20 PM, Lance Andersen wrote: > > Hi Paul, > > Thank you for the review. >> On Feb 28, 2018, at 1:40 PM, Paul Sandoz > > wrote: >> >> Compatible module refactoring in action! >> >> Looks good, one comment: >> >> test/jdk/javax/transaction

RFR: JDK-8198844 Clean up GensrcX11Wrappers

My hunt on technical debt continues. This time my aim has been on the sorry mess known as GensrcX11Wrappers. I've disentangled it into two functions, one simple gensrc part that is actually run during the build, and which involves just a simple java tool and some pre-calculated data files, and

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

> On Feb 28, 2018, at 2:43 PM, Alan Bateman wrote: > > On 28/02/2018 18:25, Lance Andersen wrote: >> Hi all, >> >> This RFR request moves the javax.transaction.xa package out of the java.sql >> module and into its own module java.transaction.xa. One of the motivators >> for this change is du

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

On 28/02/2018 18:25, Lance Andersen wrote: Hi all, This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa p

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

Hi Paul, Thank you for the review. > On Feb 28, 2018, at 1:40 PM, Paul Sandoz wrote: > > Compatible module refactoring in action! > > Looks good, one comment: > > test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java > > This is not a valid Java source file can you merge the jtreg met

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

Compatible module refactoring in action! Looks good, one comment: test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java This is not a valid Java source file can you merge the jtreg meta data into XAExceptionTests instead? Paul. > On Feb 28, 2018, at 10:25 AM, Lance Andersen > wrote:

RFR JDK-8197533 move javax.transaction.xa into its own module

Hi all, This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa package will be subsumed by Java SE. There sh

Re: RFR: JDK-8198751 Refactor SetupNativeCompilation to take NAME and TYPE

Magnus: Currently, SetupNativeCompilation takes as "main" argument either LIBRARY := $name, PROGRAM := $name or STATIC_LIBRARY := $name. This confounds two distinct concepts: the name of the generated binary, and the type of binary to create. Instead, we should have a NAME argument and a TYPE a