Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #8765 > unrolled thread
| Started by | Roedy Green <see_website@mindprod.com.invalid> |
|---|---|
| First post | 2011-10-13 10:44 -0700 |
| Last post | 2011-10-16 22:14 -0400 |
| Articles | 15 on this page of 75 — 14 participants |
Back to article view | Back to comp.lang.java.programmer
Ubunto Roedy Green <see_website@mindprod.com.invalid> - 2011-10-13 10:44 -0700
Re: Ubunto Robert Klemme <shortcutter@googlemail.com> - 2011-10-13 22:27 +0200
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-14 01:08 +0000
Re: Ubunto Tom Anderson <twic@urchin.earth.li> - 2011-10-14 14:21 +0100
Re: Ubunto B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> - 2011-10-14 17:00 -0400
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-14 22:20 +0000
Re: Ubunto B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> - 2011-10-15 01:16 -0400
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-15 12:21 +0000
Re: Ubunto B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> - 2011-10-15 15:42 -0400
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-16 00:23 +0000
Re: Ubuntu Roedy Green <see_website@mindprod.com.invalid> - 2011-10-15 13:01 -0700
Re: Ubuntu Arne Vajhøj <arne@vajhoej.dk> - 2011-10-15 16:49 -0400
Re: Ubuntu Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-16 00:57 +0000
Re: Ubuntu Tom Anderson <twic@urchin.earth.li> - 2011-10-17 00:51 +0100
Re: Ubuntu Arne Vajhøj <arne@vajhoej.dk> - 2011-10-16 22:12 -0400
Re: Ubuntu Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-17 21:21 +0000
Re: Ubuntu blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-18 14:50 +0000
Re: Ubuntu Lew <lewbloch@gmail.com> - 2011-10-18 08:59 -0700
Re: Ubuntu Robert Klemme <shortcutter@googlemail.com> - 2011-10-18 18:19 +0200
Re: Ubuntu blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-18 17:43 +0000
Re: Ubuntu Robert Klemme <shortcutter@googlemail.com> - 2011-10-18 22:18 +0200
Re: Ubuntu blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-19 13:26 +0000
Re: Ubuntu Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-19 00:18 +0000
Re: Ubuntu blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-19 13:27 +0000
Re: Ubuntu Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-19 19:39 +0000
Re: Ubuntu blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-20 14:15 +0000
Re: Ubuntu David Lamb <dalamb@cs.queensu.ca> - 2011-10-20 12:24 -0400
Re: Ubuntu Tom Anderson <twic@urchin.earth.li> - 2011-10-20 20:53 +0100
Re: Ubuntu blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-21 16:24 +0000
Re: Ubuntu Tom Anderson <twic@urchin.earth.li> - 2011-10-22 20:38 +0100
Re: Ubuntu blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-25 07:03 +0000
Re: Ubuntu Eight of Seventeen <eights17@gmail.com> - 2011-10-25 23:23 -0700
Re: Ubuntu blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-21 16:24 +0000
Java 7 javadocs (was Re: Ubuntu) blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-20 14:16 +0000
Re: Java 7 javadocs (was Re: Ubuntu) David Lamb <dalamb@cs.queensu.ca> - 2011-10-20 12:27 -0400
Re: Java 7 javadocs (was Re: Ubuntu) Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 15:44 -0500
Re: Ubuntu Tom Anderson <twic@urchin.earth.li> - 2011-10-20 20:53 +0100
Re: Ubuntu Eight of Seventeen <eights17@gmail.com> - 2011-10-20 17:05 -0700
Re: Ubuntu Tom Anderson <twic@urchin.earth.li> - 2011-10-17 00:32 +0100
Re: Ubunto Tom Anderson <twic@urchin.earth.li> - 2011-10-15 15:06 +0100
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-15 15:59 +0000
Re: Ubunto Tom Anderson <twic@urchin.earth.li> - 2011-10-15 17:15 +0100
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-15 16:48 +0000
Re: Ubunto B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> - 2011-10-15 15:45 -0400
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-16 00:17 +0000
Re: Ubunto Tom Anderson <twic@urchin.earth.li> - 2011-10-16 23:40 +0100
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-16 23:50 +0000
Re: Ubunto B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> - 2011-10-15 15:46 -0400
Re: Ubunto Tom Anderson <twic@urchin.earth.li> - 2011-10-16 23:44 +0100
Re: Ubunto B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> - 2011-10-16 20:41 -0400
Re: Ubunto Lew <lewbloch@gmail.com> - 2011-10-16 17:48 -0700
Re: Ubunto B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> - 2011-10-16 20:59 -0400
Re: Ubunto Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-16 11:39 +0300
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-16 11:22 +0000
Re: Ubunto Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-10-16 10:58 -0300
Re: Ubunto Dancing Fingers <batymahn@gmail.com> - 2011-10-21 01:51 -0700
Re: Ubunto Arne Vajhøj <arne@vajhoej.dk> - 2011-10-13 22:54 -0400
Re: Ubunto Tom Anderson <twic@urchin.earth.li> - 2011-10-14 14:20 +0100
Re: Ubunto Roedy Green <see_website@mindprod.com.invalid> - 2011-10-15 13:04 -0700
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-16 01:03 +0000
Re: Ubunto Tom Anderson <twic@urchin.earth.li> - 2011-10-17 00:31 +0100
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-17 00:29 +0000
Re: Ubunto Arne Vajhøj <arne@vajhoej.dk> - 2011-10-16 22:03 -0400
Re: Ubunto Tom Anderson <twic@urchin.earth.li> - 2011-10-17 15:08 +0100
Re: Ubunto Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 15:49 -0500
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-17 21:29 +0000
Re: Ubunto Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 15:47 -0500
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-06 22:49 +0000
Re: Ubunto Lew <lewbloch@gmail.com> - 2011-11-06 17:13 -0800
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-07 23:49 +0000
Re: Ubunto markspace <-@.> - 2011-11-07 21:07 -0800
Re: Ubunto Tom Anderson <twic@urchin.earth.li> - 2011-10-17 16:47 +0100
Re: Ubunto B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> - 2011-10-16 20:55 -0400
Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-17 21:37 +0000
Re: Ubunto Arne Vajhøj <arne@vajhoej.dk> - 2011-10-16 22:14 -0400
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Tom Anderson <twic@urchin.earth.li> |
|---|---|
| Date | 2011-10-17 00:31 +0100 |
| Message-ID | <alpine.DEB.2.00.1110162344190.27716@urchin.earth.li> |
| In reply to | #8843 |
On Sun, 16 Oct 2011, Martin Gregorie wrote: > On Sat, 15 Oct 2011 13:04:16 -0700, Roedy Green wrote: > >> On Fri, 14 Oct 2011 14:20:40 +0100, Tom Anderson <twic@urchin.earth.li> >> wrote, quoted or indirectly quoted someone who said : >> >>> That Fedora is much better. >> >> In there anything you would want to tell programmers thinking of >> developing Java on Fedora? >> http://mindprod.com/jgloss/redhat.html is an entry a bit long in the >> tooth. Just a bit! > It just works. That is just about true, but i think it's glossing over some facts worth knowing. I would identify the following points: 0. You should read: http://fedoraproject.org/wiki/Java > Out of the box the RedHat distros (RHEL - RedHat Enterprise Linux - and > Fedora) use OpenJava, 1. The default Java is OpenJava. I *think* a standard install does not include it, but it's easy enough to install. There is one package for the JRE (ie the 'java' program and supporting cast), called java-1.6.0-openjdk, and one for the rest of the JDK (ie the 'javac' program and supporting cast), called java-1.6.0-openjdk-devel. The javadoc is in a third package, java-1.6.0-openjdk-javadoc. 2. None of the above includes Derby, which is included in the Sun releases. That's a package simply called derby. > though you can easily switch to Oracle/Sun Java by simply downloading > and installing it 5. This can be obtained in the usual place, and is an RPM file (there is also a 'compressed binary' - ignore that). There is an important aside here for those not familiar with package management in Red Hat (or Linux generally). There are two distinct layers to package management. The lower layer is RPM - RPM files and the 'rpm' command, which is all about taking RPM files (which are bundles of files, like a fancy ZIP file) and unpacking them into the filesystem. If you give RPM a file for a package, it will do the unpacking, then remember that it did it, so it can delete the package, replace it with a new version, etc. The upper layer is YUM - repositories and the 'yum' command, which is all about dependencies and downloads. If you give YUM a package name, it will find and download the RPM for it, and also work out all the packages it depends on, and find download RPMs for those too, if necessary. It will then transactionally install all of them (or rather, ask RPM to do so). It will also know to check for updates to these packages. The upshot of this is that if you install something from an RPM, then all you get is the installation. It is up to you to obtain the installer, install dependencies, install updates when they are released, and so on. Whereas if you install from YUM, the machine does all that for you. The critical bit there is updates: if a new bugfix release of a package is pushed out, an install from RPM does nothing at all, whereas an install from YUM will upgrade to it as a matter of routine. (I feel so sorry for users of operating systems where this is not the norm, such as Windows and most of OS X; Unix users get this wonderful up-to-dateness as standard) And so: 6. OpenJDK is a YUM install and the Sun JDK is an RPM install. So, choosing Sun over OpenJDK means giving up painless automatic updates. > and changing the default search path ($PATH) so that compilers, etc are > preferentially loaded from there rather than from OpenJava. Whilst you can do this: 7. The right way to manage multiple installations of Java is through the standard 'alternatives' mechanism. See: http://fedoraproject.org/wiki/Packaging:Alternatives http://fedoraproject.org/wiki/Java#Java_Runtime_Environments_.28JRE.29 http://wiki.yyovkov.net/solutions:java:sunjavaonfedora 8. Being the 'default' Java means, amongst other things, that OpenJDK is a dependency of any package which uses Java. Hence, even if you install the Sun JDK, using YUM to install such a package will drag in OpenJDK - even though it won't actually be used! It's possible this won't happen if you have correctly used the alternatives mechanism, as above, but i can't guarantee it. Oh, and: 9. I don't think any standard installation process sets the JAVA_HOME environment variable, so add an export for that to your .bashrc (and make sure your .bash_profile sources your .bashrc - or do something different if you prefer). This is not required, but i often come across bits of software (like JBoss) which either assume or are greatly comforted by its presence. 10. There are loads of Java libraries in the package repositories, all just a few effortless keystrokes away. However! I'm not sure i really recommend getting libraries this way. Although YUM makes getting libraries easy, it doesn't help you distribute code written against the libraries - unless your consumers are also running Fedora, you are going to have to take care of packaging the dependencies yourself. If you instead use something like Ivy to get your jars, you can somewhat reasonably just distribute your ivy.xml file, or if not, use Ivy to build a zip-of-jars to distribute. 11. There are quite a few Java applications in the package repositories, and these don't have the distribution problem of the libraries. I installed Ant, Ivy, and Groovy this way. I once installed IntelliJ IDEA (community edition) this way (modulo some manual bodging of broken dependencies). I once installed Eclipse this way, but that turned out to be a terrible idea, because it couldn't update itself (or install plugins, i think) without being run as root. Essentially, its own package management fought with YUM. Bad. (getting increasingly random ...) 12. If you use Eclipse and eGit, and do access control by client key, and your key has a passphrase, and you generate or passphrase-protect this key on your shiny new Fedora box, then you will hit a bug where eGit's internal version of SSH cannot understand the key (it only understands 3DES-encrypted keys; the current OpenSSH uses AES). You need to set the GIT_SSH environment variable to point to your ssh binary, ie to /usr/bin/ssh, to override the internal version. This is not really a Fedora-specific problem. I'll stop now. tom -- Well, traditionally they are the main constituent of boobs. -- Andrzej Rosa, on why lipids are popular
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2011-10-17 00:29 +0000 |
| Message-ID | <j7fssv$19j$2@localhost.localdomain> |
| In reply to | #8877 |
On Mon, 17 Oct 2011 00:31:05 +0100, Tom Anderson wrote:
> On Sun, 16 Oct 2011, Martin Gregorie wrote:
>
>> On Sat, 15 Oct 2011 13:04:16 -0700, Roedy Green wrote:
>>
>>> On Fri, 14 Oct 2011 14:20:40 +0100, Tom Anderson
>>> <twic@urchin.earth.li>
>>> wrote, quoted or indirectly quoted someone who said :
>>>
>>>> That Fedora is much better.
>>>
>>> In there anything you would want to tell programmers thinking of
>>> developing Java on Fedora?
>>> http://mindprod.com/jgloss/redhat.html is an entry a bit long in the
>>> tooth.
>
> Just a bit!
>
>> It just works.
>
> That is just about true, but i think it's glossing over some facts worth
> knowing.
>
Sure. Short Answer!
> 1. The default Java is OpenJava. I *think* a standard install does not
> include it,
>
That's most likely true, but I haven't manged to do an install that
didn't include it because there at least package I've needed has it as a
dependency - and remember at package selection time (I don't delay this
until post-install) there's as yet no way to pull in Sun/Oracle Java.
> 2. None of the above includes Derby, which is included in the Sun
> releases. That's a package simply called derby.
>
True. Due to a PostgreSQL fixation I keep meaning to use it but haven't
yet.
>> though you can easily switch to Oracle/Sun Java by simply downloading
>> and installing it
>
However, by that time OpenJava is already installed. So far I haven't
been brave enough to uninstall it after I've installed the Sun/Oracle JDK.
Have you tried this?
> The upshot of this is that if you install something from an RPM, then
> all you get is the installation. It is up to you to obtain the
> installer, install dependencies, install updates when they are released,
> and so on. Whereas if you install from YUM, the machine does all that
> for you.
>
Not entirely true because you can add repositories to the Yum
configuration: I normally add rpmfusion and atrpms and current releases
of GoogleMaps add their repository as well.
> whereas
> an install from YUM will upgrade to it as a matter of routine. (I feel
> so sorry for users of operating systems where this is not the norm, such
> as Windows and most of OS X; Unix users get this wonderful
> up-to-dateness as standard)
>
Agreed. That is why I add atrpms and rpmfusion, but beware: there can be
odd dependency clashes between repositories: there are currently stopping
me from installing vlc and avidemux: eventually I'll crack and compile
these from source.
> 6. OpenJDK is a YUM install and the Sun JDK is an RPM install. So,
> choosing Sun over OpenJDK means giving up painless automatic updates.
>
If you pull in an RPM install/update directly (as I regularly do for both
Java and Opera, the next yum update will complain that something changed
the RPM database without telling it. This can be safely ignored if you
know you did this.
> 7. The right way to manage multiple installations of Java is through the
> standard 'alternatives' mechanism. See:
>
I use this for swapping from sendmail to Postfix, both both are Fedora
packages: not doing so causes arse-ache. However, merely changing $PATH
by dropping java.sh (my custom script: contains pathmunge commands) into
/etc/profile.d/ is easy and works equally well.
FWIW the predefined alternatives in F15 are only OpenJava and gcj
(compile to native using the gcc Java-->C preprocessor)
8. Being the 'default' Java means, amongst other things, that OpenJDK is
> a dependency of any package which uses Java. Hence, even if you install
> the Sun JDK, using YUM to install such a package will drag in OpenJDK -
> even though it won't actually be used! It's possible this won't happen
> if you have correctly used the alternatives mechanism, as above, but i
> can't guarantee it.
>
Quite.
> 9. I don't think any standard installation process sets the JAVA_HOME
> environment variable, so add an export for that to your .bashrc (and
> make sure your .bash_profile sources your .bashrc - or do something
> different if you prefer). This is not required, but i often come across
> bits of software (like JBoss) which either assume or are greatly
> comforted by its presence.
>
True.
> 10. There are loads of Java libraries in the package repositories, all
> just a few effortless keystrokes away. However! I'm not sure i really
> recommend getting libraries this way. Although YUM makes getting
> libraries easy, it doesn't help you distribute code written against the
> libraries - unless your consumers are also running Fedora, you are going
> to have to take care of packaging the dependencies yourself. If you
> instead use something like Ivy to get your jars, you can somewhat
> reasonably just distribute your ivy.xml file, or if not, use Ivy to
> build a zip-of-jars to distribute.
>
Quite. I use a few of them, configured in manually.
I agree with your other points, but haven't added anything: I manually
installed ant and don't use any IDEs.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2011-10-16 22:03 -0400 |
| Message-ID | <4e9b8cd8$0$282$14726298@news.sunsite.dk> |
| In reply to | #8883 |
On 10/16/2011 8:29 PM, Martin Gregorie wrote: > On Mon, 17 Oct 2011 00:31:05 +0100, Tom Anderson wrote: >> 2. None of the above includes Derby, which is included in the Sun >> releases. That's a package simply called derby. >> > True. Due to a PostgreSQL fixation I keep meaning to use it but haven't > yet. I don't think Derby and PostgreSQL are alternatives. You could use Derby for your development incl. unit test because it is practically no install/config and PostgreSQL for your QA and production for the reliability and performance. Arne
[toc] | [prev] | [next] | [standalone]
| From | Tom Anderson <twic@urchin.earth.li> |
|---|---|
| Date | 2011-10-17 15:08 +0100 |
| Message-ID | <alpine.DEB.2.00.1110171448080.10855@urchin.earth.li> |
| In reply to | #8889 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, 16 Oct 2011, Arne Vajhøj wrote: > On 10/16/2011 8:29 PM, Martin Gregorie wrote: >> On Mon, 17 Oct 2011 00:31:05 +0100, Tom Anderson wrote: >>> 2. None of the above includes Derby, which is included in the Sun >>> releases. That's a package simply called derby. >> >> True. Due to a PostgreSQL fixation I keep meaning to use it but haven't >> yet. > > I don't think Derby and PostgreSQL are alternatives. > > You could use Derby for your development incl. unit test because it is > practically no install/config and PostgreSQL for your QA and production > for the reliability and performance. I'd almost say it was the other way round. PostgreSQL is pretty easy to install - as root (paraphrasing what i actually just did): yum install postgresql-server # will prompt to confirm sudo -u postgres initdb # possibly edit pg_hba.conf service postgresql start sudo -u postgres createuser -P -S developer # will prompt for a password sudo -u postgres createdb -O developer development pg_hba.conf is the file which defines access methods, and access control. With every package i have ever installed, it is created in a state which allows the normal console user to get access to the database. However, the details vary: IIRC, on OS X (with MacPorts), it is set up to use peer authentication for unix domain sockets (which is secure), and MD5 password authentication for TCP/IP sockets (which is fairly secure). However, a default install on Fedora 15 has no authentication on either kind of socket; that said, TCP/IP sockets are only opened on the loopback interface, so this is not that bad. An old installation on Fedora came with only unix domain sockets by default, and no TCP/IP. So, that file may need some tweaking. So, not nearly as easy as installing Derby (which with a Sun JDK involves precisely zero steps), but not at all difficult. Suitable for a development machine. Whereas i think the great strength of Derby is in production - if and only if you are distributing code to run on desktop machines. There, the less you need to install, the better, and the fact that Derby comes in the JDK makes it a bit of a slam-dunk. It's not a particularly great database, but you can't argue with the ease of installation. tom -- If this is paradise, i wish i had a lawnmower.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2011-11-06 15:49 -0500 |
| Message-ID | <4eb6f2d5$0$295$14726298@news.sunsite.dk> |
| In reply to | #8910 |
On 10/17/2011 10:08 AM, Tom Anderson wrote: > On Sun, 16 Oct 2011, Arne Vajhøj wrote: > >> On 10/16/2011 8:29 PM, Martin Gregorie wrote: >>> On Mon, 17 Oct 2011 00:31:05 +0100, Tom Anderson wrote: >>>> 2. None of the above includes Derby, which is included in the Sun >>>> releases. That's a package simply called derby. >>> >>> True. Due to a PostgreSQL fixation I keep meaning to use it but haven't >>> yet. >> >> I don't think Derby and PostgreSQL are alternatives. >> >> You could use Derby for your development incl. unit test because it is >> practically no install/config and PostgreSQL for your QA and >> production for the reliability and performance. > > I'd almost say it was the other way round. PostgreSQL is pretty easy to > install - as root (paraphrasing what i actually just did): > So, not nearly as easy as installing Derby (which with a Sun JDK > involves precisely zero steps), but not at all difficult. Suitable for a > development machine. Something > nothing. > Whereas i think the great strength of Derby is in production - if and > only if you are distributing code to run on desktop machines. There, the > less you need to install, the better, and the fact that Derby comes in > the JDK makes it a bit of a slam-dunk. It's not a particularly great > database, but you can't argue with the ease of installation. An embedded database like Derby is great for desktop apps. But I would not use it for a major Java EE app. And I must admit that I am thinking mostly Java EE when talking about production. Arne
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2011-10-17 21:29 +0000 |
| Message-ID | <j7i6o6$kk4$2@localhost.localdomain> |
| In reply to | #8889 |
On Sun, 16 Oct 2011 22:03:04 -0400, Arne Vajhøj wrote: > I don't think Derby and PostgreSQL are alternatives. > > You could use Derby for your development incl. unit test because it is > practically no install/config and PostgreSQL for your QA and production > for the reliability and performance. > Of course, but with PostgreSQL installed and running, the effort needed to add a new project/database/call it what you will is probably the same as it would be with Derby - and I don't need to learn another database's SQL syntax quirks to do it. I've nothing against Derby: its on my list of things to get up to speed with, but hasn't yet got to the head of the list. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2011-11-06 15:47 -0500 |
| Message-ID | <4eb6f24f$0$295$14726298@news.sunsite.dk> |
| In reply to | #8930 |
On 10/17/2011 5:29 PM, Martin Gregorie wrote: > On Sun, 16 Oct 2011 22:03:04 -0400, Arne Vajhøj wrote: >> I don't think Derby and PostgreSQL are alternatives. >> >> You could use Derby for your development incl. unit test because it is >> practically no install/config and PostgreSQL for your QA and production >> for the reliability and performance. >> > Of course, but with PostgreSQL installed and running, the effort needed > to add a new project/database/call it what you will is probably the same > as it would be with Derby - and I don't need to learn another database's > SQL syntax quirks to do it. But that is because you have have PostgreSQL installed and running. Arne
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2011-11-06 22:49 +0000 |
| Message-ID | <j972ue$dnt$1@localhost.localdomain> |
| In reply to | #9672 |
On Sun, 06 Nov 2011 15:47:12 -0500, Arne Vajhøj wrote: > On 10/17/2011 5:29 PM, Martin Gregorie wrote: >> On Sun, 16 Oct 2011 22:03:04 -0400, Arne Vajhøj wrote: >>> I don't think Derby and PostgreSQL are alternatives. >>> >>> You could use Derby for your development incl. unit test because it is >>> practically no install/config and PostgreSQL for your QA and >>> production for the reliability and performance. >>> >> Of course, but with PostgreSQL installed and running, the effort needed >> to add a new project/database/call it what you will is probably the >> same as it would be with Derby - and I don't need to learn another >> database's SQL syntax quirks to do it. > > But that is because you have have PostgreSQL installed and running. > True, but IIRC the initial install of PostgreSQL was pretty much a no- brainer too. The only non-straightforwardness I remember was due to me modifying the installation to move the physical database from the /var tree to /home for system management reasons. I've arranged my system so that /home is in a separate partition and that /usr/local and /usr/java as well as all PostgreSQL and Apache related user data are there as well. This means that, for a clean Linux install I can reformat everything on disk except the /home partition and know that nothing I care about will need to be restored. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2011-11-06 17:13 -0800 |
| Message-ID | <5210608.1104.1320628429657.JavaMail.geo-discussion-forums@prms22> |
| In reply to | #9692 |
Martin Gregorie wrote: > Arne Vajhøj wrote: >> Martin Gregorie wrote: >>> Arne Vajhøj wrote: >>>> I don't think Derby and PostgreSQL are alternatives. >>>> >>>> You could use Derby for your development incl. unit test because it is >>>> practically no install/config and PostgreSQL for your QA and >>>> production for the reliability and performance. >>>> >>> Of course, but with PostgreSQL installed and running, the effort needed >>> to add a new project/database/call it what you will is probably the >>> same as it would be with Derby - and I don't need to learn another >>> database's SQL syntax quirks to do it. >> >> But that is because you have have PostgreSQL installed and running. >> > True, but IIRC the initial install of PostgreSQL was pretty much a no- > brainer too. > > The only non-straightforwardness I remember was due to me modifying the > installation to move the physical database from the /var tree to /home > for system management reasons. I've arranged my system so that /home is > in a separate partition and that /usr/local and /usr/java as well as all > PostgreSQL and Apache related user data are there as well. This means > that, for a clean Linux install I can reformat everything on disk except > the /home partition and know that nothing I care about will need to be > restored. For development purposes, the default installation of Postgres works pretty well. For production purposes, as with any DBMS, the situation can be more complicated. There are many goals you want a DBMS to achieve. Most people seem to talk about speed or ease of use as if reliability were taken for granted. First and foremost, the prime directive of any data store is to be reliable. Ancillary to that the management protocols for the system should not impede keeping a system reliable. (The violation of this was my main complaint with MySQL. I don't know if they fixed it.) We do want the system to be of low footprint appropriate to the application domain. Fast enough for the project usage. Scalable likewise. Postgres and Derby both tend to win in another important area - standardness of the SQL dialect. Postgres reaches down pretty far into the low end of scale, but obviously not quite as far as Derby. Conversely, Derby does quite well into higher scale, but obviously not quite as far as Postgres. If you're doing a lot of enterprise or web work you should consider Postgres strong contender. Even during development, it mixes well with the enterprise way of looking at things (layered and componentized). Porting a system from Postgres to, say, Oracle or DB2 turns out to be not so bad. Of course no two RDBMSes speak the same dialect of SQL, but the transformations between the big guns seem to be mostly mechanical - Oracle uses VARCHAR2 for VARCHAR, for example. It's harder when a system decides to reinvent the semantics of a keyword to something rather different, as MySQL did with TIMESTAMP. That's just one scenario where one might find advantage to Postgres. Of course, the same arguments apply to the free versions of Oracle and DB2, to a point. For desktop distribution Derby may well be the ideal solution. For a desktop app needing more than desktop-scale data, perhaps a distributed DBMS architecture - keep the local DB as a sort of edge cache for wide-area data. I put forward this pie in the sky to point out that different systems fill different niches. I observe that between them, Derby and PostgreSQL cover the gamut of RDBMS needs and could even complement each other. Solid products, open source, span the use case range: no need for me to hunt further. (This does not preclude reaching for non-RDBMS solutions.) -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2011-11-07 23:49 +0000 |
| Message-ID | <j99qpr$4j1$1@localhost.localdomain> |
| In reply to | #9717 |
On Sun, 06 Nov 2011 17:13:49 -0800, Lew wrote: > For development purposes, the default installation of Postgres works > pretty well. For production purposes, as with any DBMS, the situation > can be more complicated. > PostgreSQL itself can be shifted about fairly easily: the inflexibility was in the SYSVinit daemon management script it uses which, at least on RedHat Fedora systems up to the F12 release, could only be reconfigured by editing the script because it ignored the convention of stashing configurable values in /etc/sysconfig. They fixed this for F13 - just in time to change things again when F15 introduced the systemd service management system. > Postgres and Derby both tend to win in another important area - > standardness of the SQL dialect. > Agreed. Does anything apart from MySQL insist on using auto-incrementing variables where the rest of the DB world mostly uses sequences? I don't really see the point given that you almost always want to know the value that was assigned (particularly if the field is in a prime key) and this forces you to read a row immediately after it was inserted. > If you're doing a lot of enterprise or web work you should consider > Postgres strong contender. Even during development, it mixes well with > the enterprise way of looking at things (layered and componentized). > I'm still very impressed with it, not least for the way it keeps its filing system tidy and the DB stats updated with next to no management effort apart from making backups and the periodic need to restore from the backup after a major version upgrade. > Porting a system from Postgres to, say, Oracle or DB2 turns out to be > not so bad. Of course no two RDBMSes speak the same dialect of SQL, but > the transformations between the big guns seem to be mostly mechanical - > Oracle uses VARCHAR2 for VARCHAR, for example. It's harder when a > system decides to reinvent the semantics of a keyword to something > rather different, as MySQL did with TIMESTAMP. > The only major Postgres anomaly, that I've noticed anyway, is its use of a BYTEA where other DBMS would use a CLOB. > For desktop distribution Derby may well be the ideal solution. For a > desktop app needing more than desktop-scale data, perhaps a distributed > DBMS architecture - keep the local DB as a sort of edge cache for > wide-area data. > Derby is very much on my radar: I just haven't yet found a round tuit or a good reason to use Derby in place of PostgreSQL. Have you tried using it as a small central DBMS, i.e. not run as an integral part of an application? If so, are there any obvious gotchas or performance issues with running it that way? -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2011-11-07 21:07 -0800 |
| Message-ID | <j9adf1$7f3$1@dont-email.me> |
| In reply to | #9758 |
On 11/7/2011 3:49 PM, Martin Gregorie wrote: > Derby is very much on my radar: I just haven't yet found a round tuit or > a good reason to use Derby in place of PostgreSQL. I've considered using it for unit testing. I need to get cracking on that particular personal project, actually, but I'm just tossing the idea out there that DB doesn't have to mean production system.
[toc] | [prev] | [next] | [standalone]
| From | Tom Anderson <twic@urchin.earth.li> |
|---|---|
| Date | 2011-10-17 16:47 +0100 |
| Message-ID | <alpine.DEB.2.00.1110171645590.10855@urchin.earth.li> |
| In reply to | #8883 |
On Mon, 17 Oct 2011, Martin Gregorie wrote: >> On Sun, 16 Oct 2011, Martin Gregorie wrote: >> >>> though you can easily switch to Oracle/Sun Java by simply downloading >>> and installing it > > However, by that time OpenJava is already installed. So far I haven't > been brave enough to uninstall it after I've installed the Sun/Oracle > JDK. Have you tried this? I haven't. We used to run CentOS 5 systems with only Sun JDK and no OpenJDK, but i think that was because there was no OpenJDK at the time. tom -- A rough whimper of insanity.
[toc] | [prev] | [next] | [standalone]
| From | B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> |
|---|---|
| Date | 2011-10-16 20:55 -0400 |
| Message-ID | <j7fuef$hjm$1@speranza.aioe.org> |
| In reply to | #8877 |
On 16/10/2011 7:31 PM, Tom Anderson wrote: > The upshot of this is that if you install something from an RPM, then > all you get is the installation. It is up to you to obtain the > installer, install dependencies, install updates when they are released, > and so on. Whereas if you install from YUM, the machine does all that > for you. The critical bit there is updates: if a new bugfix release of a > package is pushed out, an install from RPM does nothing at all, whereas > an install from YUM will upgrade to it as a matter of routine. (I feel > so sorry for users of operating systems where this is not the norm, such > as Windows and most of OS X; Unix users get this wonderful > up-to-dateness as standard) The flip side of this, of course, is that Unix users can also wake up one morning to fresh new bugs that have just spontaneously materialized in software that had been working perfectly for them yesterday. :) -- A fatal exception 0E has occurred at 0028:C0011E36 in VXD VMM(01) 00010E36. The current application will be terminated. * Press any key to terminate the current application.
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2011-10-17 21:37 +0000 |
| Message-ID | <j7i76v$kk4$3@localhost.localdomain> |
| In reply to | #8886 |
On Sun, 16 Oct 2011 20:55:40 -0400, B1ll Gat3s wrote: > > The flip side of this, of course, is that Unix users can also wake up > one morning to fresh new bugs that have just spontaneously materialized > in software that had been working perfectly for them yesterday. :) > That's only true if you leave automatic updating enabled: I don't. By turning it off I can easily do a fast backup with rsync immediately before running yum, thus creating the possibility of a fairly easy backout should it be needed. So far, after 8+ years of using Fedora that hasn't been necessary. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2011-10-16 22:14 -0400 |
| Message-ID | <4e9b8f93$0$290$14726298@news.sunsite.dk> |
| In reply to | #8877 |
On 10/16/2011 7:31 PM, Tom Anderson wrote: > The upshot of this is that if you install something from an RPM, then > all you get is the installation. It is up to you to obtain the > installer, install dependencies, install updates when they are released, > and so on. Whereas if you install from YUM, the machine does all that > for you. The critical bit there is updates: if a new bugfix release of a > package is pushed out, an install from RPM does nothing at all, whereas > an install from YUM will upgrade to it as a matter of routine. (I feel > so sorry for users of operating systems where this is not the norm, such > as Windows and most of OS X; Unix users get this wonderful > up-to-dateness as standard) Updating is not the issue. Testing that updates will not break anything is the issue. Arne
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.java.programmer
csiph-web