Hi,
Here is a tiny change to increase the heap space for javadoc, during the
jdk build, this allows the build to complete and speeds up the build as
well.
fyi. The heap space was on the borderline of running out of heap and cause
an OOM, some recent changes have increased the memory requir
On 4/12/2012 2:03 PM, Daniel D. Daugherty wrote:
The wonderful T&L nightly testing caught an error in my changes
The change looks good to me.
Thanks
Kumar
that were reviewed on this thread. On Linux and Solaris, I installed
the .debuginfo files for programs in $JAVA_HOME/bin. I made a
mista
On windows, I see a failure when building hotspot, as as follows.
Kumar
link.exe /SAFESEH /manifest kernel32.lib user32.lib gdi32.lib
winspool.lib co
dlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib
Wsock32.lib
winmm.lib /nologo /machine:I386 /opt:REF /opt:ICF,8 /map /debu
On 7/9/2012 5:20 PM, David Holmes wrote:
On 10/07/2012 9:51 AM, Kumar Srinivasan wrote:
On windows, I see a failure when building hotspot, as as follows.
Kumar
link.exe /SAFESEH /manifest kernel32.lib user32.lib gdi32.lib
winspool.lib codlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32
nOn 7/9/2012 5:20 PM, David Holmes wrote:
On 10/07/2012 9:51 AM, Kumar Srinivasan wrote:
On windows, I see a failure when building hotspot, as as follows.
Kumar
link.exe /SAFESEH /manifest kernel32.lib user32.lib gdi32.lib
winspool.lib codlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32
It looks like autoconf has messed up.
From the config.log
HOSTCC='C:/PROGRA~1/MSVS10/VC/BIN/cl.exe'
HOSTCXX='C:/PROGRA~1/MSVS10/VC/BIN/cl.exe'
HOSTLD='C:/devtools/cygwin/bin/link.exe'
It has picked cl.exe correctly, oopsie on link.exe.
Kumar
On 10/07/2012 10
cked cl.exe correctly, oopsie on link.exe.
Kumar
On 10/07/2012 10:59 AM, Kumar Srinivasan wrote:
nOn 7/9/2012 5:20 PM, David Holmes wrote:
On 10/07/2012 9:51 AM, Kumar Srinivasan wrote:
On windows, I see a failure when building hotspot, as as follows.
Kumar
link.exe /SAFESEH /manifest ker
comments inlined...
I think Kumar Srinivasan would be the best person to answer if adding a
$ORIGIN/../lib/
RPATH entry to jre/bin/java would be an issue or not. I suspect it is not an
issue.
But I'd recommend some well placed comments in the Makefile explaining the need
if we do
Hi Omair,
Hi Kumar,
On 07/23/2012 11:19 AM, Kumar Srinivasan wrote:
My suggestion is to see if System.loadLibrary can be used, this will
bode well for the
modularization effort.
Unfortunately, this bug can come up with proprietary third-party code
that cant be modified by the users of OpenJDK
On 7/25/2012 2:23 PM, Kelly O'Hair wrote:
Naoto has noticed this build failure on the Mac (just the Mac) when building
just the jdk repository.
From what I can tell, the Mac build of the jdk repository now depends on the
langtools repository also
being built, which means that partial builds o
Hello Omair,
Hi Kumar,
On 07/23/2012 11:19 AM, Kumar Srinivasan wrote:
My suggestion is to see if System.loadLibrary can be used, this will
bode well for the modularization effort.
I discussed this with the folks at awt-dev and they would prefer to
avoid loading as much as possible. They are
he fix can be pushed to a repo.
Thanks for finding and fixing this issue.
--
best regards,
Anthony
On 8/10/2012 1:48 AM, Omair Majid wrote:
On 08/09/2012 07:15 AM, Andrew Hughes wrote:
- Original Message -
Hi Kumar,
On 07/23/2012 11:19 AM, Kumar Srinivasan wrote:
My suggestion is
Hi Kumar,
On 07/23/2012 11:19 AM, Kumar Srinivasan wrote:
My suggestion is to see if System.loadLibrary can be used, this
will
bode well for the modularization effort.
I discussed this with the folks at awt-dev and they would prefer to
avoid loading as much as possible. They are strongly
On 8/10/2012 1:56 PM, Omair Majid wrote:
Hi Anthony,
On 08/10/2012 08:29 AM, Anthony Petrov wrote:
Actually, if Omair has a good automatic jtreg test, we would be happy to
get it checked in with this fix. Could we see a webrev for the test please?
I have uploaded a new webrev that includes a t
Hi Anthony, Omair.
Here is the patch for the test, this will live in test/tools/launcher,
also I don't have access
to a MacOS system, appreciate if you can add this otherwise I will file
a bug and add
the macosx case later on.
Thanks
Kumar
Hi Omair and Kumar,
As to me, the fix and the tes
I have pointed out some changes below, but there is a serious problem.
You are checking for the system arch using uname but the
java architecture may not be the same.
For example we run 32-bit jdk on a 64bit system, this will cause test
failures
since we will be using the wrong path names.
Yo
I see your point. As I told you we'll be open-sourcing a JAWT-specific
test under 7190587. This test already provides support for Linux,
Solaris, and Windows platforms, and even does a little more than just
loads the jawt library.
So it looks there's still some value in Kumar's test as well.
- Original Message -
I have pointed out some changes below, but there is a serious
problem.
You are checking for the system arch using uname but the
java architecture may not be the same.
For example we run 32-bit jdk on a 64bit system, this will cause test
failures
since we will be u
Hi Omair,
Thumbs up!. please let me know when you actually push I will set the CR,
so that
the integrator does not get confused, and I don't get awt push
notifications.
And once again thanks for doing this...
Kumar
On 08/14/2012 07:13 AM, Kumar Srinivasan wrote:
I see your point.
veHeader on the classpath. The javac used
in that ant script is the bootjdk javac, which usually doesn't provide the
annotation. I suppose the correct fix would be to change the ant script to use
the bootstrap javac instead.
/Erik
On 2012-07-28 00:06, Kumar Srinivasan wrote:
On 7/25/20
I focus on pack200, java launcher and javac, and for the launcher
I am sometimes forced to use windows as the development platform.
Building incrementally the launcher, saves me a lot of time.
This is how it works:
1. make launcher specific files and test with ALT_OUTPUTDIR.
2. build all the to
also it is being used by the jdk tl/etc integrator to build PIT bundles.
I agree
with the others it has been very useful in the past.
Kumar
I agree with Jon. SKIP_BOOT_CYCLE=false has been a useful and handy
test case (building JDK with the newly built JDK) to catch issues
early on.Such
On 9/24/2012 6:46 AM, Andrew Hughes wrote:
- Original Message -
hi all,
this may seem a strange request but here goes..
IBM ships its runtimes with a javaw launcher on all platforms - not
just Windows.
We do this for consistency reasons so that applications using Java
know tha
Hi,
{ I don't know if this has been brought my apologies if it has }
When using NetBeans sometimes the import statements are inserted preceding
the Copyright header, this happens with a new java file containing a
Copyright header,
and if import statements are absent, in which case NB does not k
Hello,
Please review changes to rev up the default -source and -target for jdk
compilation,
thus producing v52.0 class files.
Bug is here:
https://jbs.oracle.com/bugs/browse/JDK-8001191
Webrev is here:
http://cr.openjdk.java.net/~ksrini/8001191/webrev.0/
Note: this webrev is generated agains
separate issue when we start the lambda merges.
Kumar
On Oct 31 2012, at 10:43 , Kumar Srinivasan wrote:
Hello,
Please review changes to rev up the default -source and -target for jdk
compilation,
thus producing v52.0 class files.
Bug is here:
https://jbs.oracle.com/bugs/browse/JDK-8001191
Kumar
/Erik
On 2012-11-01 02:38, David Holmes wrote:
Hi Kumar,
So after this jdk8 builds will have to use current langtools javac in
order to work?
The corresponding changes to the new build system will be needed as
well.
David
On 1/11/2012 3:43 AM, Kumar Srinivasan wrote:
Hello,
P
gtools javac in
order to work?
The corresponding changes to the new build system will be needed as well.
David
On 1/11/2012 3:43 AM, Kumar Srinivasan wrote:
Hello,
Please review changes to rev up the default -source and -target for jdk
compilation,
thus producing v52.0 class files.
Bug
g jax* and corba are using -source/target 8 ?
Kumar
-kto
On Nov 2, 2012, at 6:51 AM, Kumar Srinivasan wrote:
Hello Erik,
For the new build, the change is done in jdk/makefiles/Setup.gmk, in the macro
call for GENERATE_JDKBYTECODE. Would be nice if that change went in the same
changeset.
Hi Erik,
I tested this on my failing system and the build works now,
but I am not a m4 expert to say if the fix is correct or not.
Kumar
This is a simple fix for when objcopy is missing.
http://cr.openjdk.java.net/~erikj/8003300/webrev.root.01/
/Erik
Hi,
Is it possible for the new infra, to produce a composite image of both
server and
client VMs on Solaris 32-bit
For extra credits is it possible to build the 64 bit image as well and
have it merged
into a composite image of 32-bit variants ?
Thanks
Kumar
Hi,
[jib LOG] Mirror site llg
[jib LOG]
Downloadinghttps://jpg.uk.oracle.com/artifactory/jdk-virtual/com/oracle/java/jib/jib/3.0-SNAPSHOT/jib-3.0-SNAPSHOT-distribution.zip
[jib ERR] Checksum for
'/var/tmp/jib-hudson/download/com/oracle/java/jib/jib/3.0-SNAPSHOT/jib-3.0-SNAPSHOT-distribution.zi
Hello,
Please review build change to enable the javadoc tool to produce concise
API
documentation for those classes that override a method without changing its
specification see [2], this change simply enables that feature in the
javadoc tool.
diff --git a/make/Docs.gmk b/make/Docs.gmk
---
Hello,
Please review fix [1] for VS2017 to compile pack200 native header
file, without warnings.
Thanks
Kumar
[1] http://cr.openjdk.java.net/~ksrini/8201259/
Hi John,
I focused mainly on the native side, looks ok, except for a couple of
minor issues.
java.c
1320 const char *prop = "-Djdk.internal.javac.source=";
1321 size_t size = JLI_StrLen(prop) + JLI_StrLen(value) + 1;
1322 char *propValue = (char
+1
Kumar
Hi Erik,
As long as the end result is a jvm.cfg that matches the current ones
in the repo then this looks fine.
Thanks,
David
On 12/05/2018 3:46 AM, Erik Joelsson wrote:
Here is a new attempt. This time I'm pretty sure it produces the same
jvm.cfg as all the predefined ones. It'
The changes look ok to me, however I am wondering if the module
could be called jdk.unpack200 and not jdk.pack200 ? since it
contains only the unpacker, and the bin utilities are pack200 and
unpack200.
Kumar
On 3/4/2015 5:13 PM, Mandy Chung wrote:
As listed in an open issue in JEP 200:
The jdk
Hi Magnus,
*||make/common/NativeCompilation.gmk*
Typo: s/explicitely/explicitly/
I don't quite understand the changes ;) but Mr ErikJ has done the
honors. :-)
Thanks
Kumar
On 3/17/2015 5:58 AM, Magnus Ihse Bursie wrote:
It turned out that the fix for JDK-8074796 (Disabling warnings on
On 6/8/2015 9:57 PM, Jan Lahoda wrote:
On 9.6.2015 01:31, Daniel D. Daugherty wrote:
>
http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01
langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
old L171: case "1.9":
Henry,
Generally looks good here are some comments, on my initial
pass, I am not fully done with args.c I will look at this some
more later today or tomorrow.
args.c:
1.) Can be folded
45 char *rv;
46
47 rv = (char *) JLI_MemAlloc(len + 1);
char *rv = (char *) JLI_MemAlloc(len +
Hello,
http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html
You are undefining Windows math.h OVERFLOW, what is it defined
as ? With you redefining this, will it cause problems for users of
this API, lik
I am good with this change!.
I would like the rest of the component teams to weigh in on the others.
Thanks
Kumar
On 12/16/2015 12:18 PM, Magnus Ihse Bursie wrote:
On 2015-12-16 16:33, Kumar Srinivasan wrote:
Hello,
http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition
Hi All,
Please review the following build changes:
JDK changes:
* simple entry point change
http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.jdk.0/
Top forest repo:
* configuration changes to use the new javadoc/doclet implementation
* module dependency changes (*Mandy, Alan*)
http:/
HI Magnus,
In make/gensrc/Gensrc-jdk.javadoc.gmk:
Did you mean to remove the old javadoc version.properties? If not, and
you want two files from now on, you need to give them unique names as
the first argument, e.g. OLD_JAVADOC_VERSION and JAVADOC_VERSION, or
something like that.
Is this suf
+
+
+ jdk.javadoc.doclet.taglet
+
Thanks
Kumar
On 22/01/2016 22:50, Kumar Srinivasan wrote:
Hi All,
Please review the following build changes:
JDK changes:
* simple entry point change
http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.jdk.0/
Top forest repo:
* configuration
+1, I have also tested on Windows.
Kumar
On 7/13/2016 2:05 PM, joe darcy wrote:
Hi Bhavesh,
This looks fine to get the build going again; please push this right
away.
As we discussed off-list, there will probably need to be some
additional javadoc mechanisms so that checking for this kind
Hello,
Please review:
http://cr.openjdk.java.net/~ksrini/8039305/webrev.00/
Fix for:
https://bugs.openjdk.java.net/browse/JDK-8159305
This was reported as a broken link, but the fix is to make
the Taglet API bundle "whole", in that, keep all the supporting
files needed by the API bundle, and n
,
Some notes:
577: Not sure I agree with repeating the definition of OLD_DOCLET_DIR.
580-587: All these new variables are defined but never used. If you
intend to use these values, you also need to add them somewhere in
610-620.
/Erik
On 2016-08-01 23:56, Kumar Srinivasan wrote:
Hello,
Please
ay, in the old make/infra work as
well.
Kumar
/Erik
On 2016-08-02 22:25, Kumar Srinivasan wrote:
Hello Erik,
Ok I fixed the items you pointed out, also in my last email, the JIRA
reference was incorrect, the correct JIRA should be:
https://bugs.openjdk.java.net/browse/JDK-8039305
The modified
+1.
Kumar
On 29/09/2016 16:25, Erik Joelsson wrote:
Volker's comment above was directed at the suggestion of taking the
problematic AIX specific code out of the OpenJDK repositories and create
a separate library with a separate lifecycle somewhere else that OpenJDK
for AIX would then need to
Hello,
Please review the fix for:
https://bugs.openjdk.java.net/browse/JDK-8169001
Webrev at:
http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/
Background:
Launcher ergonomics was introduced last decade to help determine
if the execution system is "Server Class", this was necessary to
cho
Hi David,
Thanks for the review please see embedded comments:
Hi Kumar,
On 8/11/2016 4:47 AM, Kumar Srinivasan wrote:
Hello,
Please review the fix for:
https://bugs.openjdk.java.net/browse/JDK-8169001
Webrev at:
http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/
Overall this looks
/2016 3:24 PM, David Holmes wrote:
Hi Kumar,
On 8/11/2016 4:47 AM, Kumar Srinivasan wrote:
Hello,
Please review the fix for:
https://bugs.openjdk.java.net/browse/JDK-8169001
Webrev at:
http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/
Overall this looks like a complete eradication of the
Hi Volker et. al.,
Was a bug opened to track this ? I still see these files around
http://hg.openjdk.java.net/jdk9/dev/jdk/file/ff45c582ca8a/src/java.base/aix/native/libjli
Would you like me to create a bug for you ?
Thanks
Kumar
On 9/29/2016 9:59 AM, Volker Simonis wrote:
On Thu, Sep 29, 201
Hi Volker,
Hi Volker et. al.,
Was a bug opened to track this ? I still see these files around
http://hg.openjdk.java.net/jdk9/dev/jdk/file/ff45c582ca8a/src/java.base/aix/native/libjli
Hi Kumar,
no, as far as I know there's no bug for this issue until now.
Have created a bug for you:
https
Looks good
On 2017-01-18 18:57, Henry Jen wrote:
Hi,
Please review the webrev to remove jvisualvm from JDK9.
http://cr.openjdk.java.net/~henryjen/jdk9/8160881/jdk/webrev/
Looks good to me.
/Magnus
Hello,
As explained in the JBS issue [1], this new taglet enables API documents
to contain the extLink tag to link external sources.
Please review the webrev [2].
Thanks
Kumar
[1] https://bugs.openjdk.java.net/browse/JDK-8178725
[2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/
Thanks Erik, yes will wait for Magnus' and Jon's comments.
Kumar
The build change looks ok to me, but Magnus should definitely look at
this since he is so heavily involved in the Javadoc build right now.
/Erik
On 2017-04-18 19:44, Kumar Srinivasan wrote:
Hello,
As explained
ot;{@extLink"
and the name. [1]
-- Jon
[1]:
https://blog.codinghorror.com/regular-expressions-now-you-have-two-problems/
On 04/18/2017 11:26 AM, Kumar Srinivasan wrote:
Thanks Erik, yes will wait for Magnus' and Jon's comments.
Kumar
The build change looks ok to me, but M
4-18 19:44, Kumar Srinivasan wrote:
Hello,
As explained in the JBS issue [1], this new taglet enables API
documents
to contain the extLink tag to link external sources.
Please review the webrev [2].
Changes looks good.
Just a reflection: This is heavily biased to Oracle documentation. Ev
On 4/19/2017 1:37 PM, David Holmes wrote:
On 20/04/2017 3:50 AM, Kumar Srinivasan wrote:
We could potentially make the default URL to be "some" cgi url,
and have the build system specify the URL all the time, in our
case it would be the Oracle documentation URL.
Would this be an
doc comments.
-- Jon
On 04/19/2017 01:37 PM, David Holmes wrote:
On 20/04/2017 3:50 AM, Kumar Srinivasan wrote:
We could potentially make the default URL to be "some" cgi url,
and have the build system specify the URL all the time, in our
case it would be the Oracle documentation URL
04/19/2017 01:37 PM, David Holmes wrote:
On 20/04/2017 3:50 AM, Kumar Srinivasan wrote:
We could potentially make the default URL to be "some" cgi url,
and have the build system specify the URL all the time, in our
case it would be the Oracle documentation URL.
Would this be an accep
Hi,
Please review fix for the custom taglet to allow openjdk builds, in
which case
the property "build.tools.taglet.ExtLink.NO_LINK" must be set to inhibit
server
side lookups.
Thanks
Kumar
Webrev: http://cr.openjdk.java.net/~ksrini/8179915/webrev.0
JBS: https://bugs.openjdk.java.net/browse/
On 5/10/2017 9:51 AM, Erik Joelsson wrote:
Should this be set on the javadoc command line somewhere or am I
missing something?
Yes, one would have to set this prop, via the build system, when
performing a non-oracle build.
Kumar
/Erik
On 2017-05-10 09:42, Kumar Srinivasan wrote:
Hi
umvent the build system
to get the effect?
Thanks, Roger
On 5/10/2017 12:42 PM, Kumar Srinivasan wrote:
Hi,
Please review fix for the custom taglet to allow openjdk builds, in
which case
the property "build.tools.taglet.ExtLink.NO_LINK" must be set to
inhibit server
side lookups.
Hi,
Changes in this webrev:
* inverted the logic as you suggested
* some doc comment changes to reflect the change
http://cr.openjdk.java.net/~ksrini/8179915/webrev.1/
Thanks
Kumar
On 5/10/2017 7:19 PM, David Holmes wrote:
On 11/05/2017 3:18 AM, Kumar Srinivasan wrote:
On 5/10/2017 9:51 AM
Looks good, and thanks for fixing this quickly!.
Kumar
With the removal of the -d64 flag, bootcycle builds started failing.
This patch stops trying to use -d64 completely for the boot jdk since
it shouldn't be needed for either JDK 8 or 9. The checks that used
this parameter to see if the JV
Hello,
Please review the changes to fix JDK-8180334, essentially -DJAVA_ARGS
exceeds
a Visual Studio C++ compiler limit, and this fix provides a way to specify
very long string literals, by the build system.
This also includes some minor and subtle simplifications and cleanups wrt.
the JAVA
, 2017, at 2:58 PM, Kumar Srinivasan
wrote:
Hello,
Please review the changes to fix JDK-8180334, essentially -DJAVA_ARGS exceeds
a Visual Studio C++ compiler limit, and this fix provides a way to specify
very long string literals, by the build system.
This also includes some minor and subtle
as
compile time and runtime check, the latter for a good measure.
Thanks
Kumar
PS: Mandy, could you please file a RFE for the jlink requirements and
assign it to me.
On Jun 7, 2017, at 2:58 PM, Kumar Srinivasan
wrote:
Hello,
Please review the changes to fix JDK-8180334, essentially
Hi Jon,
Looks good to me.
Thanks
Kumar
Please review a simple fix to the regex used to analyze the content of
an {@extLink } tag.
The fix is to use DOTALL mode for the regex, and for good measure, to
ensure the match is up to the end of the line.
JBS: https://bugs.openjdk.java.net/browse
Hello,
Please review the changes to remove Solaris 32-bit binaries from JDK8
distros,
at this time the dual mode support in the launcher is being disabled.
Message regarding this:
http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html
The jdk changes are here:
http://cr.op
appy ? this is specific to solaris you are free to have
something else that suits your purposes.
#ifdef __solaris__
-# define DUAL_MODE
+# ifdef DUAL_MODE
+#undef DUAL_MODE
+# endif
Kumar
On Fri, Sep 6, 2013 at 9:47 AM, Kumar Srinivasan
mailto:[email protected]
On 9/6/2013 12:21 PM, Alan Bateman wrote:
On 06/09/2013 17:47, Kumar Srinivasan wrote:
Hello,
Please review the changes to remove Solaris 32-bit binaries from JDK8
distros,
at this time the dual mode support in the launcher is being disabled.
Message regarding this:
http
/sun/tools/jhat/HatRun.java
It isn't clear to me why you need to retain the d64 variable at all.
---
test/tools/launcher/ExecutionEnvironment.java
typo: appopriate
Thanks,
David
On 7/09/2013 2:47 AM, Kumar Srinivasan wrote:
Hello,
Please review the changes to remove Solaris 32-bi
hannel/lib/solaris-amd64/libLauncher.so
I know this already exist but I thought binaries were disallowed in
the open repo?
Alan, are the nio changes acceptable? Let me know if you need more time
to go over all
the changes.
Kumar
Davud
On 9/09/2013 1:09 PM, Kumar Srinivasan wrote:
Hi Davi
th = exe;
205 }
I think this should be:
198 if (home.length() > 0) {
201 exePath = home + File.separator + "bin" + File.separator
+ exe;
203 } else {
204 exePath = exe;
205 }
Thanks,
/St
Hi Tomas,
Looks good!, and thanks for doing this, some minor comments
There is a typo though.
+# It's a JAR or ZIP file, let's do it differntly
s/differntly/differently/
2711 print "No access to jar, so can't produce diffs for jar
files"
this message should b
Hi Tomas,
Approved.
Thanks
Kumar
Hi Kumar,
updated webrev: <http://cr.openjdk.java.net/~thurka/8025920/webrev.01>
On 4 Oct 2013, at 16:08, Kumar Srinivasan wrote:
Hi Tomas,
Looks good!, and thanks for doing this, some minor comments
There is a typo though.
+# It&#
On 10/11/2013 4:15 AM, David Holmes wrote:
On 11/10/2013 9:02 PM, Alan Bateman wrote:
Looks good. At some point it would be great to have a page somewhere
with the list of things that need to be updated when we move major
versions. There always seems to be something that only remember late in
t
Hi Tim,
I looked at the changes, and it seems to be ok.
That's it ? This works ? I tried this earlier but it did not work for
me, though
the jprt build completed the tests would stall, maybe I missed something.
Thanks
Kumar
Hello
This is a piece of followup work to JDK-8023288 "Remove Sol
Hello,
Please review the removal of extraneous docs (specifically javaws.1) no
longer need for
Solaris.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8026500
Webrev:
http://cr.openjdk.java.net/~ksrini/8026500/webrev/
Thanks
Kumar
On 10/15/2013 11:51 AM, Tim Bell wrote:
On 10/15/13 10:26 AM, Kumar Srinivasan wrote:
That's it ? This works ? I tried this earlier but it did not work for
me, though
the jprt build completed the tests would stall, maybe I missed
something.
Not quite. There was also a bit of fiddli
+1
Kumar
On 10/17/2013 9:11 AM, Tim Bell wrote:
Hi Erik:
Please review this simple patch extending the recognized make
versions in configure to 4.0, which was recently released and is
already default in Cygwin. I also removed the version check in
NewMakefile.gmk since it seems redundant hav
Hi Alex,
This looks good, and thanks for spotting this and fixing it.
Kumar
On 11/8/2013 6:57 AM, Alexander Zuev wrote:
Hello,
please review my fix for the issue JDK-8027900: pack200 option is
broken due to the incorrect makefile definition for its driver
The problem is that in the def
Hi Volker,
One thing I notieced,
BOOT_RTJAR=`$BOOT_JDK/bin/java -XshowSettings 2>&1 ...
I suggest using java -XshowSettings:props -version 2>&1 .
props, will narrow down the reporting to only properties section, which is
really what you want
-version, will allow the launcher to
Hello,
Please review these changes to remove applet related demos from the
images and thereby
from the Solaris distributions. Note: at this time appletviewer is still
available in the distros,
as there are tests dependent on it.
http://cr.openjdk.java.net/~ksrini/8028645/webrev.0/
Thanks
Kum
/demo/nbproject/%
196 $(call install-file)
197 $(CHMOD) -f ug+w $@
198 ifeq ($(OPENJDK_TARGET_OS), solaris)
199 $(RM) -r $(JDK_OUTPUTDIR)/demo/nbproject/jfc/SwingApplet
200 endif
/Erik
On 2013-11-20 00:36, Kumar Srinivasan wrote:
Hello,
Please review
Hi,
Previously in 8 we removed solaris 32-bit along with it, various
deployment tools and related
demos. This is to fix a stray straggler which managed to creep in due to
a flawed previous fix.
The flawed fix is removed and the right fix has been applied now.
The bug:
https://bugs.openjdk.jav
Hi Magnus,
Is this formalized some place ? If not it would be good to get this
formalized and
posted on a wiki or at http://openjdk.java.net/groups/build/
Thanks
Kumar
On 10/8/2013 12:40 AM, Magnus Ihse Bursie wrote:
Whitespace and indentation in makefiles is a more problematic area
than f
Hello,
Please review the removal of ISA (Instruction Specific Architecture)
directories namely sparcv9, amd64
and the symlinks in these directories, this was provided to aid
transition to jdk8, where solaris 32-bit was
removed, and the 32-bit binaries were replaced with 64-bit versions.
ht
On 12/21/2013 12:08 AM, Alan Bateman wrote:
On 20/12/2013 23:03, Kumar Srinivasan wrote:
Hello,
Please review the removal of ISA (Instruction Specific Architecture)
directories namely sparcv9, amd64
and the symlinks in these directories, this was provided to aid
transition to jdk8, where
Hello Magnus,
On our team CI server we are seeing these failures on Windows,
are they related to this fix ? Or is this something else ?
Message snippet inlined below.
Thanks
Kumar
checking Checking for install src... found
checking for ant... /devtools/ant-1.7.1/bin/ant
checking for JUnit... n
Never mind it is indeed the same issue, I found the bug filed by Brad on
this.
Thanks
Kumar
On 2/25/2014 6:11 AM, Kumar Srinivasan wrote:
Hello Magnus,
On our team CI server we are seeing these failures on Windows,
are they related to this fix ? Or is this something else ?
Message snippet
Looks good but IIRC PPC also needs this.
Kumar
On 5/22/2014 1:13 PM, Mikael Vidstedt wrote:
Please review the following change, destined for jdk7u-dev. The zip
implementation in unpack200 depends on _BIG_ENDIAN being defined on
big endian platforms, and the define is missing on the linux/spa
Looks good. The JBS bug needs noreg-build
Thanks
Kumar
On 5/29/2014 1:29 PM, Mikael Vidstedt wrote:
Please review the below fix which removes a couple of build options
used when compiling/linking the unpack200 executable - specifically
-xregs=no%appl and -xmemalign=4s.
Bug: https://bugs.o
Looks good. The JBS bug needs noreg-build
Thanks
Kumar
On 5/29/2014 1:29 PM, Mikael Vidstedt wrote:
Please review the below fix which removes a couple of build options
used when compiling/linking the unpack200 executable - specifically
-xregs=no%appl and -xmemalign=4s.
Bug: https://bugs
ect, if he has time?
Thoughts?
Regards,
Albert
--
Kumar Srinivasan
Sun Microsystems, Java Software.
408-276-7586
Changeset: db4bd081eff2
Author:ksrini
Date: 2008-08-19 07:50 -0700
URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/db4bd081eff2
6614210: JPRT Windows 32bit msival2 build failure when building 'install'
workspace
Summary: suppresses wscript's modal dialog on error and no msi vali
1 - 100 of 115 matches
Mail list logo
