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
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
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
o 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 into the "depend" javac plugin, and another part ended up
as the java server, both of which we still use.
This patch
, 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
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
>
ust 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 P
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
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 this one. (I.
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 som
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
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
ava 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.)
>
>
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 bars
ars:
> - 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.
> (Note
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
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
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,
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
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.
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
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
build
e 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, we
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
default.
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
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 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
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.
Anyone
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
java classes.
Has a bug been created
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
, 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
can have
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 easiest
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 might
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.
Here
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
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
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.
Bug
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 comment
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_SJAVAC
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 comment
.
/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
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
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
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
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 also set a minimum of 512M, which I
have verified
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 from 1G
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 passing around the main arg array
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
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
-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
restructures the code so
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 -i
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
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 . with /. Fix the problem in the jdk
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
\
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 from the excludes sent to sjavac
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 erik.joels...@oracle.com
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 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 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
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
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
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 like a bug in sjavac. I have seen it work previously
/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
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 java
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
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: sjavac
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 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 or the build system?
It looks to me like
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 sjavac
Looks ok with me. ;^)
-kto
On 4/8/13 2:44 AM, Erik Joelsson erik.joels...@oracle.com 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 adding -buildenv
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
- 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 makefiles/BuildNashorn.gmk .
Cheers,
-- Jim
(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 gnu.and...@redhat.comwrote:
- Original
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 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 -classpath in makefiles/BuildNashorn.gmk .
Cheers
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.
Noted.
-- 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 -classpath in makefiles/BuildNashorn.gmk .
Cheers
Hi,
I was doing experiments with the recently added sjavac flag to enable
smart recompilation of JDK classes. I got a failure in Nashorn (I'm
building on linux x64, Ubuntu 11.10):
## Starting nashorn
Compiling BUILD_NASHORN
Compiling 106 files in 7 packages (jdk.internal.dynalink
On 2/11/2013 1:56 PM, Vita Santrucek wrote:
I see that sjavac was pushed in b75:
but in our logs we seem to disable it:
…
checking whether to use sjavac… no
...
[3] DISABLE_SJAVAC:=true
...
Why don't we use it when building JDK 8?
It's not that we disable it, autoconf does that for any
What David says is correct. We hope to enable it by default soon, but
feel that it could use some hardening first.
/Erik
On 2013-02-11 23:42, David Katleman wrote:
On 2/11/2013 1:56 PM, Vita Santrucek wrote:
I see that sjavac was pushed in b75:
but in our logs we seem to disable
On 01/18/2013 02:58 PM, Fredrik Öhrström wrote:
18 jan 2013 kl. 03:07 skrev Weijun Wang:
Just tried on a latest jdk8/tl clone and
The makefile listed source
/space/repos/jdk8/tl/build/linux-x86_64-sjavac/langtools/gensrc/com/sun/tools/doclint/resources/doclint.java
was not calculated
2013/1/18 Weijun Wang weijun.w...@oracle.com:
I just find something interesting. /space on my machine is a symlink to
/home/more/space. If I cd to
/home/more/space/repos/jdk8/tl/build/linux-x86_64-sjavac and configure/make
there, everything is fine.
Ah, then sjavac is probably doing canonical
Just tried on a latest jdk8/tl clone and
Building Java(TM) for target 'all' in configuration
'/space/repos/jdk8/tl/build/linux-x86_64-sjavac'
## Starting langtools
Compiling 2 files for BUILD_TOOLS
Compiling 26 properties into resource bundles
Compiling 720 files for BUILD_BOOTSTRAP_LANGTOOLS
Anyone else having trouble deciphering the error message:
The makefile listed source
/space/repos/jdk8/tl/build/linux-x86_64-sjavac/langtools/gensrc/com/sun/tools/doclint/resources/doclint.java
was not calculated by the smart javac wrapper!
-- Jon
On 01/17/2013 06:07 PM, Weijun Wang wrote
18 jan 2013 kl. 03:07 skrev Weijun Wang:
Just tried on a latest jdk8/tl clone and
The makefile listed source
/space/repos/jdk8/tl/build/linux-x86_64-sjavac/langtools/gensrc/com/sun/tools/doclint/resources/doclint.java
was not calculated by the smart javac
Ok, as the old saying goes
The fix for moving a few source files for the awt bean info classes has not
yet propagated into tl, from build. Until then, the tl with --enable-sjavac
build
will stop somewhere in the jdk when generating sources for awt bean infos.
//Fredrik
1 - 100 of 106 matches
Mail list logo
