OpenJDK: need little help with ObjC

[Sergey Fedorov]

On Tue, Jul 16, 2024 at 10:47 PM Ken Cunningham <
ken.cunningham.webuse at gmail.com> wrote:

> For reference, I threw some extra pool management into glib2 to stop
> messages exactly like that here:
>
>
> https://github.com/macports/macports-ports/blob/master/devel/glib2/files/patch-glib2-findfolders-before-Lion.diff
>
>
> perhaps adding some into openjdk would help. A bit of trial and error
> might be required.
>

Thank you for the reference, I will try that.



>
>
> > On Jul 16, 2024, at 7:44 AM, Ken Cunningham <
> ken.cunningham.webuse at gmail.com> wrote:
> >
> > The usual equivalent older construct is this:
> >
> >
> > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> > {
> >
> > }
> > [pool drain];
> >
> >
> > which (AFAIK) does exactly the same thing as:
> >
> > @autoreleasepool
> > {
> >
> > }
> >
> > but just a little less beautifully.
> >
> > Now the commit you referenced has this older construct still in place.
> But I didn't look at the current source code that you are compiling to see
> what it has.
> >
> > Ken
> >
> > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> > { } [pool drain];
> >> On Jul 16, 2024, at 7:17 AM, Sergey Fedorov <vital.had at gmail.com>
> wrote:
> >>
> >> On Tue, Jul 16, 2024 at 6:19 PM Saagar Jha <saagar at saagarjha.com>
> wrote:
> >> I’m guessing that since the block runs elsewhere there isn’t an
> autoreleasepool for it anymore. You can probably fix this by wrapping the
> call to JavaMain in @autoreleasepool {}?
> >> Saagar Jha
> >>
> >> This syntax is not supported by GCC, we need to use a standard ObjC
> somehow.
> >>
> >>>
> >>> On Jul 10, 2024, at 02:47, Riccardo Mottola via macports-dev <
> macports-dev at lists.macports.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Sergio Had wrote:
> >>>> I have finally built the thing and it works, from looks of things,
> but I get a message on startup:
> >>>> 36-25%
> /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_java_openjdk8/openjdk8/work/jdk8u-jdk8u372-ga/build/openjdk8/images/j2sdk-image/bin/java
> -version
> >>>> 2024-07-09 18:34:10.587 java[13785:1903] *** __NSAutoreleaseNoPool():
> Object 0x5d12e50 of class NSCFDictionary autoreleased with no pool in place
> - just leaking
> >>>> 2024-07-09 18:34:10.590 java[13785:1903] *** __NSAutoreleaseNoPool():
> Object 0x5d13310 of class NSCFData autoreleased with no pool in place -
> just leaking
> >>>> openjdk version "1.8.0_372"
> >>>> OpenJDK Runtime Environment (build
> 1.8.0_372-root_2024_07_09_15_56-b00)
> >>>> OpenJDK Zero VM (build 25.372-b00, interpreted mode)
> >>>>
> >>>> This seems to be related to the code, which upstream has switched to
> block syntax (it does not build with GCC), so I had to use its earlier
> version.
> >>>> From commit message it seems upstream also had this startup issue:
> >>>>
> https://github.com/openjdk/jdk8u/commit/c29d997ca180ba5d812df7745c668cfc906be20b
> >>>
> >>> the message tells you that you are using NS* objects without an
> Autorelease Pool. It will cause issues, but "should work", so your app
> should run.
> >>> I notice what they appear to be CoreFoundation bridge object. You
> should try to track where they come from, maybe put a breakpoint and
> stacktrace.
> >>>
> >>> The snipped seen in the commit looks trivial, no nsblocks needed and
> has an fresh ARP allocated, so I think the issue is elsewhere.
> >>>
> >>> Riccardo
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20240716/cecbbd14/attachment.htm>