Re: RFR: 8284209: Replace remaining usages of 'a the' in source code

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: > a/the, an?/an?, the/the… > > It's the last issue in the series, and it still touches different areas of > the code. Logging/JNDI OK - Marked as revi

Re: RFR: 8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues [v2]

On Fri, 13 May 2022 14:36:02 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the failure >> handler command `dmesg` on macOS? >> >> As noted in the JBS issue, the command currently fails with permission >> error. The commit in this PR uses `sudo` as s

Re: RFR: 8285915: failure_handler: gather the contents of /etc/hosts file

On Fri, 29 Apr 2022 11:28:32 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which addresses > https://bugs.openjdk.java.net/browse/JDK-8285915? > > With this change, the environment details collected by the failure handler > will now include the contents of the `/etc/hosts

Re: RFR: 8284890: Support for Do not fragment IP socket options [v8]

On Wed, 20 Apr 2022 14:30:21 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following PR review please? It adds a new JDK specific >> extended socket option >> called IP_DONTFRAGMENT, which disables IP packet fragmentation in both IPv4 >> and IPv6 >> UDP sockets (NIO DatagramChannels

Re: RFR: 8284890: Support for Do not fragment IP socket options [v5]

On Tue, 19 Apr 2022 15:54:02 GMT, Michael McMahon wrote: >> test/jdk/jdk/net/ExtendedSocketOption/DontFragmentTest.java line 44: >> >>> 42: StandardProtocolFamily fam = args[0].equals("ipv4") ? INET : >>> INET6; >>> 43: System.out.println("Family = " + fam); >>> 44: test

Re: RFR: 8284890: Support for Do not fragment IP socket options [v5]

On Tue, 19 Apr 2022 14:47:01 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following PR review please? It adds a new JDK specific >> extended socket option >> called IP_DONTFRAGMENT, which disables IP packet fragmentation in both IPv4 >> and IPv6 >> UDP sockets (NIO DatagramChannels

Re: RFR: 8284890: Support for Do not fragment IP socket options

On Thu, 14 Apr 2022 16:04:22 GMT, Michael McMahon wrote: > Hi, > > Could I get the following PR review please? It adds a new JDK specific > extended socket option > called IP_DONTFRAGMENT, which disables IP packet fragmentation in both IPv4 > and IPv6 > UDP sockets (NIO DatagramChannels). For

Re: RFR: 8277459: Add jwebserver tool [v5]

On Mon, 29 Nov 2021 13:57:13 GMT, Julia Boes wrote: >> This change introduces jwebserver, a dedicated JDK tool for the Simple Web >> Server. >> >> A description is provided in a follow-up comment. > > Julia Boes has updated the pull request incrementally with one additional > commit since the

Re: RFR: 8277459: Add jwebserver tool [v3]

On Wed, 24 Nov 2021 17:29:40 GMT, Julia Boes wrote: >> This change introduces jwebserver, a dedicated JDK tool for the Simple Web >> Server. >> >> A description is provided in a follow-up comment. > > Julia Boes has updated the pull request incrementally with one additional > commit since the

Re: RFR: 8277847: Support toolGuide tag in class-level documentation

On Fri, 26 Nov 2021 14:31:04 GMT, Julia Boes wrote: >> make/jdk/src/classes/build/tools/taglet/ToolGuide.java line 159: >> >>> 157: .toString() >>> 158: .replace('.', '/') >>> 159: .replaceAll("[^/]+", ".."); >> >> If the c

Re: RFR: 8277847: Support toolGuide tag in class-level documentation

On Thu, 25 Nov 2021 15:58:58 GMT, Julia Boes wrote: > This change adds support for the `@toolGuide` tag in class-level API > documentation. > > (A use case is the jwebserver tool, where the > com.sun.net.httpserver.SimpleFileServer class provides API points for > extension and customization

Re: RFR: 8277459: Add jwebserver tool [v2]

On Wed, 24 Nov 2021 17:15:35 GMT, Julia Boes wrote: >> This change introduces jwebserver, a dedicated JDK tool for the Simple Web >> Server. >> >> A description is provided in a follow-up comment. > > Julia Boes has updated the pull request incrementally with one additional > commit since the

Re: RFR: 8277459: Add jwebserver tool

On Mon, 22 Nov 2021 09:43:19 GMT, Julia Boes wrote: > This change introduces jwebserver, a dedicated JDK tool for the Simple Web > Server. > > A description is provided in a follow-up comment. src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/resources/simpleserver.properties

Re: RFR: 8277459: Add jwebserver tool

On Mon, 22 Nov 2021 09:43:19 GMT, Julia Boes wrote: > This change introduces jwebserver, a dedicated JDK tool for the Simple Web > Server. > > A description is provided in a follow-up comment. src/jdk.httpserver/share/classes/com/sun/net/httpserver/SimpleFileServer.java line 110: > 108: *

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v8]

On Wed, 29 Sep 2021 11:02:05 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an implementation class whose main meth

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v7]

On Tue, 28 Sep 2021 10:08:29 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an implementation class whose main meth

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v6]

