Task #12180 (new)
Opened 10 years ago
Last modified 9 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 10 years ago by jamoore
- Milestone changed from Unscheduled to 5.0.2
- Owner jamoore deleted
comment:2 Changed 10 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 10 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 10 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 10 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 10 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 10 years ago by jamoore
- Milestone changed from 5.1.0-m4 to 5.1.1
comment:8 Changed 9 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 9 years ago by jamoore
- Milestone changed from 5.1.2 to 5.1.3
comment:10 Changed 9 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 9 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 9 years ago by jamoore
- Milestone changed from OMERO-5.2.0 to OMERO-5.2.1
comment:13 Changed 9 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 9 years ago by jburel
- Milestone changed from OMERO-5.2.2 to OMERO-5.2.1
Milestone OMERO-5.2.2 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).