[eobjects] #857: Remove toTableModel from DataSet interface

2 views
Skip to first unread message

eobjects

unread,
May 22, 2012, 9:08:23 PM5/22/12
to dataclean...@googlegroups.com
#857: Remove toTableModel from DataSet interface
-------------------------+---------------------------
Reporter: w.cazander | Owner:
Type: enhancement | Status: new
Priority: low | Milestone: MetaModel 3.0
Component: MetaModel | Keywords: swing
-------------------------+---------------------------
Influenced classes:
org.eobjects.metamodel.data.DataSet

-------------------------+---------------------------
This swing TableModel class will get you AccessControlExceptions when
doing fine grained policy control with SecurityManager.

Or module systems environments such as OSGi and Jigsaw.

Or in embedded jvm/compiler without awt/swing support.

End user code change impact; (+12 chars)
{{{
OLD: TableModel tm = dataSet.toTableModel();

NEW: TableModel tm = new DataSetTableModel(dataSet);
}}}

--
Ticket URL: <http://eobjects.org/trac/ticket/857>
eobjects <http://eobjects.org/trac>
The eobjects project management system, based on the trac system.

eobjects

unread,
May 24, 2012, 3:08:01 AM5/24/12
to dataclean...@googlegroups.com
#857: Remove toTableModel from DataSet interface
-------------------------+----------------------------
Reporter: w.cazander | Owner:
Type: enhancement | Status: new
Priority: low | Milestone: MetaModel 3.0
Component: MetaModel | Resolution:
Keywords: swing |
-------------------------+----------------------------
Influenced classes:
org.eobjects.metamodel.data.DataSet

-------------------------+----------------------------

Comment (by kasper):

Damn I never realized this was an issue. Will it really cause issues, even
if you do not invoke toTableModel() ?

If it only occurs when you call the method, then I can live with it, but
obviously we need to support OSGi environments etc.

--
Ticket URL: <http://eobjects.org/trac/ticket/857#comment:1>

eobjects

unread,
May 24, 2012, 10:16:54 AM5/24/12
to dataclean...@googlegroups.com
#857: Remove toTableModel from DataSet interface
-------------------------+----------------------------
Reporter: w.cazander | Owner:
Type: enhancement | Status: new
Priority: low | Milestone: MetaModel 3.0
Component: MetaModel | Resolution:
Keywords: swing |
-------------------------+----------------------------
Influenced classes:
org.eobjects.metamodel.data.DataSet

-------------------------+----------------------------

Comment (by w.cazander):

Yes the import statement of the TableModel class needs a TableModel class
in classloader see;

http://wiki.osgi.org/wiki/Why_does_Eclipse_find_javax.swing_but_not_Felix%3F

--
Ticket URL: <http://eobjects.org/trac/ticket/857#comment:2>

eobjects

unread,
May 24, 2012, 10:22:59 AM5/24/12
to dataclean...@googlegroups.com
#857: Remove toTableModel from DataSet interface
-------------------------+----------------------------
Reporter: w.cazander | Owner:
Type: enhancement | Status: new
Priority: low | Milestone: MetaModel 3.0
Component: MetaModel | Resolution:
Keywords: swing |
-------------------------+----------------------------
Influenced classes:
org.eobjects.metamodel.data.DataSet

-------------------------+----------------------------

Comment (by kasper):

Hmm does that mean we can fix the issue by not IMPORTING the class, but by
fully qualifying it (locally) in the method? Like this:

{{{
public javax.swing.table.TableModel toTableModel();
}}}

