--
Ticket URL: <http://eobjects.org/trac/ticket/857>
eobjects <http://eobjects.org/trac>
The eobjects project management system, based on the trac system.
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>
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>
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>
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>
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>
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>
* 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>