Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #37527 > unrolled thread

Java 9 issues

Started byEric Douglas <e.d.programmer@gmail.com>
First post2017-10-03 08:12 -0700
Last post2017-10-03 19:23 -0400
Articles 10 on this page of 30 — 7 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  Java 9 issues Eric Douglas <e.d.programmer@gmail.com> - 2017-10-03 08:12 -0700
    Re: Java 9 issues Arne Vajhøj <arne@vajhoej.dk> - 2017-10-03 11:33 -0400
    Re: Java 9 issues Patrick Roemer <sangamon@netcologne.de> - 2017-10-03 17:43 +0200
      Re: Java 9 issues Arne Vajhøj <arne@vajhoej.dk> - 2017-10-03 12:07 -0400
        Re: Java 9 issues Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2017-10-03 11:20 -0500
        Re: Java 9 issues Eric Douglas <e.d.programmer@gmail.com> - 2017-10-03 10:19 -0700
          Re: Java 9 issues Arne Vajhøj <arne@vajhoej.dk> - 2017-10-03 14:10 -0400
            Re: Java 9 issues Patrick Roemer <sangamon@netcologne.de> - 2017-10-03 20:20 +0200
              Re: Java 9 issues Arne Vajhøj <arne@vajhoej.dk> - 2017-10-03 15:37 -0400
                Re: Java 9 issues Eric Douglas <e.d.programmer@gmail.com> - 2017-10-03 12:52 -0700
                  Re: Java 9 issues Patrick Roemer <sangamon@netcologne.de> - 2017-10-03 22:27 +0200
                    Re: Java 9 issues Eric Douglas <e.d.programmer@gmail.com> - 2017-10-03 13:38 -0700
                      Re: Java 9 issues Patrick Roemer <sangamon@netcologne.de> - 2017-10-03 22:55 +0200
                      Re: Java 9 issues Arne Vajhøj <arne@vajhoej.dk> - 2017-10-03 19:45 -0400
                        Re: Java 9 issues Eric Douglas <e.d.programmer@gmail.com> - 2017-10-04 05:18 -0700
                          Re: Java 9 issues Arne Vajhøj <arne@vajhoej.dk> - 2017-10-04 20:04 -0400
                            Re: Java 9 issues Eric Douglas <e.d.programmer@gmail.com> - 2017-10-05 06:10 -0700
                          Re: Java 9 issues Martin Gregorie <martin@address-in-sig.invalid> - 2017-10-05 11:06 +0000
                            Re: Java 9 issues Eric Douglas <e.d.programmer@gmail.com> - 2017-10-05 06:09 -0700
                              Re: Java 9 issues Martin Gregorie <martin@address-in-sig.invalid> - 2017-10-05 18:23 +0000
            Re: Java 9 issues Eric Douglas <e.d.programmer@gmail.com> - 2017-10-03 12:03 -0700
    Re: Java 9 issues Eric Douglas <e.d.programmer@gmail.com> - 2017-10-03 13:34 -0700
      Re: Java 9 issues Eric Douglas <e.d.programmer@gmail.com> - 2017-10-03 13:49 -0700
        Re: Java 9 issues Arne Vajhøj <arne@vajhoej.dk> - 2017-10-03 19:39 -0400
      Re: Java 9 issues Eric Douglas <e.d.programmer@gmail.com> - 2017-10-03 14:01 -0700
      Re: Java 9 issues Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-10-03 17:36 -0400
        Re: Java 9 issues Eric Douglas <e.d.programmer@gmail.com> - 2017-10-04 07:51 -0700
          Re: Java 9 issues Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-10-04 11:20 -0400
            Re: Java 9 issues v_borchert@despammed.com (Volker Borchert) - 2017-10-04 20:14 +0000
      Re: Java 9 issues Arne Vajhøj <arne@vajhoej.dk> - 2017-10-03 19:23 -0400

Page 2 of 2 — ← Prev page 1 [2]


#37536

FromEric Douglas <e.d.programmer@gmail.com>
Date2017-10-03 12:03 -0700
Message-ID<50202f7a-b621-4e73-b420-cd97dacecacd@googlegroups.com>
In reply to#37534
On Tuesday, October 3, 2017 at 2:10:30 PM UTC-4, Arne Vajhøj wrote:
> On 10/3/2017 1:19 PM, Eric Douglas wrote:
> > On Tuesday, October 3, 2017 at 12:08:08 PM UTC-4, Arne Vajhøj wrote:
> >> https://bugs.openjdk.java.net/browse/JDK-8154860
> >>
> >> says "Resolved In Build: b124".
> >>
> >> But when looking at:
> >>
> >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/25066225d892
> >>
> >> the fix seems to have been to change:
> >>
> >>             rs.onRegistration(registry, category);
> >>
> >> to:
> >>
> >>              try {
> >>                  rs.onRegistration(registry, category);
> >>              } catch (Throwable t) {
> >>                  System.err.println("Caught and handled this exception");
> >>                  t.printStackTrace();
> >>              }
> >>
> >> WTF????
> > 
> > Exactly.  All I saw in Patrick's link was this 'fix' that prints
> > stack traces.  Can I get a jar that gets rid of the error and the
> > messages?
> 
> OpenJDK : edit, compiler, update jar
> 
> Oracle JDK : submit a new bug report (you could get in license problems
>               by modifying rt.jar I believe)
> 
> Arne