On Wed, 22 Sep 2021 15:26:33 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an implementation class whose main meth

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

On Tue, 21 Sep 2021 16:03:28 GMT, Hannes Wallnöfer wrote: >> Hmm... When printing messages on the console don't we want a localized date? >> Or are you referring to other usages of the date formatter? Worth double >> checking in any case. > > The problem I was referring to was not about printi

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an implementation class whose main meth

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

On Tue, 21 Sep 2021 15:06:09 GMT, Hannes Wallnöfer wrote: >> test/jdk/com/sun/net/httpserver/simpleserver/SecurityManagerTest.java line >> 198: >> >>> 196: >>> 197: static final DateTimeFormatter HTTP_DATE_FORMATTER = >>> 198: DateTimeFormatter.ofPattern("EEE, dd MMM HH:mm

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v4]

On Mon, 20 Sep 2021 16:09:14 GMT, Daniel Fuchs wrote: >> Julia Boes has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' into simpleserver >> - check

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v4]

On Mon, 20 Sep 2021 15:28:05 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an implementation class whose main meth

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

On Tue, 14 Sep 2021 16:47:45 GMT, Daniel Fuchs wrote: >> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an i

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes wrote: > This change implements a simple web server that can be run on the > command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, > an implementation class whose main method is

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

On Tue, 14 Sep 2021 12:38:19 GMT, Jim Laskey wrote: >> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java >> line 128: >> >>> 126: * {@code headers} are the effective headers of the response. >>> The >>> 127: * response body bytes are a {@code UTF-8} encoded b

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

On Tue, 14 Sep 2021 16:07:21 GMT, Julia Boes wrote: >> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line >> 288: >> >>> 286: } >>> 287: >>> 288: private static final Headers EMPTY = new UnmodifiableHeaders(new >>> Headers()); >> >> IDEA warns here: >>>Referenc

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

On Tue, 14 Sep 2021 13:19:17 GMT, Andrey Turbanov wrote: >> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an implementation class whose mai

Re: RFR: 8273092: Sort classlist in JDK image [v2]

On Tue, 31 Aug 2021 01:05:05 GMT, Ioi Lam wrote: >> When the classlist is generated using build.tools.classlist.HelloClasslist, >> its contents may be non-deterministic due to Java thread execution order. >> >> We should sort the generated classlist to make the JDK image's contents more >> det

Re: RFR: 8273092: Sort classlist in JDK image

On Fri, 27 Aug 2021 23:12:52 GMT, Ioi Lam wrote: > When the classlist is generated using build.tools.classlist.HelloClasslist, > its contents may be non-deterministic due to Java thread execution order. > > We should sort the generated classlist to make the JDK image's contents more > determin

Re: RFR: 8272805: Avoid looking up standard charsets [v2]

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up t

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e38

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]

On Wed, 28 Oct 2020 08:54:31 GMT, Peter Levart wrote: >> Some thoughts regarding the parameter type of refersTo. Summary: I think >> `refersTo(T)` is fine and that we don't want to change it to >> `refersTo(Object)`. >> >> I don't think we have a migration issue similar to generifying collecti

RFR: 8205945 - Revert unintended changes to make/gensrc/Gensrc-jdk.hotspot.agent.gmk