Just looking for an easy fix that will not break backwards compatibility.
At Human Inference we do have quite some code relying on this method (and
I always liked it because TableModel is also used in many contexts except
Swing (eg. for some web frameworks etc.).

--
Ticket URL: <http://eobjects.org/trac/ticket/857#comment:3>

eobjects

unread,
May 24, 2012, 9:59:49 PM5/24/12
to dataclean...@googlegroups.com
#857: Remove toTableModel from DataSet interface
-------------------------+----------------------------
Reporter: w.cazander | Owner:
Type: enhancement | Status: new
Priority: low | Milestone: MetaModel 3.0
Component: MetaModel | Resolution:
Keywords: swing |
-------------------------+----------------------------
Influenced classes:
org.eobjects.metamodel.data.DataSet

-------------------------+----------------------------

Comment (by w.cazander):

No that is already there loading as sting and return object will do it;
{{{
public Object toTableModel() {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
if (cl == null) {
cl = getClass().getClassLoader();
}
try {
Class<?> tableModelClass =
cl.loadClass(".....DataSetTableModel");
return tableModelClass.getConstructor(new Class[]
{DateSet.class}).invoke(this);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}}}

But still user code needs change with extra cast statement, but than api
changes
can happen on major version updates.

I would restict even more to only import sub packages and
java.lang.*/java.util.* and move
impl classes to seperate package (but not abstracts) and split dataset api
into;
- org.eobjects.metamodel.dataset.*
- org.eobjects.metamodel.dataset.row.*
- org.eobjects.metamodel.dataset.meta.*

Splitting even more will make verly clean api;
- metamodel-datatype
- metamodel-dataset
- metamodel-schema
- metamodel-query
- metamodel-query-dataset
- metamodel-query-pojo
- metamodel-core
- metamodel-data-mongodb
- metamodel-data-jdbc
- metamodel-papi-classic
- metamodel-papi-jdo
- metamodel-papi-jpa

Just a thought :)

--
Ticket URL: <http://eobjects.org/trac/ticket/857#comment:4>

eobjects

unread,
May 26, 2012, 12:02:02 PM5/26/12
to dataclean...@googlegroups.com
#857: Remove toTableModel from DataSet interface
-------------------------+----------------------------
Reporter: w.cazander | Owner:
Type: enhancement | Status: new
Priority: low | Milestone: MetaModel 3.0
Component: MetaModel | Resolution:
Keywords: swing |
-------------------------+----------------------------
Influenced classes:
org.eobjects.metamodel.data.DataSet

-------------------------+----------------------------

Comment (by w.cazander):

Oke have to redefine the SecurityManager statement as that only checks if
code is allowed
to change class loader, where the module class loader still should kill
java.swing classes
when bundle has not defined that is needs those.

Also in the past GCJ had no support for awt and swing classes but now it
can be enabled
when compiling gcj itself.
Done small test on my current (unstable) debian version of GCJ which has
gotten awt and
~swing support enabled by default.

Small gcj test run code:
{{{
public class SwingLoadTest {
private Table table = null;
public static void main(String[] argu) {
try {SwingLoadTest test = new
SwingLoadTest();test.run(argu);} catch (Exception e)
{e.printStackTrace();}
}
public void run(String[] argu) throws Exception {
File tmpFile = File.createTempFile("test-class-loading",
"csv");
tmpFile.deleteOnExit();
CsvDataContext dataContext = new CsvDataContext(tmpFile);
final Schema schema = dataContext.getDefaultSchema();
dataContext.executeUpdate(new UpdateScript() {
public void run(UpdateCallback cb) {
MutableRef<Table> tableRef = new MutableRef<Table>();
table = cb.createTable(schema,
"table").withColumn("column").execute();
tableRef.set(table);
cb.insertInto(table).value(0,"data").execute();
}
});
DataSet ds =
dataContext.query().from(table).select(table.getColumns()).execute();
while (ds.next()) {
Row row = ds.getRow();
System.out.println("Row value contains
"+row.getValue(0));
}
ds.close();
}
}
}}}

Running some compile commands like;
{{{
gcj --classpath=slf4j-simple.jar:slf4j.jar -fjni -c slf4j-simple.jar -o
slf4j-simple.jar.o
gcj --classpath=slf4j-simple.jar:slf4j.jar -fjni -c slf4j.jar -o
slf4j.jar.o
gcj --classpath=slf4j.jar:slf4j-simple.jar:mm-core.jar -fjni -c mm-
core.jar -o mm-core.jar.o
gcj --classpath=slf4j.jar:slf4j-simple.jar:mm-core.jar:opencsv.jar -fjni
-c opencsv.jar -o opencsv.jar.o
gcj --classpath=slf4j.jar:slf4j-simple.jar:mm-core.jar:opencsv.jar:mm-
csv.jar -fjni -c mm-csv.jar -o mm-csv.jar.o
gcj --classpath=slf4j.jar:slf4j-simple.jar:mm-core.jar:opencsv.jar:mm-
csv.jar:SwingLoadTest.java -fjni -c SwingLoadTest.java -o SwingLoadTest.o

gcj -o SwingLoadTest --main=SwingLoadTest slf4j.jar.o slf4j-simple.jar.o
mm-core.jar.o mm-csv.jar.o opencsv.jar.o SwingLoadTest.o

$ ls -lah SwingLoadTest
-rwxr-xr-x 1 user user 1.8M May 26 17:20 SwingLoadTest
}}}

Check native execute time;
{{{
$ time ./SwingLoadTest
Row value contains data

real 0m0.177s
user 0m0.096s
sys 0m0.060s

Compare to byte code jvm's;

java-7-openjdk-amd64: 0m0.364s
java-6-openjdk-amd64: 0m0.382s
java-6-sun-1.6.0.26: 0m0.450s
java-1.5.0-gcj-4.7: 0m0.364s

java-1.5.0-sun-1.5.0.20: No Data
(As all libs are version 50.0 should recompile all to 49.0 to test)
}}}

--
Ticket URL: <http://eobjects.org/trac/ticket/857#comment:5>

eobjects

unread,
May 31, 2012, 5:31:17 AM5/31/12
to dataclean...@googlegroups.com
#857: Remove toTableModel from DataSet interface
-------------------------+----------------------------
Reporter: w.cazander | Owner:
Type: enhancement | Status: new
Priority: low | Milestone: MetaModel 3.0
Component: MetaModel | Resolution:
Keywords: swing |
-------------------------+----------------------------
Influenced classes:
org.eobjects.metamodel.data.DataSet

-------------------------+----------------------------

Comment (by kasper):

Willem, I think you're right. Let's remove this method from the DataSet
interface. And let's create just a single new maven module for now called
'extras'. We can put the DataSetTableModel class in there.

The 'full' module should have 'extras' as an optional dependency IMO.

--
Ticket URL: <http://eobjects.org/trac/ticket/857#comment:6>

eobjects

unread,
Jul 8, 2012, 4:16:08 PM7/8/12
to dataclean...@googlegroups.com
#857: Remove toTableModel from DataSet interface
-------------------------+----------------------------
Reporter: w.cazander | Owner:
Type: enhancement | Status: closed
Priority: low | Milestone: MetaModel 3.0
Component: MetaModel | Resolution: fixed
Keywords: swing |
-------------------------+----------------------------
Influenced classes:
org.eobjects.metamodel.data.DataSet

-------------------------+----------------------------
Changes (by kasper):

* status: new => closed
* resolution: => fixed


Comment:

As of rev. [3929], I've deprecated the toTableModel() method.

My suggestion is that we now keep everything as is for the 3.0 release and
in 3.1 we remove the method entirely.

--
Ticket URL: <http://eobjects.org/trac/ticket/857#comment:7>

Reply all
Reply to author
Forward
0 new messages