So wait what no I'm confused.
jai core is in the jdk now?  Does this just work now, we don't need a separate jar?  I had an old jai-imageio-core-standalone-1.2-pre-dr-b04-2013-04-23.jar in my classpath, found one called jai-imageio-core-1.3.1.jar which seems to be the newest version of that, took them out and my images still render with no log messages.

[toc] | [prev] | [next] | [standalone]


#37540

FromEric Douglas <e.d.programmer@gmail.com>
Date2017-10-03 13:34 -0700
Message-ID<fa039415-999b-4a40-9943-422a3ee2495b@googlegroups.com>
In reply to#37527
On Tuesday, October 3, 2017 at 11:12:18 AM UTC-4, Eric Douglas wrote:
> Then there's the next trivial issue of all the now deprecated methods I'm referencing.
> JTextComponent.viewToModel(Point)
JTextComponent.viewToModel2D(Point)

> JTextComponent.modelToView(Point)
JTextComponent.modelToView2D(Point).getBounds()

> InputEvent.CTRL_MASK
InputEvent.CTRL_DOWN_MASK

> Class.newInstance()
Class.getDeclaredConstructor(myClass).newInstance()

> InputEvent.getModifiers()
InputEvent.getModifiersEx()

> new Float(float)
Float.valueOf(float)

> new Integer(int)
Integer.valueOf(int)

> new Double(double)
Double.valueOf(double)

> new Long(long)
Long.valueOf(long)

> new Boolean(String)
Boolean.valueOf(String)

> Object.finalize()
*** this is the tricky one ***

> BigDecimal.ROUND_HALF_UP
RoundingMode.HALF_UP

> BigDecimal.setScale(int,int)
(this warning was triggered by the HELF_UP parameter and simply went away)

> 

* Apparently Exactly the Same (functionality) As

So, what to do with finalize()??  Oracle's comment block on this one simply says it's deprecated, as in the don't know how to properly execute it and just want to do away with it.  In this case I have a file watcher class, using java.nio.file.WatchService in a daemon thread, and want to close it properly..

[toc] | [prev] | [next] | [standalone]


#37542

FromEric Douglas <e.d.programmer@gmail.com>
Date2017-10-03 13:49 -0700
Message-ID<24cf9bd2-774f-4a12-8f97-7952496c2861@googlegroups.com>
In reply to#37540
On Tuesday, October 3, 2017 at 4:34:28 PM UTC-4, Eric Douglas wrote:
> > Then there's the next trivial issue of all the now deprecated methods I'm referencing.
> > JTextComponent.viewToModel(Point)
> JTextComponent.viewToModel2D(Point)
> 
> > JTextComponent.modelToView(Point)
> JTextComponent.modelToView2D(Point).getBounds()
> 

All the methods I had to change work in both 8 and 9 except these 2D, not in 8, so once you go 9 you can't go back.

[toc] | [prev] | [next] | [standalone]


#37549

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-10-03 19:39 -0400
Message-ID<or173t$1vai$1@gioia.aioe.org>
In reply to#37542
On 10/3/2017 4:49 PM, Eric Douglas wrote:
> On Tuesday, October 3, 2017 at 4:34:28 PM UTC-4, Eric Douglas wrote:
>>> Then there's the next trivial issue of all the now deprecated methods I'm referencing.
>>> JTextComponent.viewToModel(Point)
>> JTextComponent.viewToModel2D(Point)
>>
>>> JTextComponent.modelToView(Point)
>> JTextComponent.modelToView2D(Point).getBounds()
> 
> All the methods I had to change work in both 8 and 9 except these 2D,
> not in 8, so once you go 9 you can't go back.
Yes.

But it is not unusual that code for Java version N+1 does not work
on Java version N.

There are several approaches:

A) Drop support for Java 8: fix the code and just build.
B) Support Java 8 and postpone problem: keep the code, build
    with --release 8 and switch to #A when Java 8 support is dropped.
C) Support Java 8, fix problem and increase size of code base: have
    two source files - one for Java 8 and one for Java 9, do separate
    builds for Java 8 and Java 9 and when Java 8 support is dropped
    just remove the Java 8 stuff.

Arne


[toc] | [prev] | [next] | [standalone]


#37545

FromEric Douglas <e.d.programmer@gmail.com>
Date2017-10-03 14:01 -0700
Message-ID<72877719-94cc-438f-8fcc-f0862f0c474c@googlegroups.com>
In reply to#37540
On Tuesday, October 3, 2017 at 4:34:28 PM UTC-4, Eric Douglas wrote:
> > InputEvent.getModifiers()
> InputEvent.getModifiersEx()
> 

