Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #12180 (new)

Opened 6 years ago

Last modified 4 years ago

RFE: more robustness in using non-standard Java classes

Reported by: mtbcarroll Owned by:
Priority: minor Milestone: Unscheduled
Component: General Version: 5.0.1
Keywords: n.a. Cc: java@…
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: n.a.

Description

http://lists.openmicroscopy.org.uk/pipermail/ome-users/2014-April/004358.html describes a surprise arising from Blitz's use of sun.misc.Signal and git grep 'import sun' reveals other instances of optimism. Perhaps these imports should be reviewed in case they can be written more defensively, as with the approach taken by ome.util.PixelData.dispose(), or with more reliably present classes.

Change History (14)

comment:1 Changed 6 years ago by jamoore

  • Milestone changed from Unscheduled to 5.0.2
  • Owner jamoore deleted

Happy to have this addressed. A safer way a la ome.util.SignalHandler which uses reflection is fine, but there's no appropriate Java way to do this (across the versions we support).

comment:2 Changed 6 years ago by jamoore

Btw, since we don't currently support gnu classpath, it's a bit arguable if the behaviour from the mailing list is perhaps not the correct one, though failing faster with a nicer message certainly couldn't hurt.

comment:3 Changed 6 years ago by mtbcarroll

If we go down that road, we should replace the mentions in the docs of "Java 1.6 or later" and suchlike with something rather more specific. It's not that we "don't support" GNU classpath so much as we require extra classes that are not part of the Java standard. Oracle themselves are quite clear on this:

A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform ... In general, writing java programs that rely on sun.* is risky: those classes are not portable, and are not supported.

Yes, at the least, failing fast with a helpful message would be an improvement.

comment:4 Changed 6 years ago by jamoore

Yup, know the passage well. And once the standard provides signal handling, we'll abide by it completely :)

comment:5 Changed 6 years ago by mtbcarroll

If it helps then I'm happy for this ticket to be pushed out beyond 5.0 given all what else needs to be done.

comment:6 Changed 6 years ago by jamoore

  • Milestone changed from 5.0.2 to 5.0.3

Pushing a bit, and we can review after the next release.

comment:7 Changed 5 years ago by jamoore

  • Milestone changed from 5.1.0-m4 to 5.1.1

comment:8 Changed 5 years ago by jamoore

  • Milestone changed from 5.1.1 to 5.1.2

Don't see us getting to this in the next 2 weeks.

comment:9 Changed 5 years ago by jamoore

  • Milestone changed from 5.1.2 to 5.1.3

comment:10 Changed 4 years ago by jamoore

  • Milestone changed from 5.1.4 to OMERO-5.1.4

Splitting 5.1.4 due to milestone decoupling

comment:11 Changed 4 years ago by jburel

  • Milestone changed from OMERO-5.1.4 to OMERO-5.2.0

Moving to 5.2 for consideration

comment:12 Changed 4 years ago by jamoore

  • Milestone changed from OMERO-5.2.0 to OMERO-5.2.1

comment:13 Changed 4 years ago by jburel

  • Milestone changed from OMERO-5.2.1 to OMERO-5.2.2

Milestone OMERO-5.2.1 deleted

comment:14 Changed 4 years ago by jburel

  • Milestone changed from OMERO-5.2.2 to OMERO-5.2.1

Milestone OMERO-5.2.2 deleted

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.297066 sec.)

We're Hiring!