[resending with correct subject] Hi, https://bugs.openjdk.java.net/browse/JDK-8205945 8205945: Revert unintended changes to make/gensrc/Gensrc-jdk.hotspot.agent.gmk My fix for 8205397 [1] includes a change to make/gensrc/Gensrc-jdk.hotspot.agent.gmk that was not intended: diff --git a/make

RFR: Revert unintended changes to make/gensrc/Gensrc-jdk.hotspot.agent.gmk

Hi, My fix for 8205397 [1] includes a change to make/gensrc/Gensrc-jdk.hotspot.agent.gmk that was not intended: diff --git a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk --- a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk +++ b/make/gensrc/Gensrc-jdk.hotspo

Re: RFR: JDK-8204973: Add build support for filtering translations

Hi Erik, The modifications to the logging test look good to me. Caveat: I don't speak chinese nor japanese ;-) cheers, -- daniel On 13/06/18 20:47, Erik Joelsson wrote: Hello, Oracle will reduce the number of languages that it maintains translations of JDK resources for. The current transla

Re: RFR: JDK-8190702: JMC packaging causing errors in JDK 10 consolidated repo (macOS)

Thanks for that Erik! It's been annoying me for a couple of days :-) I have imported your patch locally in my repo and it seems to be working fine. Hopefully someone from the build team will give you a thumbs up! best regards, -- daniel On 14/11/2017 22:35, Erik Joelsson wrote: When I added

Re: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent

+1 libmanagement_agent is indeed a better name :-) best regards, -- daniel On 02/02/17 22:27, Mandy Chung wrote: libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/81738

Heads up: Fwd: hg: jdk9/dev/jdk: 8173607: JMX RMI connector should be in its own module

Hi, A direct consequence of this change is that you may have to either blow up your ./build directory, or run 'make clean-java' after pulling this fix. Otherwise you may see strange build failures like below: Error occurred during initialization of VM java.lang.RuntimeException: Package com.sun

Re: RFR: 8173607: JMX RMI connector should be in its own module

Hi Mandy, On 02/02/17 02:41, Mandy Chung wrote: http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06 Does java.management still depend on java.base/jdk.internal.module? Well spotted! It doesn't. I have updated module-info.java for java.base. http://cr.openjdk.java.net/~dfuchs/webrev_

Re: RFR: 8173607: JMX RMI connector should be in its own module

Hi Mandy, On 01/02/17 05:11, Mandy Chung wrote: On Jan 31, 2017, at 10:26 AM, Daniel Fuchs wrote: Hi, Please find below a patch for: 8173607: JMX RMI connector should be in its own module https://bugs.openjdk.java.net/browse/JDK-8173607 webrev: http://cr.openjdk.java.net/~dfuchs

RFR: 8173607: JMX RMI connector should be in its own module

Hi, Please find below a patch for: 8173607: JMX RMI connector should be in its own module https://bugs.openjdk.java.net/browse/JDK-8173607 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05 This patch makes it possible to remove the requires transitive java.rmi from the java.m

Re: Review Request: JDK-8173608: Separate JDK management agent from java.management module

Hi Mandy, Looks good to me in general. Suggestion: FileLoginModule.java 112 private static final String PASSWORD_FILE_NAME = "jmxremote.password"; Maybe the constant could be public, then it could be referred to by ConnectorBootstrap? I see that com.sun.jmx.remote.internal is already be

Re: build failing on Mac

loads/index.action cheers, -- daniel Pete On 6/20/16 4:30 AM, Daniel Fuchs wrote: Hi Pete, I had the same problem recently - and solved it by installing Xcode 6.3 - which I was told is the officially supported version. best regards, -- daniel On 18/06/16 01:20, Pete Brunet wrote: I haven't d

Re: build failing on Mac

Hi Pete, I had the same problem recently - and solved it by installing Xcode 6.3 - which I was told is the officially supported version. best regards, -- daniel On 18/06/16 01:20, Pete Brunet wrote: I haven't done a full build in around a month, but just pulled (tpull -u) / cleaned / reconfig

Re: RFR: JDK-8073328: Incremental build of gensrc broken