Oops this doesn't work.  It compiles, but I'm trying to create a new MouseEvent to pass a mouse event from one control (JTable) to an embedded control (JTree).  If I just switch to the Ex it doesn't process.  What else do I need?

    @Deprecated(since = "9")
    public int getModifiers() {
        return modifiers & (JDK_1_3_MODIFIERS | HIGH_MODIFIERS);
    }
    public int getModifiersEx() {
        return modifiers & ~JDK_1_3_MODIFIERS;
    }

[toc] | [prev] | [next] | [standalone]


#37546

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2017-10-03 17:36 -0400
Message-ID<or0vtk$bcn$1@dont-email.me>
In reply to#37540
On 10/3/2017 4:34 PM, Eric Douglas wrote:
> On Tuesday, October 3, 2017 at 11:12:18 AM UTC-4, Eric Douglas wrote:
>> Then there's the next trivial issue of all the now deprecated methods I'm referencing.
>> [...]
>> Object.finalize()
> *** this is the tricky one ***
> 
> So, what to do with finalize()??  Oracle's comment block on this one simply says it's deprecated, as in the don't know how to properly execute it and just want to do away with it.  In this case I have a file watcher class, using java.nio.file.WatchService in a daemon thread, and want to close it properly..

     It seems you may have been abusing finalize() as a destructor.  That
is and always has been bad practice.  Quoth Bloch in "Effective Java:"

	Item 6: Avoid finalizers
	[...] C++ programmers are cautioned not to think of
	finalizers as the analog of C++ destructors. [...]
	So what should you do instead of writing a finalizer
	for a class whose objects encapsulate resources that
	require termination, such as files or threads? Just
	provide an explicit termination method, and require
	clients of the class to invoke this method on each
	instance when it is no longer needed. [...]

     Don't try to resuscitate bad practice; reform it.

-- 
esosman@comcast-dot-net.invalid
Twelve hundred five days to go.

[toc] | [prev] | [next] | [standalone]


#37554

FromEric Douglas <e.d.programmer@gmail.com>
Date2017-10-04 07:51 -0700
Message-ID<fa3d490a-9119-48b4-92f8-048ac7107be3@googlegroups.com>
In reply to#37546
On Tuesday, October 3, 2017 at 5:37:00 PM UTC-4, Eric Sosman wrote:
> 
>      It seems you may have been abusing finalize() as a destructor.  That
> is and always has been bad practice.  Quoth Bloch in "Effective Java:"

I do have a proper terminate method which is supposed to be calling before destroying the instance.  I was just hoping it was possible to implement a failsafe to close a resource instance such as this watcher service or a socket listener which is supposed to remain open for the life of the object.

[toc] | [prev] | [next] | [standalone]


#37555

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2017-10-04 11:20 -0400
Message-ID<or2u83$jk2$1@dont-email.me>
In reply to#37554
On 10/4/2017 10:51 AM, Eric Douglas wrote:
> On Tuesday, October 3, 2017 at 5:37:00 PM UTC-4, Eric Sosman wrote:
>>
>>       It seems you may have been abusing finalize() as a destructor.  That
>> is and always has been bad practice.  Quoth Bloch in "Effective Java:"
> 
> I do have a proper terminate method which is supposed to be calling before destroying the instance.  I was just hoping it was possible to implement a failsafe to close a resource instance such as this watcher service or a socket listener which is supposed to remain open for the life of the object.

     Ah!  Okay, that's reasonable -- finalize() as a fail-safe,
rather than as a destructor substitute.

     If you still want the fail-safe, I can think of two likely
approaches:

     - Keep on using finalize() as you have been, and ignore
       the deprecation warnings.

     - (Haven't tried this myself): Ditch finalize(), create a
       Reference to your object, and register the Reference with
       a ReferenceQueue. When the queue notifies you that the
       object is no longer reachable, you can then check that
       it's been properly closed.

-- 
esosman@comcast-dot-net.invalid
Twelve hundred four days to go.

[toc] | [prev] | [next] | [standalone]


#37557

Fromv_borchert@despammed.com (Volker Borchert)
Date2017-10-04 20:14 +0000
Message-ID<or3fes$7qn$1@Gaia.teknon.de>
In reply to#37555
Eric Sosman wrote:

>      - (Haven't tried this myself): Ditch finalize(), create a
>        Reference to your object, and register the Reference with
>        a ReferenceQueue. When the queue notifies you that the
>        object is no longer reachable, you can then check that
>        it's been properly closed.

PhantomReference would be the flavor of choice.

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

[toc] | [prev] | [next] | [standalone]


#37547

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-10-03 19:23 -0400
Message-ID<or165g$1u70$1@gioia.aioe.org>
In reply to#37540
On 10/3/2017 4:34 PM, Eric Douglas wrote:
> On Tuesday, October 3, 2017 at 11:12:18 AM UTC-4, Eric Douglas wrote:
>> Object.finalize()
> *** this is the tricky one ***

> So, what to do with finalize()?? Oracle's comment block on this one
 > simply says it's deprecated, as in the don't know how to properly
 > execute it and just want to do away with it. In this case I have a
 > file watcher class, using java.nio.file.WatchService in a daemon
 > thread, and want to close it properly..

Add a close/stop/dispose/halt/terminate method to that class and
let that do teh stuff and call that method explicit.

Arne



[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer


csiph-web