Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #34710 > unrolled thread
| Started by | Roedy Green <inquiry@mindprod.com> |
|---|---|
| First post | 2016-06-28 21:34 -0700 |
| Last post | 2016-07-03 20:57 +0000 |
| Articles | 20 on this page of 160 — 12 participants |
Back to article view | Back to comp.lang.java.programmer
missing import java.lang.Comparable Roedy Green <inquiry@mindprod.com> - 2016-06-28 21:34 -0700
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-06-29 05:56 +0000
Re: missing import java.lang.Comparable Roedy Green <inquiry@mindprod.com> - 2016-06-28 23:59 -0700
Re: missing import java.lang.Comparable Matthias Wiehl <mw@kwarg.de> - 2016-06-29 09:52 +0200
Re: missing import java.lang.Comparable Roedy Green <inquiry@mindprod.com> - 2016-06-29 01:16 -0700
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-06-29 06:38 -0700
Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-30 13:24 +0000
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-06-30 06:37 -0700
Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-30 10:19 -0400
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-06-30 07:47 -0700
Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-30 11:17 -0400
Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-30 18:23 +0000
Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-30 15:24 -0400
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-06-30 12:47 -0700
Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-30 16:38 -0400
Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-30 21:09 +0000
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-01 06:45 +0000
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-01 05:03 -0700
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-03 20:46 +0000
Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-01 15:21 -0700
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-03 21:10 +0000
Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-04 16:08 -0700
Program proof Mike Amling <mamling@chaff.us> - 2016-07-05 11:23 -0500
Re: Program proof Andreas Leitgeb <avl@logic.at> - 2016-07-05 18:08 +0000
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-05 17:23 +0000
Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-05 14:28 -0700
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-07 15:22 +0000
Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-07 11:44 -0400
Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-07 12:57 -0400
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-07 18:29 +0000
[OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-07 15:48 -0400
Re: [OT] Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-08 08:01 +0000
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-08 08:25 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-08 06:55 -0700
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-08 10:16 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-08 07:35 -0700
Re: [OT] Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-08 18:07 +0000
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-08 12:54 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-08 16:29 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-08 14:06 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-08 20:11 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-15 11:37 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-15 16:36 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-15 15:49 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-15 22:09 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-16 13:04 +0000
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-18 13:08 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-18 19:56 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-08 20:59 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-09 11:57 +0000
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 09:39 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-09 14:43 +0000
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 11:15 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 09:46 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-09 15:21 +0000
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 11:27 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-15 11:39 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-15 15:38 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-15 15:52 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-15 19:19 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-18 13:10 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 16:26 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-18 13:58 -0700
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-18 16:30 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 20:24 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-19 05:14 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-19 20:22 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-19 10:31 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-19 16:37 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-19 14:44 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-19 21:16 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-19 21:54 +0000
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-19 20:17 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-20 12:01 -0700
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-20 21:28 +0000
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-20 16:14 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-19 20:18 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-19 21:33 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-19 21:56 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-19 23:47 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-22 23:31 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-23 10:24 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-23 21:26 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-23 19:23 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-23 23:08 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 10:44 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 10:44 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-20 16:04 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-20 14:51 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-20 22:57 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-21 11:38 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-21 15:57 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-21 13:45 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-21 21:00 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-22 15:28 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-22 19:34 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-22 23:36 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-23 10:25 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-23 10:58 +0000
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-23 09:32 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-22 23:34 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-23 10:25 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-23 17:04 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 10:46 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-23 21:23 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 10:47 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-22 23:40 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-18 20:02 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 20:26 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-18 20:35 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-18 19:59 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-08 23:36 +0000
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-08 20:09 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-09 12:51 +0000
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-09 09:15 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-09 14:30 +0000
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 09:44 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-09 14:37 +0000
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 11:14 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-09 20:09 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-10 01:11 +0000
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-09 21:52 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-10 10:34 +0000
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-08 21:03 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-08 20:32 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-11 05:30 -0700
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-11 16:26 +0000
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-11 13:56 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-11 10:59 -0700
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-11 15:09 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-11 13:44 -0700
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-11 17:21 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-11 10:56 -0700
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-11 11:49 -0700
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-11 21:00 +0000
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-11 22:30 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-11 22:36 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-12 11:37 -0700
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-12 13:01 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-12 20:31 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-11 22:13 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-08 20:18 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-08 15:14 -0700
Re: [OT] Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-08 17:59 +0000
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-08 14:34 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-08 15:18 -0700
Re: [OT] Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-08 23:50 +0000
Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-07 13:18 -0700
Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-07 16:59 -0400
Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-08 15:05 -0700
Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-08 19:51 -0400
Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-07 17:07 -0400
Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-30 20:44 +0000
Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-07 16:56 -0400
Re: missing import java.lang.Comparable a.laforgia@gmail.com - 2016-06-30 08:32 -0700
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-06-30 08:59 -0700
Re: missing import java.lang.Comparable a.laforgia@gmail.com - 2016-06-30 09:06 -0700
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-06-30 09:35 -0700
Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-06-30 11:18 -0700
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-03 20:57 +0000
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Roedy Green <inquiry@mindprod.com> |
|---|---|
| Date | 2016-06-28 21:34 -0700 |
| Subject | missing import java.lang.Comparable |
| Message-ID | <drj6nb1mja17fads03ucr3v7mi2fcn2d36@4ax.com> |
I just noticed all my programs are missing an import java.lang.Comparable, but they work fine! Presumably IntellliJ IDE has pruned them. It is just an interface. Why are they not required?
[toc] | [next] | [standalone]
| From | Andreas Leitgeb <avl@logic.at> |
|---|---|
| Date | 2016-06-29 05:56 +0000 |
| Message-ID | <slrnnn6op7.456.avl@login.logic.tuwien.ac.at> |
| In reply to | #34710 |
Roedy Green <inquiry@mindprod.com> wrote: > I just noticed all my programs are missing an import > java.lang.Comparable, but they work fine! > > Presumably IntellliJ IDE has pruned them. It is just an interface. > Why are they not required? Because java.lang is implicitly "imported". For same reason you can also use String instead of java.lang.String
[toc] | [prev] | [next] | [standalone]
| From | Roedy Green <inquiry@mindprod.com> |
|---|---|
| Date | 2016-06-28 23:59 -0700 |
| Message-ID | <ads6nbhnkttcdfudcnemafu5gdeul2uq45@4ax.com> |
| In reply to | #34711 |
On Wed, 29 Jun 2016 05:56:55 -0000 (UTC), Andreas Leitgeb <avl@logic.at> wrote: >Because java.lang is implicitly "imported". But you have to import java.lang.System do you not?
[toc] | [prev] | [next] | [standalone]
| From | Matthias Wiehl <mw@kwarg.de> |
|---|---|
| Date | 2016-06-29 09:52 +0200 |
| Message-ID | <86lh1o4eku.fsf@kwarg.de> |
| In reply to | #34712 |
Roedy Green <inquiry@mindprod.com> writes: > Andreas Leitgeb <avl@logic.at> wrote: > >> Because java.lang is implicitly "imported". > > But you have to import java.lang.System do you not? No. All classes in the java.lang package are imported by default. You don't need to import them to use them without fully qualified names.
[toc] | [prev] | [next] | [standalone]
| From | Roedy Green <inquiry@mindprod.com> |
|---|---|
| Date | 2016-06-29 01:16 -0700 |
| Message-ID | <fr07nbtsb5vh74liogda4s77cujk44malj@4ax.com> |
| In reply to | #34713 |
On Wed, 29 Jun 2016 09:52:17 +0200, Matthias Wiehl <mw@kwarg.de> wrote: >All classes in the java.lang package are imported by default. You >don't need to import them to use them without fully qualified names. There is not a single instance of import java.lang in all my code. IntelliJ has been quietly removing them, and I never noticed till now.
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-06-29 06:38 -0700 |
| Message-ID | <5df4ccab-dee6-412f-b6f2-026b69ebf82c@googlegroups.com> |
| In reply to | #34717 |
On Wednesday, June 29, 2016 at 4:16:31 AM UTC-4, Roedy Green wrote: > There is not a single instance of import java.lang in all my code. > IntelliJ has been quietly removing them, and I never noticed till now. I added a line in my code in Eclipse: System.gc(); Eclipse did not add an import and did not mark this as an error. I manually added an import for this java.lang.System and it didn't mark it as an error. I ran a Cleanup and it removed the import.
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-06-30 13:24 +0000 |
| Message-ID | <nl36hi$704$1@dont-email.me> |
| In reply to | #34713 |
On Wed, 29 Jun 2016 19:52:00 +0000, Stefan Ram wrote: > Matthias Wiehl <mw@kwarg.de> writes: >>>But you have to import java.lang.System do you not? >>No. > > »No.« only in the special case that you do not have a »System.class« > file in your directory. > s/you do not have/you have/ $ cp tmp1 > Main.java $ javac.exe $ java.exe example s/example/Main/ -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-06-30 06:37 -0700 |
| Message-ID | <11952827-9dd1-48e7-b835-722a38023ce5@googlegroups.com> |
| In reply to | #34724 |
On Thursday, June 30, 2016 at 9:24:14 AM UTC-4, Martin Gregorie wrote: > > »No.« only in the special case that you do not have a »System.class« > > file in your directory. > > > s/you do not have/you have/ Right, you should need an import statement for anything in java.lang if you use their class names for one of your classes. I have a unique identifier in front of all my class names. I hate when classes have the same name. On the off chance you need to reference 2 of those in the same class you can't use the import, at least one needs to be fully qualified for every reference.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-30 10:19 -0400 |
| Message-ID | <nl39pj$o53$1@dont-email.me> |
| In reply to | #34725 |
On 6/30/2016 9:37 AM, Eric Douglas wrote:
> On Thursday, June 30, 2016 at 9:24:14 AM UTC-4, Martin Gregorie wrote:
>>> »No.« only in the special case that you do not have a »System.class«
>>> file in your directory.
>>>
>> s/you do not have/you have/
>
> Right, you should need an import statement for anything in java.lang if you use their class names for one of your classes.
> I have a unique identifier in front of all my class names.
Isn't that what the package name is for?
> I hate when classes have the same name. [...]
Then you must really hate Java SE's classes ... There are two
interfaces named Action, two classes and an interface named Binding,
a class and three interfaces named Attribute, and a class and *four*
interfaces all named Element. And, of course, many more collisions --
even UNKNOWN is used twice!
Name clashes are unavoidable, absent some kind of central agency
that dispenses unique names the way the Department of Motor Vehicles
dispenses license plates. You can (and should!) try to minimize them,
but you'll never completely eliminate them. That said, I feel that
Stefan's insistence on fully-qualifying "standard" names (while leaving
his own undecorated!) borders on the perverse -- and from the wrong
side of the border ...
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-06-30 07:47 -0700 |
| Message-ID | <00835840-56aa-4ba2-b496-e364a62a38e8@googlegroups.com> |
| In reply to | #34726 |
On Thursday, June 30, 2016 at 10:19:42 AM UTC-4, Eric Sosman wrote: > Then you must really hate Java SE's classes ... There are two > interfaces named Action, two classes and an interface named Binding, > a class and three interfaces named Attribute, and a class and *four* > interfaces all named Element. And, of course, many more collisions -- > even UNKNOWN is used twice! I do, in fact. I already encountered the collision on at least one of their classes, I had to fully qualify. There shouldn't be any reason for 2 Action classes. They should have some sort of difference in meaning they could qualify with a letter or two. There's really no reason other people use the same names. Why java.io.File and com.google.api.services.drive.model.File?? Google could've at least named theirs GFile or DFile (D for Drive), somehow unique it. I put 3 letters in front of all my class names to make them unique. Our in house API is written to work with our Business BASIC software (see www.basis.com) so they all start with BB, then a third letter for type (a for abstract, i for interface, g for GUI object, r for report object, s for static, etc). If you use someone else's name, like File, then anyone who sees a reference to it in your class that is not fully qualified must check the import, and if you need to reference both no one could ever know just by looking at the imports. I think code is more readable if you fully qualify the imports (the .* becomes problematic as well with these name collisions), and name classes something that doesn't sound like a key word and isn't so generic someone else would use the same name.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-30 11:17 -0400 |
| Message-ID | <nl3d72$4qn$1@dont-email.me> |
| In reply to | #34727 |
On 6/30/2016 10:47 AM, Eric Douglas wrote:
> On Thursday, June 30, 2016 at 10:19:42 AM UTC-4, Eric Sosman wrote:
>> Then you must really hate Java SE's classes ... There are two
>> interfaces named Action, two classes and an interface named Binding,
>> a class and three interfaces named Attribute, and a class and *four*
>> interfaces all named Element. And, of course, many more collisions --
>> even UNKNOWN is used twice!
>
> I do, in fact. I already encountered the collision on at least one of their classes, I had to fully qualify. There shouldn't be any reason for 2 Action classes. They should have some sort of difference in meaning they could qualify with a letter or two. There's really no reason other people use the same names. Why java.io.File and com.google.api.services.drive.model.File?? Google could've at least named theirs GFile or DFile (D for Drive), somehow unique it.
>
> I put 3 letters in front of all my class names to make them unique. Our in house API is written to work with our Business BASIC software (see www.basis.com) so they all start with BB, then a third letter for type (a for abstract, i for interface, g for GUI object, r for report object, s for static, etc).
>
> If you use someone else's name, like File, then anyone who sees a reference to it in your class that is not fully qualified must check the import, and if you need to reference both no one could ever know just by looking at the imports. I think code is more readable if you fully qualify the imports (the .* becomes problematic as well with these name collisions), and name classes something that doesn't sound like a key word and isn't so generic someone else would use the same name.
Many, many years ago I knew a guy who took extraordinary steps to
ensure his identifiers were unique. He used a random number generator
to generate and print a thousand or so unintelligible names, and each
time he needed a new name he'd take one from his printout and cross it
off. Result: code that not even he himself could read.
As I wrote earlier, name clashes are potentially confusing but not
completely avoidable -- unless you adopt a procedure something like my
old acquaintance's, and end up with ridiculous code. Your three-letter
prefix -- well, as Java SE stands today there are no public classes or
interfaces whose names begin with BB, so you should be perfectly safe.
Don't incorporate any third-party code from the British Broadcasting
Corporation, though ...
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-06-30 18:23 +0000 |
| Message-ID | <nl3o2f$b28$1@dont-email.me> |
| In reply to | #34728 |
On Thu, 30 Jun 2016 11:17:49 -0400, Eric Sosman wrote: > As I wrote earlier, name clashes are potentially confusing but not > completely avoidable -- unless you adopt a procedure something like my > old acquaintance's, and end up with ridiculous code. Your three-letter > prefix -- well, as Java SE stands today there are no public classes or > interfaces whose names begin with BB, so you should be perfectly safe. > Don't incorporate any third-party code from the British Broadcasting > Corporation, though ... > Not using just the 'BBC' prefix should good enough to avoid clashes with code written inside the beeb. I've worked there and never saw them abbreviate their corporate name to anything less than three letters. Same goes for BBC TV and the World Service. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-30 15:24 -0400 |
| Message-ID | <nl3rm7$r1d$1@dont-email.me> |
| In reply to | #34735 |
On 6/30/2016 2:23 PM, Martin Gregorie wrote:
> On Thu, 30 Jun 2016 11:17:49 -0400, Eric Sosman wrote:
>
>> As I wrote earlier, name clashes are potentially confusing but not
>> completely avoidable -- unless you adopt a procedure something like my
>> old acquaintance's, and end up with ridiculous code. Your three-letter
>> prefix -- well, as Java SE stands today there are no public classes or
>> interfaces whose names begin with BB, so you should be perfectly safe.
>> Don't incorporate any third-party code from the British Broadcasting
>> Corporation, though ...
>>
> Not using just the 'BBC' prefix should good enough to avoid clashes with
> code written inside the beeb. I've worked there and never saw them
> abbreviate their corporate name to anything less than three letters. Same
> goes for BBC TV and the World Service.
Okay, so he can avoid BBC and be safe ... Until his stuff has
to play nicely with something from Batten Barton Durstine & Osborn,
or BlackBerry, or Best Buy, or Bed Bath & Beyond, or Breitburn Energy,
or Branch Banking & Trust, or ...
Java's packages serve (among other things) as namespaces. There's
no reason not to use them as such.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-06-30 12:47 -0700 |
| Message-ID | <8668311a-503f-46b6-909c-dcbfbfc5ce19@googlegroups.com> |
| In reply to | #34736 |
On Thursday, June 30, 2016 at 3:25:06 PM UTC-4, Eric Sosman wrote: > Okay, so he can avoid BBC and be safe ... Until his stuff has > to play nicely with something from Batten Barton Durstine & Osborn, > or BlackBerry, or Best Buy, or Bed Bath & Beyond, or Breitburn Energy, > or Branch Banking & Trust, or ... > > Java's packages serve (among other things) as namespaces. There's > no reason not to use them as such. Possible somewhere else in the world would come up with the same class names, unlikely they would and less likely they'd have to work together. We could come up with entirely unique class names for every class in existence, though it would require a central repository (you register your API, they assign a unique string to put in front of every class name). Using the most simplistic names creates a much higher probability for clashing, and I see no reason to ever clash within the same API. It's bad enough we upload a File to Google and you have to check the import and realize we just declared a Google File, and the client File we're transferring to it is the fully qualified one because it's package name is shorter (java.io.File and com.google.api.services.drive.model.File). Why is javax.swing.event.Changelistener just called ChangeListener, yet javafx.beans.value also includes a ChangeListener? Are we to expect they're exactly the same? (they're not) Is it so hard to call the new one FXChangeListener?
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-30 16:38 -0400 |
| Message-ID | <nl3vvv$as1$1@dont-email.me> |
| In reply to | #34737 |
On 6/30/2016 3:47 PM, Eric Douglas wrote:
> On Thursday, June 30, 2016 at 3:25:06 PM UTC-4, Eric Sosman wrote:
>> Okay, so he can avoid BBC and be safe ... Until his stuff has
>> to play nicely with something from Batten Barton Durstine & Osborn,
>> or BlackBerry, or Best Buy, or Bed Bath & Beyond, or Breitburn Energy,
>> or Branch Banking & Trust, or ...
>>
>> Java's packages serve (among other things) as namespaces. There's
>> no reason not to use them as such.
>
> Possible somewhere else in the world would come up with the same class names, unlikely they would and less likely they'd have to work together.
> We could come up with entirely unique class names for every class in existence, though it would require a central repository (you register your API, they assign a unique string to put in front of every class name).
>
> Using the most simplistic names creates a much higher probability for clashing, and I see no reason to ever clash within the same API. It's bad enough we upload a File to Google and you have to check the import and realize we just declared a Google File, and the client File we're transferring to it is the fully qualified one because it's package name is shorter (java.io.File and com.google.api.services.drive.model.File). Why is javax.swing.event.Changelistener just called ChangeListener, yet javafx.beans.value also includes a ChangeListener? Are we to expect they're exactly the same? (they're not) Is it so hard to call the new one FXChangeListener?
Yes, it is so hard. What's easy is to point at one pair of names,
complain that they shouldn't clash, file a bug report, and persuade the
originator to change one. (Fixing the follow-on damage to all the code
that used the old name still counts as "easy" compared to the rest.)
What's hard is scaling that one-at-a-time process. How many people
write Java, and for how many different organizations? How many public
identifiers do they require for their work? Resolving the inevitable
collisions would be an O(N*N) task, for some not inconsiderable N.
And keeping it resolved as new names are constantly being invented
would be another O(N*N) task, for an ever-increasing N.
Ah, but you're only concerned about names in quote the same API
end quote. Observe, though, that API's merge and blend all the time:
IBM's WebSphere began as (no insult intended) an agglomeration of code
from numerous sources, some within IBM, some from companies acquired
by IBM. You're developing an API for Limits Ltd., so you needn't fret
about name collisions with the products of Universal Unlimited, right?
Except that tomorrow IBM will buy both firms and announce plans to
roll out a magnificent new API incorporating both firms' stuff ...
Name collisions are unfortunate because they are potentially
confusing, granted. For that reason you should hesitate to create
collisions. But there is *no* practical strategy that will avoid
them altogether, so you *must* accept that some will crop up. Java
has packages to resolve collisions among package-level names, and a
recommended practice for avoiding collisions between package names
(it's not perfect, but it seems to be working pretty well). I see
little reason to resort to a sort of Microsoftened naming convention
in a futile attempt to do without packages.
That's my story, and I'm sticking to it.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-06-30 21:09 +0000 |
| Message-ID | <nl41pc$apo$2@dont-email.me> |
| In reply to | #34737 |
On Thu, 30 Jun 2016 12:47:15 -0700, Eric Douglas wrote: > Using the most simplistic names creates a much higher probability for > clashing, and I see no reason to ever clash within the same API. > Agreed, but I think its also reasonable to avoid ever using class names that appear in the Java standard class library. > Its bad enough we upload a File to Google and you have to check > the import and realize we just declared a Google File, and the client > File we're transferring to it is the fully qualified one because it's > package name is shorter (java.io.File and > com.google.api.services.drive.model.File). > IMO Google should have done due diligence over checking for and avoiding name clashes with the standard library. The only place where a clashing class name is OK is where the purpose and functionality of the class means that it would never, ever be used in the same source file as the standard library class with the same name. > Why is javax.swing.event.Changelistener just called ChangeListener, yet > javafx.beans.value also includes a ChangeListener? Are we to expect > they're exactly the same? (they're not) Is it so hard to call the new > one FXChangeListener? > Would you ever use Swing in a Javafx bean? If not, then there's no real harm in the name clash. Its much the same with java.util.Date and java.sql.Date: in practise its unlikely that you'd need to use both within the same source file. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Andreas Leitgeb <avl@logic.at> |
|---|---|
| Date | 2016-07-01 06:45 +0000 |
| Message-ID | <slrnnnc4cm.456.avl@login.logic.tuwien.ac.at> |
| In reply to | #34740 |
Martin Gregorie <martin@address-in-sig.invalid> wrote:
> Its much the same with java.util.Date and java.sql.Date: in practise its
> unlikely that you'd need to use both within the same source file.
Happened to me: I have a method that has to accept java.util.Date,
and the enclosing class does database stuff. Another one that's
not too unlikely to happen is java.awt.List versus java.util.List.
Imho, Java lacks a feature that would allow one do assign local
aliases for fully qualified class names. something like:
import java.awt.List as AwtList;
I seem to remember that other languages with hierarchical
namespaces do have such a feature.
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-07-01 05:03 -0700 |
| Message-ID | <bd1cf8ba-c490-4507-a94f-341a4acd2446@googlegroups.com> |
| In reply to | #34742 |
On Friday, July 1, 2016 at 2:45:52 AM UTC-4, Andreas Leitgeb wrote: > import java.awt.List as AwtList; That would be a possible workaround to be able to mention every class used in the imports but would seem extra confusing on the variable declares. We don't want to look like C language with the #define.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Leitgeb <avl@logic.at> |
|---|---|
| Date | 2016-07-03 20:46 +0000 |
| Message-ID | <slrnnniuce.456.avl@login.logic.tuwien.ac.at> |
| In reply to | #34743 |
Eric Douglas <e.d.programmer@gmail.com> wrote: > On Friday, July 1, 2016 at 2:45:52 AM UTC-4, Andreas Leitgeb wrote: >> import java.awt.List as AwtList; > That would be a possible workaround to be able to mention every class used > in the imports > but would seem extra confusing on the variable declares. Without any calibration of your scale of "confusingness", such a statement doesn't carry much weight. By what criteria could it be e.g. "more confusing" to import a class to a new name, than other already possible things like naming one's own classes confusingly, or importing a class whose bare name also exists in the same package (as the class with the import statement under discussion). > We don't want to look like C language with the #define. If closeness to C language were a criterion of confusingness, then Java might quite not be your favourite language... C's #define is of course ways more powerful and thus with a much higher potential for being misused(*) confusingly, than an import alias, so the comparison might be considered somewhat humble. (*): #define while if
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2016-07-01 15:21 -0700 |
| Message-ID | <e66db7c3-40cd-4df2-9e0e-9f23b0cb680c@googlegroups.com> |
| In reply to | #34742 |
On Thursday, June 30, 2016 at 11:45:52 PM UTC-7, Andreas Leitgeb wrote: > Martin Gregorie <martin@address-in-sig.invalid> wrote: > > Its much the same with java.util.Date and java.sql.Date: in practise its > > unlikely that you'd need to use both within the same source file. > > Happened to me: I have a method that has to accept java.util.Date, > and the enclosing class does database stuff. Another one that's > not too unlikely to happen is java.awt.List versus java.util.List. > > Imho, Java lacks a feature that would allow one do assign local > aliases for fully qualified class names. something like: > import java.awt.List as AwtList; > > I seem to remember that other languages with hierarchical > namespaces do have such a feature. Or you could just use the FQN for one of the conflicting types. Whatever is the big effing deal about that? -- Lew
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web