On 17/02/15 16:38, Erik Joelsson wrote: Right, thanks for catching that. The OS specific file is not there for every OS. This patch should fix it. I'm testing all platforms now. Webrev: http://cr.openjdk.java.net/~erikj/8073328/webrev.jdk.03/ Thanks Erik. This one appears to work like a charm

Re: RFR: JDK-8073328: Incremental build of gensrc broken

Hi Erik, I tried to import your patch, and now the build fails with the following error: make[3]: *** No rule to make target `/Users/danielfuchs/workspaces/jdk/jdk9-dev-java-time/jdk/make/data/charsetmapping/stdcs-macosx', needed by `/Users/danielfuchs/workspaces/jdk/jdk9-dev-java-time/build/

Re: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8'

On 24/11/14 11:44, Erik Joelsson wrote: Hello Daniel, Test seems like a great idea. Thanks! OK - I have logged JDK-8065748 https://bugs.openjdk.java.net/browse/JDK-8065748 I'll send a patch for review when your fix is in :-) Thanks! -- daniel /Erik On 2014-11-20 18:25, Daniel

Re: RFR [JEP 220] Modular Run-Time Images

Hi Chris, I had a look at the changes in java.logging and java.management modules (+ corresponding tests) and they look reasonable to me. I also had a cursory look at the jdeps changes. It's difficult for me to review that without importing the changes and playing with the tool as this is a part

Re: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8'

-e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ +-e 's/\\=/=/' \ +| $(SORT) > $$@ $(CHMOD) -f ug+w $$@ # And do not forget this target I filed a separate issue [1] for investigating the use of pipefail. /Erik [1] https://bugs.openjdk.java.net

Re: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8'

ote: On 11/19/2014 4:09 PM, Mandy Chung wrote: On 11/19/2014 3:49 PM, Mandy Chung wrote: On 11/19/2014 12:50 PM, Daniel Fuchs wrote: On 11/19/14 9:36 PM, Mandy Chung wrote: resources.jar will be gone when we move to the modular runtime image (JEP 220 [1]). JDK-8065138 and JDK-8065365 will bec

Re: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK

On 15/10/14 17:19, shanliang wrote: Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/ The new version looks fine :-) -- daniel I add: ./01/jdk9-make/ for updating ./make/CompileJavaModules.gmk ./01/jdk9-jdk-src/ is same to ./00 Thanks, Shanliang Erik Jo

Re: RFR JDK-8044627: Update JNDI to work with modules

n 14/10/2014 14:34, Daniel Fuchs wrote: Hi Pavel, I saw your mail on build-dev. I guess the issue will resolve itself once we have the modular image. I wonder whether the way to go for now would be to add a single META-INF/services file - as you suggest - in java.naming, with the 4 lines inside

Re: Review request: 8055230: Rename attach provider implementation class

, Aix and Solaris versions could probably be unified. Ah - right - I missed those. Forget my comment then! Thanks Staffan! -- daniel /Staffan On 26 aug 2014, at 12:40, Daniel Fuchs wrote: Hi Mandy, I'm seeing some small differences in the various VirtualMachineImpl.java files, but i

Re: Review request: 8055230: Rename attach provider implementation class

Hi Mandy, I'm seeing some small differences in the various VirtualMachineImpl.java files, but if I'm not mistaken, all the new AttachProviderImpl.java look all the same. I wonder if the patch could be further simplified by moving AttachProviderImpl.java to jdk.attach/share/classes (unless there's

Re: RFR: 8048184 : (s) handle mercurial dev build version string

Hi Mike, This one works perfectly on my machine :-) Thumbs up! -- daniel On 7/8/14 7:40 PM, Mike Duigou wrote: I've updated the webrev with yet a different variant of the extract version field function. http://cr.openjdk.java.net/~mduigou/JDK-8048184/1/webrev/ Sorry Dave, I resist all atte

Re: RFR: 8048184 : (s) handle mercurial dev build version string

Hi, Thanks Dave, yes - your patch works like a charm :-) best regards, -- daniel Note: the following also works on my machine: -- check() { read var if expr 1 + $var >/dev/null ; then echo $var else return 2 fi } hgmajor="

Re: RFR: 8048184 : (s) handle mercurial dev build version string

