Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #37527 > unrolled thread
| Started by | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| First post | 2017-10-03 08:12 -0700 |
| Last post | 2017-10-03 19:23 -0400 |
| Articles | 10 on this page of 30 — 7 participants |
Back to article view | Back to comp.lang.java.programmer
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]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2017-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]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2017-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]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2017-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]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2017-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]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2017-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]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2017-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]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2017-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]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2017-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]
| From | v_borchert@despammed.com (Volker Borchert) |
|---|---|
| Date | 2017-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]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2017-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