On 2020-05-04 23:38, Erik Joelsson wrote:
On 2020-05-04 02:51, Magnus Ihse Bursie wrote:
On 2020-05-01 19:33, Erik Joelsson wrote:
After the sjavac cleanup in JDK-8244036 (and the subsequent fix of
the javac server usage in JDK-8244210), two more build failures have
been noted. The bootcycle
On 2020-05-04 02:51, Magnus Ihse Bursie wrote:
On 2020-05-01 19:33, Erik Joelsson wrote:
After the sjavac cleanup in JDK-8244036 (and the subsequent fix of
the javac server usage in JDK-8244210), two more build failures have
been noted. The bootcycle build fails and the test-make target
On 2020-05-01 19:33, Erik Joelsson wrote:
After the sjavac cleanup in JDK-8244036 (and the subsequent fix of the
javac server usage in JDK-8244210), two more build failures have been
noted. The bootcycle build fails and the test-make target fails the
tests of SetupJavaCompilation.
The
Erik:
Looks good.
Tim
After the sjavac cleanup in JDK-8244036 (and the subsequent fix of the
javac server usage in JDK-8244210), two more build failures have been
noted. The bootcycle build fails and the test-make target fails the
tests of SetupJavaCompilation.
The bootcycle build fails
After the sjavac cleanup in JDK-8244036 (and the subsequent fix of the
javac server usage in JDK-8244210), two more build failures have been
noted. The bootcycle build fails and the test-make target fails the
tests of SetupJavaCompilation.
The bootcycle build fails because a space has crept
mpiler.interim -m
jdk.compiler.interim/com.sun.tools.sjavac.Main
--server:portfile=/mnt/scratch1/fw/jdk/make-support/javacservers/server.port,id=BUILD_TOOLS_JDK,sjavac=/usr/lib/jvm/java-14-openjdk-amd64/bin/java%20-Xms512M%20-Xmx2048M%20--limit-modules%20java.base%2Cjdk.zipfs%2Cjava.compiler.interim%2Cjdk.compiler
nterim
--module-path
/mnt/scratch1/fw/jdk/buildtools/interim_langtools_modules
--add-exports java.base/sun.reflect.annotation=jdk.compiler.interim
--add-exports java.base/jdk.internal.jmod=jdk.compiler.interim
--add-exports java.base/jdk.internal.misc=jdk.compiler.interim -m
jdk.compiler.interim/com.sun.tool
On 2020-04-30 15:50, Florian Weimer wrote:
* Magnus Ihse Bursie:
I made sure that no build performances were measured on my system, and
since I saw no such indication, I did not make any more systematic analysis.
What is the difference if you run with or without the javac server?
Thanks.
* Magnus Ihse Bursie:
> I made sure that no build performances were measured on my system, and
> since I saw no such indication, I did not make any more systematic analysis.
>
> What is the difference if you run with or without the javac server?
Thanks. Which configure flags do you want me to t
On 2020-04-30 15:07, Magnus Ihse Bursie wrote:
On 2020-04-30 14:55, Florian Weimer wrote:
* Magnus Ihse Bursie:
The code for setting up Java compilation has long been quite hard to
understand, and has a tricky API. Part of this is due to the support
for
the sjavac ("smart javac&quo
On 2020-04-30 14:55, Florian Weimer wrote:
* Magnus Ihse Bursie:
The code for setting up Java compilation has long been quite hard to
understand, and has a tricky API. Part of this is due to the support for
the sjavac ("smart javac") system. We do not use sjavac anymore, and it
ha
* Magnus Ihse Bursie:
> The code for setting up Java compilation has long been quite hard to
> understand, and has a tricky API. Part of this is due to the support for
> the sjavac ("smart javac") system. We do not use sjavac anymore, and it
> has not been tested for lo
e support
for the sjavac ("smart javac") system. We do not use sjavac anymore,
and it has not been tested for long. Part of the sjavac effort was
extracted into the "depend" javac plugin, and another part ended up
as the java server, both of which we still use.
This
, Magnus Ihse Bursie wrote:
The code for setting up Java compilation has long been quite hard to
understand, and has a tricky API. Part of this is due to the support
for the sjavac ("smart javac") system. We do not use sjavac anymore,
and it has not been tested for long. Part of the sjava
The code for setting up Java compilation has long been quite hard to
understand, and has a tricky API. Part of this is due to the support for
the sjavac ("smart javac") system. We do not use sjavac anymore, and it
has not been tested for long. Part of the sjavac effort was extracted
On Wed, Feb 24, 2016 at 12:00:36PM +1000, David Holmes wrote:
> I just had a failed JPRT build on Solaris sparc caused by:
>
> === Output from failing command(s) repeated here ===
> /usr/ccs/bin/printf "* For target
> support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_class
nce, it seems that if I build on Windows in
>> cygwin and I cancel the build for whatever reason with CTRL+C, the sjavac
>> server hangs and blocks the output directory. It takes some minutes for it
>> to timeout, or I go hunting for the process in Process Explorer.
>
> Intere
On 25/02/2016 4:14 AM, Andreas Lundblad wrote:
On Wed, Feb 24, 2016 at 12:00:36PM +1000, David Holmes wrote:
I just had a failed JPRT build on Solaris sparc caused by:
Sorry to hear this.
I've been ill today (not sure how I'll feel tomorrow) but I'll look into this
issue before doing anythin
l the build for whatever reason with CTRL+C, the sjavac
> > server hangs and blocks the output directory. It takes some minutes for
> it
> > to timeout, or I go hunting for the process in Process Explorer.
>
> Interesting. I don't know if there's an easy solution to thi
On Wed, Feb 24, 2016 at 09:33:55AM +0100, Thomas Stüfe wrote:
> Just to add another small annoyance, it seems that if I build on Windows in
> cygwin and I cancel the build for whatever reason with CTRL+C, the sjavac
> server hangs and blocks the output directory. It takes some minutes fo
On Wed, Feb 24, 2016 at 12:00:36PM +1000, David Holmes wrote:
> I just had a failed JPRT build on Solaris sparc caused by:
Sorry to hear this.
I've been ill today (not sure how I'll feel tomorrow) but I'll look into this
issue before doing anything else.
There's always the --disable-javac-serve
Just to add another small annoyance, it seems that if I build on Windows in
cygwin and I cancel the build for whatever reason with CTRL+C, the sjavac
server hangs and blocks the output directory. It takes some minutes for it
to timeout, or I go hunting for the process in Process Explorer.
I
I just had a failed JPRT build on Solaris sparc caused by:
=== Output from failing command(s) repeated here ===
/usr/ccs/bin/printf "* For target
support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch:\n"
* For target
support_test_hotspot_closed_tonga_dist_jav
the java modules with
> different settings.
>
> Attaching a chart of the result.
>
> Red bars:
> - Plain old javac. Sjavac disabled.
>
> Green bars:
> - Sjavac, without breaking up each module into multiple javac invocations.
> (This is the default setting.)
>
>
spent some time measuring the build times of the java modules with different
settings.
Attaching a chart of the result.
Red bars:
- Plain old javac. Sjavac disabled.
Green bars:
- Sjavac, without breaking up each module into multiple javac invocations.
(This is the default setting.)
Blue
Red bars:
> - Plain old javac. Sjavac disabled.
>
> Green bars:
> - Sjavac, without breaking up each module into multiple javac invocations.
> (This is the default setting.)
>
> Blue bars:
> - Sjavac where each module is split into three parallel javac invocations.
>
I spent some time measuring the build times of the java modules with different
settings.
Attaching a chart of the result.
Red bars:
- Plain old javac. Sjavac disabled.
Green bars:
- Sjavac, without breaking up each module into multiple javac invocations.
(This is the default setting.)
Blue
On Tue, Jan 19, 2016 at 02:29:33PM +0100, Magnus Ihse Bursie wrote:
> On 2016-01-19 11:31, Erik Joelsson wrote:
> >Hello,
> >
> >Please review this fix in the makefiles for using sjavac. The
> >include/exclude mechanism in sjavac has changed. We used to
> >som
On 2016-01-19 11:31, Erik Joelsson wrote:
Hello,
Please review this fix in the makefiles for using sjavac. The
include/exclude mechanism in sjavac has changed. We used to sometimes
exclude files using a full absolute path. This no longer works. The
same thing can be achieved by splitting up
Hello,
Please review this fix in the makefiles for using sjavac. The
include/exclude mechanism in sjavac has changed. We used to sometimes
exclude files using a full absolute path. This no longer works. The same
thing can be achieved by splitting up the source roots argument to
sjavac in
On 2015-11-27 14:28, Erik Joelsson wrote:
Hello,
The javac-server feature wasn't compatible with bootcycle-images. This
fix is a bit of hack, but so was the original bootcycle
implementation. We probably need to take a step back and figure out a
better model for this later.
I agree on that.
Hello,
The javac-server feature wasn't compatible with bootcycle-images. This
fix is a bit of hack, but so was the original bootcycle implementation.
We probably need to take a step back and figure out a better model for
this later.
Bug: https://bugs.openjdk.java.net/browse/JDK-8144172
Webre
On 2015-11-19 12:10, Erik Joelsson wrote:
On Windows, when trying to use the new javac-server mode (or sjavac),
each java compilation process that spawns a javac server ends up
waiting for that server to shut down before shutting down itself. This
behavior is caused by the new LogFailure
On Windows, when trying to use the new javac-server mode (or sjavac),
each java compilation process that spawns a javac server ends up waiting
for that server to shut down before shutting down itself. This behavior
is caused by the new LogFailure feature, where each javac invocation is
wrapped
Erik
On 2015-10-23 17:21, Magnus Ihse Bursie wrote:
On 2015-10-22 12:38, Erik Joelsson wrote:
In JDK-8135131, sjavac added a thin server mode, in which only the
server part of sjavac is used for running plain javac. This patch
adds a configure option to enable this mode of running to the jdk
bui
Bursie wrote:
On 2015-10-22 12:38, Erik Joelsson wrote:
In JDK-8135131, sjavac added a thin server mode, in which only the
server part of sjavac is used for running plain javac. This patch
adds a configure option to enable this mode of running to the jdk
build. Later, if it seems to work well, w
, Erik Joelsson wrote:
In JDK-8135131, sjavac added a thin server mode, in which only the
server part of sjavac is used for running plain javac. This patch
adds a configure option to enable this mode of running to the jdk
build. Later, if it seems to work well, we will consider making it
def
On 2015-10-22 12:38, Erik Joelsson wrote:
In JDK-8135131, sjavac added a thin server mode, in which only the
server part of sjavac is used for running plain javac. This patch adds
a configure option to enable this mode of running to the jdk build.
Later, if it seems to work well, we will
In JDK-8135131, sjavac added a thin server mode, in which only the
server part of sjavac is used for running plain javac. This patch adds a
configure option to enable this mode of running to the jdk build. Later,
if it seems to work well, we will consider making it default.
On my workstation
On 10/06/2015 10:21, Andreas Lundblad wrote:
On Wed, Jun 10, 2015 at 11:02:19AM +0200, Andreas Lundblad wrote:
What's the approperiate procedure here? Should I submit a patch that adds the
type arguments to avoid forcing people to update their boot jdks?
I have now pushed a patch that adds t
On Wed, Jun 10, 2015 at 11:02:19AM +0200, Andreas Lundblad wrote:
> What's the approperiate procedure here? Should I submit a patch that adds the
> type arguments to avoid forcing people to update their boot jdks?
I have now pushed a patch that adds the type arguments.
http://hg.openjdk.java.net
On Wed, Jun 10, 2015 at 09:06:44AM +0100, Alan Bateman wrote:
>
>
> On 10/06/2015 09:00, Erik Joelsson wrote:
> >Hello,
> >
> >Sjavac has always been compiled in the interim langtools step, the
> >configure flag only affects using it to compile the rest of the
On 10/06/2015 09:00, Erik Joelsson wrote:
Hello,
Sjavac has always been compiled in the interim langtools step, the
configure flag only affects using it to compile the rest of the java
classes.
Has a bug been created for this?
I haven't created a bug for this as I wasn't sure i
Hello,
Sjavac has always been compiled in the interim langtools step, the
configure flag only affects using it to compile the rest of the java
classes.
Has a bug been created for this?
/Erik
On 2015-06-10 09:53, Alan Bateman wrote:
There was a sjavac update pushed to jdk9/dev yesterday
There was a sjavac update pushed to jdk9/dev yesterday (JDK-8054717). I
seem to be running into build issues on OS X since then (clean build,
not a reconfigure). My boot JDK is 8u31. My configure command does not
specify --enable-sjavac so I'm surprised this code is being compiled.
A
e for java.awt.datatransfer.UnsupportedFlavorException not found
From what I can tell, jdk.jconsole uses java.desktop, which uses
java.datatransfer (and re-exports it), where the missing class is.
My best guess is that something in sjavac (API checking?) needs to
traverse down into the transitive dependencies. This mig
what I can tell, jdk.jconsole uses java.desktop, which uses
java.datatransfer (and re-exports it), where the missing class is. My
best guess is that something in sjavac (API checking?) needs to
traverse down into the transitive dependencies. This might be wrong,
but as a workaround, it's
sktop, which uses
java.datatransfer (and re-exports it), where the missing class is. My
best guess is that something in sjavac (API checking?) needs to
traverse down into the transitive dependencies. This might be wrong,
but as a workaround, it's easiest to fix in the makefiles so that we
ts it), where the missing class is. My
best guess is that something in sjavac (API checking?) needs to traverse
down into the transitive dependencies. This might be wrong, but as a
workaround, it's easiest to fix in the makefiles so that we can have a
working sjavac enabled jdk build.
Hello,
Here is my suggestion for makefile changes to go with the sjavac
changes. Adding build-dev to get review for my part.
Webrev: http://cr.openjdk.java.net/~erikj/8054717/webrev.root.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8054717
/Erik
On 2015-03-02 13:31, Andreas Lundblad
On 2015-01-15 10:21, Erik Joelsson wrote:
Hello,
Please review this small patch which fixes bootcycle-images builds
when enabling sjavac. The problem was that the directory where the
portfile should be created is never created in the bootcycle-build
output directory. I think the best and
Hello,
Please review this small patch which fixes bootcycle-images builds when
enabling sjavac. The problem was that the directory where the portfile
should be created is never created in the bootcycle-build output
directory. I think the best and simplest solution is to just always
create it
On 2014-09-19 10:45, Erik Joelsson wrote:
In JDK-8058118, a small java tool is compiled very early in the make
process. This compilation cannot use sjavac since it's done with the
boot javac. The fix is simple. Just add DISABLE_SJAVAC := true to the
macro call. I also added a co
On 2014-09-19 10:56, David Holmes wrote:
Hi Erik,
On 19/09/2014 6:45 PM, Erik Joelsson wrote:
In JDK-8058118, a small java tool is compiled very early in the make
process. This compilation cannot use sjavac since it's done with the
boot javac. The fix is simple. Just add DISABLE_S
Hi Erik,
On 19/09/2014 6:45 PM, Erik Joelsson wrote:
In JDK-8058118, a small java tool is compiled very early in the make
process. This compilation cannot use sjavac since it's done with the
boot javac. The fix is simple. Just add DISABLE_SJAVAC := true to the
macro call. I also added a co
In JDK-8058118, a small java tool is compiled very early in the make
process. This compilation cannot use sjavac since it's done with the
boot javac. The fix is simple. Just add DISABLE_SJAVAC := true to the
macro call. I also added a comment documenting this already existing
feature.
changed that into a simple MEMORY_SIZE/2 for sjavac server mx flag.
Then I did some tests on my machine and with the modules build, sjavac
really isn't that memory intensive anymore. I set a cap at 2GB (1,5
for 32 bit jvms) and also set a minimum of 512M, which I have verified
still works. I
e review this little workaround for a current shortcoming in Sjavac.
>> See bug for more details. With this change, Sjavac will start acting
>> correctly again and not miss any files that need to be recompiled. The
>> approximation is course however, we should still fix
>&
It seems like the development speed for sjavac needs to be increased
significantly, one JIRA bug, one 2 week review cycle, leads to one commit
is much too slow. I belive it would be good to have a separate repository
to do quicker development of sjavac, and test out all sorts of interesting
stuff
On 2014-08-26 11:58, Erik Joelsson wrote:
Updated webrev: http://cr.openjdk.java.net/~erikj/8055922/webrev.root.02/
Some of the demos failed to compile because the javac_state file did
not contain any public api and this caused grep to exit with code 1,
which failed the build. I made exit code
.
/Erik
On 2014-08-25 16:50, Erik Joelsson wrote:
Hello,
Please review this little workaround for a current shortcoming in
Sjavac. See bug for more details. With this change, Sjavac will start
acting correctly again and not miss any files that need to be
recompiled. The approximation is course
Hello,
Please review this little workaround for a current shortcoming in
Sjavac. See bug for more details. With this change, Sjavac will start
acting correctly again and not miss any files that need to be
recompiled. The approximation is course however, we should still fix
https
get rid of the big if-else construct, so I
> changed that into a simple MEMORY_SIZE/2 for sjavac server mx flag.
> Then I did some tests on my machine and with the modules build,
> sjavac really isn't that memory intensive anymore. I set a cap at
> 2GB (1,5 for 32 bit jvms) and
sjavac server mx flag. Then
I did some tests on my machine and with the modules build, sjavac really
isn't that memory intensive anymore. I set a cap at 2GB (1,5 for 32 bit
jvms) and also set a minimum of 512M, which I have verified still works.
I also removed the verbosegc flag.
When cha
Hi build-dev,
Please review the fix for JDK-8014510: Fix sjavac on all platforms in jprt
Description:
JPRT jobs fail (on Sparc) with sjavac enabled. This is because the JVM can't
allocate the requested amount of memory upon launch. This patch changes the the
-Xms setting (which ranges fr
The previous RFR tried to solve both this simple problem and the larger
rewrite of the options but seems to be stalled due to problems with the
Windows build. Since it is very inconvenient to have a broken sjavac in
jdk9/jdk9, perhaps someone within Oracle could take this simple patch
(almost
Hi,
On 2014-03-19, Andreas Lundblad wrote:
> Hi compiler-dev + build-dev,
>
> Please review the fix for JDK-8035063 and JDK-8037085 which involves changes
> to sjavac (option handling) and dev/ + dev/jdk build files.
>
>
> Description:
>
> - Sjavac relied on passin
Ok, Eriks explanation makes sense. There might also be situations where you
want to exclude/include copying META-INF files and such, that reside in
non-package directories. So, changing from . to / is ok.
In particular since sjavac cleverly detects and reports an error, if a
source file is in the
sjavac ability to
compile using multiple threads. This is just as bad as when Nashorn tried
to insert $ into java source file names! The horror, the horror.
I.e. do not replace . with /. Fix the problem in the jdk.
//Fredrik
2014-03-19 12:29 GMT+01:00 Erik Joelsson :
> Ah, I see now, it
un/awt/X11/doc-files \
sun/util/cldr/resources \
#
When building with sjavac, these get translated to "-e
java.awt.doc-files.*" which sjavac does not accept, because doc-files
are not proper package names. Another possible fix would be to filter
out non valid package names fr
On 2014-03-19 09:49, Andreas Lundblad wrote:
Hi compiler-dev + build-dev,
Please review the fix for JDK-8035063 and JDK-8037085 which involves changes to
sjavac (option handling) and dev/ + dev/jdk build files.
The build part looks good to me.
/Magnus
or problem. You will not find that source
> through -sourcepath, which means that you just broke sjavac ability to
> compile using multiple threads. This is just as bad as when Nashorn tried
> to insert $ into java source file names! The horror, the horror.
>
> I.e. do not replace .
Ah, I see now, it was "-i some.package.*" in the original code. Build
part looks good to me now.
/Erik
On 2014-03-19 11:17, Andreas Lundblad wrote:
On Wed, Mar 19, 2014 at 10:03:33AM +0100, Erik Joelsson wrote:
Hello,
The input from our makefiles changes from "-i some.package" to "-i
some/pa
On Wed, Mar 19, 2014 at 10:03:33AM +0100, Erik Joelsson wrote:
> Hello,
>
> The input from our makefiles changes from "-i some.package" to "-i
> some/package/*". IIRC the include flag works recursively for sub
> packages. Will the single * do the same?
>
> /Erik
That's strange. What used to be "
view the fix for JDK-8035063 and JDK-8037085 which involves changes to
sjavac (option handling) and dev/ + dev/jdk build files.
Description:
- Sjavac relied on passing around the main arg array to whatever part of the
code that were potentially affected by command line options. The patch
rest
Hi compiler-dev + build-dev,
Please review the fix for JDK-8035063 and JDK-8037085 which involves changes to
sjavac (option handling) and dev/ + dev/jdk build files.
Description:
- Sjavac relied on passing around the main arg array to whatever part of the
code that were potentially affected
Changeset: e247ee3924d5
Author:erikj
Date: 2013-05-22 17:26 +0200
URL: http://hg.openjdk.java.net/jdk8/build/rev/e247ee3924d5
8014514: Fix jvm args for sjavac
Reviewed-by: tbell
! common/autoconf/basics.m4
! common/autoconf/build-performance.m4
! common/autoconf/generated
On 2013-05-15 09:01, Erik Joelsson wrote:
On 2013-05-15 06:21, David Holmes wrote:
On 15/05/2013 12:34 AM, Erik Joelsson wrote:
This patch tries to be smarter when figuring out optimal jvm args for
sjavac, especially if the jvm used is 32bit.
http://cr.openjdk.java.net/~erikj/8014514
On 2013-05-15 06:21, David Holmes wrote:
On 15/05/2013 12:34 AM, Erik Joelsson wrote:
This patch tries to be smarter when figuring out optimal jvm args for
sjavac, especially if the jvm used is 32bit.
http://cr.openjdk.java.net/~erikj/8014514/webrev.root.01/
For this to work properly, two
On 15/05/2013 12:34 AM, Erik Joelsson wrote:
This patch tries to be smarter when figuring out optimal jvm args for
sjavac, especially if the jvm used is 32bit.
http://cr.openjdk.java.net/~erikj/8014514/webrev.root.01/
For this to work properly, two patches to the sjavac src langtools are
also
Erik:
This patch tries to be smarter when figuring out optimal jvm args for
sjavac, especially if the jvm used is 32bit.
http://cr.openjdk.java.net/~erikj/8014514/webrev.root.01/
Looks good.
Tim
This patch tries to be smarter when figuring out optimal jvm args for
sjavac, especially if the jvm used is 32bit.
http://cr.openjdk.java.net/~erikj/8014514/webrev.root.01/
For this to work properly, two patches to the sjavac src langtools are
also needed, but they will be handled in separate
ks good to me, btw, although I'm not a build expert.
Also, could you clarify why do Windows builds fail with sjavac? Is
this a known bug in sjavac or the build system?
It looks to me like a bug in sjavac. I have seen it work previously.
It also failed on my Windows system. There is th
/8/2013 5:21 PM, Erik Joelsson wrote:
On 2013-04-08 15:17, Anthony Petrov wrote:
Thanks for clarifying that. Makes sense to me.
The fix looks good to me, btw, although I'm not a build expert.
Also, could you clarify why do Windows builds fail with sjavac? Is
this a known bug in sjavac o
clarifying that. Makes sense to me.
The fix looks good to me, btw, although I'm not a build expert.
Also, could you clarify why do Windows builds fail with sjavac? Is
this a known bug in sjavac or the build system?
It looks to me like a bug in sjavac. I have seen it work previously.
d you clarify why do Windows builds fail with sjavac? Is
this a known bug in sjavac or the build system?
It looks to me like a bug in sjavac. I have seen it work previously.
/Erik
--
best regards,
Anthony
On 04/08/13 17:03, Erik Joelsson wrote:
Sjavac also enables parallel execution of
Hi Erik:
This looks good - approved. Sorry for the delay.
Tim
Reminder that I would like this reviewed.
/Erik
On 2013-03-21 12:49, Erik Joelsson wrote:
This patch makes it possible to enable sjavac in jprt runs. This is
achieved by adding -buildenv ENABLE_SJAVAC=true to the jprt command
Looks ok with me. ;^)
-kto
On 4/8/13 2:44 AM, "Erik Joelsson" wrote:
>Reminder that I would like this reviewed.
>
>/Erik
>
>On 2013-03-21 12:49, Erik Joelsson wrote:
>> This patch makes it possible to enable sjavac in jprt runs. This is
>> achieved by a
On 4/8/2013 5:21 PM, Erik Joelsson wrote:
On 2013-04-08 15:17, Anthony Petrov wrote:
Thanks for clarifying that. Makes sense to me.
The fix looks good to me, btw, although I'm not a build expert.
Also, could you clarify why do Windows builds fail with sjavac? Is
this a known bug in s
On 2013-04-08 15:17, Anthony Petrov wrote:
Thanks for clarifying that. Makes sense to me.
The fix looks good to me, btw, although I'm not a build expert.
Also, could you clarify why do Windows builds fail with sjavac? Is
this a known bug in sjavac or the build system?
It looks to me
Thanks for clarifying that. Makes sense to me.
The fix looks good to me, btw, although I'm not a build expert.
Also, could you clarify why do Windows builds fail with sjavac? Is this
a known bug in sjavac or the build system?
--
best regards,
Anthony
On 04/08/13 17:03, Erik Joelsson
Sjavac also enables parallel execution of java compilation, speeding up
full builds as well. But even if it didn't, being able to verify that
sjavac builds work in jprt will be a must if we are to enable it by default.
/Erik
On 2013-04-08 14:56, Anthony Petrov wrote:
Just curious: sjav
Just curious: sjavac is supposed to address the issue with slow
incremental builds. JPRT builds are full builds usually. What is the
benefit of using sjavac for full builds?
--
best regards,
Anthony
On 04/08/13 13:44, Erik Joelsson wrote:
Reminder that I would like this reviewed.
/Erik
On
Reminder that I would like this reviewed.
/Erik
On 2013-03-21 12:49, Erik Joelsson wrote:
This patch makes it possible to enable sjavac in jprt runs. This is
achieved by adding -buildenv ENABLE_SJAVAC=true to the jprt command line.
http://cr.openjdk.java.net/~erikj/8010465/webrev.root.01
This patch makes it possible to enable sjavac in jprt runs. This is
achieved by adding -buildenv ENABLE_SJAVAC=true to the jprt command line.
http://cr.openjdk.java.net/~erikj/8010465/webrev.root.01/
Doing this uncovered another bug. Adding the keyword "nofile" to the LOG
variable
(As I've complained about recently)
Not all jdk commands (e.g. javap, and apparently sjavac) consistently
support either both or neither of '-cp' and '-classpath' as synonyms.
But that's being fixed.
On Fri, Mar 15, 2013 at 10:57 AM, Andrew Hughes wrote:
- Original Message -
> The Nashorn team is wondering about the status of sjavac and the
> builds. Note: https://jbs.oracle.com/bugs/browse/JDK-8009788 .
> There are two occurances of "-cp" which should be convered to
> "-classpath" in makefile
The Nashorn team is wondering about the status of sjavac and the builds. Note:
https://jbs.oracle.com/bugs/browse/JDK-8009788 . There are two occurances of
"-cp" which should be convered to "-classpath" in makefiles/BuildNashorn.gmk .
Cheers,
-- Jim
On 03/11/2013 12:39 PM, Martin Buchholz wrote:
While you're there, consider checking/modfying all of the jdk tools to
accept either both or neither of "-cp" and "-classpath". javap is the
command I'm thinking of.
Issue JDK-8009924.
-- Jon
Hi Jon:
On 03/11/2013 11:33 AM, Jim Laskey (Oracle) wrote:
The Nashorn team is wondering about the status of sjavac and the
builds. Note: https://jbs.oracle.com/bugs/browse/JDK-8009788 .
There are two occurances of "-cp" which should be convered to
"-classpat
1 - 100 of 123 matches
Mail list logo