On 7/8/14 1:40 PM, pointo1d wrote: What do you see if you run the script using bash ? Just the same. best regards, -- daniel

Re: RFR: 8048184 : (s) handle mercurial dev build version string

expression is neither an empty string nor 0. 1 the expression is an empty string or 0. 2 the expression is invalid. [ ... ] -- daniel On 7/8/14 12:30 PM, Daniel Fuchs wrote: Hi Mike, sorry for not reacting sooner. I applied your patch on my machine, and now get the foll

Re: RFR: 8048184 : (s) handle mercurial dev build version string

Hi Mike, sorry for not reacting sooner. I applied your patch on my machine, and now get the following: sh ./get_source.sh ./get_source.sh: line 70: [: too many arguments ./get_source.sh: line 76: [: `)' expected, found -1 ./get_source.sh: line 82: [: `)' expected, found -1 I have added: echo

Re: 8029805/8029806: Remove XXX addPropertyChangeListener and removePropertyChangeListener methods

On 12/10/13 12:06 PM, Alan Bateman wrote: (This one is for the jdk9-dev forest once it is created) The addPropertyChangeListener and removePropertyChangeListener methods defined by Pack200.{Packer,Unpacker} and LogManager methods are deprecated and flagged with a warning that they "will be remo

Re: JDK7u40: Community Code Review: webrev for non Oracle people?

On 10/4/13 7:05 PM, Francis ANDRE wrote: Hi This page http://openjdk.java.net/guide/codeReview.html states that one should use webrev for providing support of Community Code Review but it also states that any user with push access to the OpenJDK Mercurial server can

Re: RFR: 8016780: (xs) README-builds.html misses crucial requirement on bootstrap JDK

On 6/18/13 8:28 AM, David Holmes wrote: On 18/06/2013 4:02 PM, Jonathan Gibbons wrote: The only problem with using N is that you don't know whether you have broken building with N-1. Therefore the general recommendation for most people should be to always use N-1. I think Stuart is just searchi

Re: Fwd: Need help to resolve build errors on Mac os x

Hi, After cloning jdk8/tl you need to cd to the new clone and run: $ sh ./get_sources.sh to get the whole forest. Then you need to run configure (sh ./configure) and then only can you call make images. Hope this helps, (and BTW you may need to install Xcode & its command line tools as well a

Re: RFR: 8011347: JDK-8009824 has broken webrev with some ksh versions

On 4/16/13 5:02 PM, Jim Gish wrote: I've updated the version to 24.0 and add Mike as a reviewer. Could someone please push this for me? Hi Jim, Done. Thanks for the fix! -- daniel Thanks, Jim On 04/15/2013 06:34 PM, Mike Duigou wrote: I think the version number needs to be changed

Re: RFR: 8011347: JDK-8009824 has broken webrev with some ksh versions

On 4/16/13 5:02 PM, Jim Gish wrote: I've updated the version to 24.0 and add Mike as a reviewer. Could someone please push this for me? Hi Jim, I think you will need to update the bug id in your comment: http://cr.openjdk.java.net/~jgish/Bug8011347-webrev/tl.changeset 8009824: JDK-8009824 h

Re: RFR: 8011347: JDK-8009824 has broken webrev with some ksh versions

Hi Jim, I had a look at your changes and they looked fine. I imported the changeset on my Mac and it worked like a charm. Thanks for the fix! -- daniel PS: I am not a JDK reviewer. On 4/12/13 8:08 PM, Jim Gish wrote: Please review http://cr.openjdk.java.net/~jgish/Bug8011347-webrev/

Re: JDK-8010495: Update JAXP NetBeans project - add support for generating javadoc

7; to work properly in the editor. I have also restrained the packageset for the javadoc target as suggested by Joe. -- daniel On 3/25/13 12:45 PM, Daniel Fuchs wrote: Hi guys, I'd like to propose a small change to jaxp/build.xml and jaxp/nbproject/project.xml - in order to allow editing JA

Re: JDK-8010495: Update JAXP NetBeans project - add support for generating javadoc

Hi Joe, On 3/25/13 5:52 PM, huizhe wang wrote: On 3/25/2013 9:35 AM, Daniel Fuchs wrote: On 3/25/13 5:20 PM, huizhe wang wrote: Hi Daniel, Thanks for doing this. JAXP doesn't have these packages: "java/", "org/ietf/jgss/", and "org/omg/". Since this is

Re: JDK-8010495: Update JAXP NetBeans project - add support for generating javadoc

207 208 209 210 211 -- daniel Regards, Joe On 3/25/2013 4:45 AM, Daniel Fuchs wrote: Hi guys, I'd like to propose a small change to jaxp/build.xml and jaxp/nbproject/project.xml - in order to allow editing JAXP sources in NetBeans, as we

JDK-8010495: Update JAXP NetBeans project - add support for generating javadoc

Hi guys, I'd like to propose a small change to jaxp/build.xml and jaxp/nbproject/project.xml - in order to allow editing JAXP sources in NetBeans, as well as generating the JAXP javadoc for previewing purposes. I actually stole the javadoc target from jdk/make/netbeans/common/shared.xml The cha

Re: Building on Mac

Hi Peter, Did you 'install the command line tools' in Xcode? The fact that you have to refer to /Applications/Xcode.app/... let me think that perhaps you didn't. Start Xcode, go to preferences, and explore the different panes: there's one that will let you install the command line tools. If

Re: Compiler build Question

I Tamer, I believe you need to define this variable: bootstrap.jdk= in $HOME/.openjdk/build.properties. see make/netbeans/README http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d782143219d6/make/netbeans/README Best regards, -- daniel http://blogs.sun.com/jmxetc tamer abd el-lateef wrote:

Re: forward-port IMPORT_BINARY_PLUGS to OpenJDK7

Hi guys, I could take care of applying the same patch than what I did a few months ago for OpenJDK 6. Namely, if you compile OpenJDK with the binary plugs, the SNMP runtime will be compiled and included in rt.jar. If you compile without the binary plugs, the SNMP runtime will not be included. I

Re: Can somebody sanity-check me here?

Hi Ted, To complete Erick's answer I believe you will find some in-depth explanation on Kelly's blog - and more particularly in these two articles: OpenJDK Mercurial Forest http://blogs.sun.com/kto/entry/openjdk_mercurial_forest and OpenJDK Mercurial Wheel (Integration Wheel of Open Life) http:

Re: mail.openjdk.java.net: no search tool on the mailing archive.

Francis ANDRE wrote: I would like to look for additional informations on building OpenJDK in all archive mails but AFAIK, there is no search tool on the archive page. Hi Francis, Well, there's always the poor man's search: For instance if you're looking for "build on windows" in the build-dev

Re: JDK 7 build 24 is available at the openjdk.java.net website

Ted Neward wrote: The key is in getting the Mercurial with the forest extension installed--I had 0.9.5, which didn't, and I couldn't figure out where to get it or how to install it; I eventually ended up getting the "Batteries Included" installer, and it appeared there. (But only in one of the fo

Re: JDK 7 build 24 is available at the openjdk.java.net website

Ted Neward wrote: Where and how do I install the “forest extension” to Mercurial for a Windows box? (I really want to make the jump ASAP, assuming the repositories are no longer in “test” status…) Hi Ted, This is how I did it on my XP Home PC at home: 1) I Installed Mercurial in c:\Mercurial

jdk7/tl/jdk: Yet another other test

Changeset: 63300458df4a Author:dfuchs Date: 2007-11-28 18:07 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/63300458df4a Yet another other test ! testfile

jdk7/tl/jdk: Removing file used to test Mercurial set-up

Changeset: 4a7493b97806 Author:dfuchs Date: 2007-11-28 15:41 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4a7493b97806 Removing file used to test Mercurial set-up - src/share/classes/com/sun/jmx/remote/util/NewInterface.java

jdk7/tl/jdk: Test Mercurial set-up

Changeset: 8d6e9e2c82cd Author:dfuchs Date: 2007-11-28 14:54 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8d6e9e2c82cd Test Mercurial set-up ! src/share/classes/com/sun/jmx/defaults/package.html + src/share/classes/com/sun/jmx/remote/util/NewInterface.java