A
Arne Vajhøj
That is actually a good example of where it is a problem.
java.util.Date should have had a different name!
Yep.
Arne
That is actually a good example of where it is a problem.
java.util.Date should have had a different name!
Yep.
Arne
A
Arved Sandstrom
Speaking to Eclipse (I use IDEA and NetBeans less frequently these days)
you can also save some irritation by modifying Java > Code Style >
Organize Imports and Java > Appearance > Type Filters, based on
knowledge of what package import priorities are, and what packages you
know might appear in an import conflict selection dialog but that you'd
never want to import.
I realize that this is not the same problem as what's being discussed in
this thread, where you have got two classes with the same name being
imported, but quite frankly it's been years since I had two classes with
the same name in the same class file, whereas I run into import
disambiguation situations in IDEs every day. I'm with Lew on this one -
next time I run into the problem being discussed in this thread, whether
that be this year some time or in 2015, I'll just use FQN's.
AHS
L
Lawrence D'Oliveiro
So you 1) don’t want individual classes specific to SQLite and MySQL, and 2)
don’t want a common class dealing with both.
What do you want, exactly?
A
Arved Sandstrom
OK, his wording might not have been the greatest. I suggest that you
treat (1) and (2) as separate statements. (1) as a general observation,
which while 1 is also not always easy to avoid.
As far as (2) goes, I'd suggest a naming convention for this scenario
that the EclipseLink team uses:
http://wiki.eclipse.org/Introduction_to_Data_Access_(ELUG)#Database_Platforms.
AHS
A
Arne Vajhøj
Preferable no database specific code at all. The JDBC API
provides many features to support that.
In those very rare cases where that is not possible, then
a class per database and a configuration/DI way of loading
those.
Arne
A
Arne Vajhøj
It happens that I use an empty line to indicate that.
It was not so much the naming but the problem with a class that
will need to be updated every time a new database has to be
supported that I did not like.
Arne
L
Lew
Arne said:
Sometimes it pays to push deployment issues out to XML files and indirect
resource managers like JNDI.
For example, Tomcat uses context.xml and related files to configure JDBC/JNDI
access, and this works quite nicely with JPA (Java Persistence API).
http://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html
Full-blown Java EE app servers have such mechanisms also.
persistence.xml:
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="fooPu" transaction-type="RESOURCE_LOCAL">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<non-jta-data-source>java:/comp/env/jdbc/foosrc</non-jta-data-source>
<class>com.lewscanon.foo.entity.Person</class>
<class>com.lewscanon.foo.entity.Address</class>
<class>com.lewscanon.foo.entity.Avatar</class>
<class>com.lewscanon.foo.entity.Etc</class>
<exclude-unlisted-classes>true</exclude-unlisted-classes>
<shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
<properties>
<property name="eclipselink.ddl-generation" value="create-tables"/>
</properties>
</persistence-unit>
</persistence>
context.xml:
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/foo" reloadable="true" >
<Resource auth="Container" name="jdbc/foosrc" type="javax.sql.DataSource"
url="jdbc
ostgresql://127.0.0.1:5432/foo"driverClassName="org.postgresql.Driver"
username="groucho" password="swordfish"
maxActive="20" maxIdle="2" maxWait="-1"
/>
</Context>
R
Roedy Green
Two reasons.
1. A modern IDE such as IntelliJ handles all the imports for you.
2. The long form of the import is easier to proofread and use. As soon
as you get nesting your brain has to think harder to see just which
packages a given class uses.
You are trying to optimise writing, when you should be optimising
reading.
That would likely have become obvious if you spent a few months
writing code FIRST. THEN by all means, make suggestions for changes.
Unlike others, I have no objection to you making such suggestions to
change Java or criticise it. I have made hundreds myself.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Refactor early. If you procrastinate, you will have
even more code to adjust based on the faulty design.
..
L
Lawrence D'Oliveiro
I wonder why Android doesn’t include any JDBC APIs in its standard library.
Could it be the overheads are too great?
Also, your problem is, you’re too fixated on the specific example, and not
on the general problem. Would you prefer another example?
L
Lawrence D'Oliveiro
http://wiki.eclipse.org/Introduction_to_Data_Access_(ELUG)#Database_Platforms.
I don’t understand the point of ensuring that unqualified names are
distinct. Isn’t that defeating the purpose of using qualification in the
first place?
L
Lawrence D'Oliveiro
Actually, my Android code will only be concerned with one DBMS, and that is
SQLite3. I brought in MySQL as an example, but I would not do any inter-DBMS
manipulations in Java, I use Python for that.
A
Arne Vajhøj
Whether you need it or not does not really matter.
It is still not good code.
Arne
A
Arne Vajhøj
No.
Packages exists to provide a logical grouping of classes.
The potential for having classes with same name in different
packages is a side effect.
Arne
A
Arne Vajhøj
I wonder why you got that idea.
http://developer.android.com/reference/java/sql/package-summary.html
Does not seems like it.
Well - I stated:
#With a decent package and class structure and naming, then it
#should happen so rare that it a complete no problem.
You asked whether I considered your example to fell
in that category and I explained to you why it is not.
If you don't think the answer is relevant then don't ask
the question.
Arne
L
Lew
Packages in Java are namespaces, serving a similar purpose to those defined by
URNs in XML schema.
Java doesn't actually have unqualified class names. 'import' is a directive,
not a statement.
A
Arved Sandstrom
Good question. I should point out that these database-specific classes
rarely get imported explicitly in Java code by an end user; rather, they
are specified through a JPA persistence.xml file. In this model it would
be essential for the names to be different.
I'm absolutely not going to say that your proposed use of packages is
wrong. We know that Java packages are used to provide a namespace
mechanism - that's the primary purpose - and as an obvious corollary
programmers then often use packages to group their classes by
functionality. But I don't believe that it follows from this primary
purpose of packages - unique namespaces - that your proposed use is a
_recommendation_. I don't think it's an _incorrect_ use, and if it makes
your APIs and implementations easier to design, implement and use, so
much the better.
In this particular problem domain I think you could make a decent
opposing argument that rather than have
org.ahs.database.platforms.oracle.Platform
org.ahs.database.platforms.mysql.Platform
it still makes more sense to have
org.ahs.database.platforms.OraclePlatform
org.ahs.database.platforms.MySqlPlatform
because the _classes_ are _not_ the same. One is customized for Oracle,
one for MySQL. Assuming that both inherit from a
org.ahs.database.platforms.Platform class, say, it's not like I'll have
explicit references to MySqlPlatform all over the place; in most cases
I'll be referring to Platform anyway.
Like I say, I don't doubt that there are situations where your proposed
package structure makes more sense. A lot of different factors would
come into it. Main thing is, I don't believe that the purpose of Java
packages dictates or recommends either approach.
AHS
L
Lew
Arved said:
According to the Java tutorial at
http://download.oracle.com/javase/tutorial/java/concepts/package.html
"A package is a namespace that organizes a set of related classes and interfaces."
So grouping related types is an explicit purpose of the namespaces.
The JLS, Chapter 7, "Packages", states, "Each package has its own set of names
for types, which helps to prevent name conflicts."
So prevention of name conflicts is, according to the JLS, a primary purpose of
packages.
I agree with your recommendations for package structure.
A
Arne Vajhøj
Packages is more than just namespace.
They are a part of OOD and UML.
And they have a practical impact on the code via
package visibility.
Arne
A
Arne Vajhøj
I don't see the word "primary" in the quoted material.
I am sure that you with a little search can find other points
of package usage in the JLS.
And then you can go outside of the JLS. Like:
http://en.wikipedia.org/wiki/Package_(UML)
Arne
L
Lew
The purpose is mentioned in the second sentence on the very topic, right at
the beginning of Chapter 7, of the normative document on the matter. That's
evidence of primacy.
You are correct that they do not use the word "primary". But you are being
disingenuous because you know perfectly well that that is neither necessary
nor sufficient to establish primacy. Inclusion in the JLS at all indicates
that the purpose is primary; inclusion at the very beginning of discussion of
the topic is strong evidence.
If you demand 100% proof rather than a preponderance of evidence, then you
win. It's ridiculous to think I could provide such. To achieve agreement you
and I will now need to resolve our different definitions of primacy of
purpose, evidence thereof, and sufficiency of proof. I prefer to stipulate
your definitions and concede the point.
I back off to the weaker claim; inclusion in the JLS signifies that prevention
of name conflicts is a sanctioned purpose of packages.
This still chides those who derided that purpose.
Also primary uses.
As a meta-comment, let me commend you for setting an excellent example both
for rigorous thinking and use of research tools.