Skip to main content

move to tiger?

69 replies [Last post]
Anonymous

For the last 6 months the jdnc team has been grappling with whether or
not we should build JDNC on top of tiger (1.5). There are many exceptional
features in 1.5 which JDNC could benefit from, such as:
- generics
- web rowset
- table printing
- concurrency utilities

However, up until now, we've consciously chose NOT to make this dependency,
as we've felt it's critical that JDNC be deployable on a 1.4.X base (most JREs out there).
However, the closer tiger comes to its final release, the more tempting it becomes,
especially since JDNC is not likely to reach 1.0 until the first half of 2005.

We'd like to get your input on this decision. Here are the pros/cons as we see them:

Pros:
- access to many new features:
. web rowset
. xerces parser
. table printing
- generics for improving apis
- concurrency utilities
- pack200 for huge download/compression improvements
- WebStart fixes/enhancements

Cons:
- 1.5 hasn't gone final yet, thus most JREs out there haven't upgraded, forcing more
JRE downloads for JDNC deployments
- 1.5 not yet available on OSX
- Many won't move to 1.5.0 and will delay upgrading until a 1.5.X release,
which isn't likely until 2005.

What do you think?
A) cut JDNC to 1.5 now
B) keep stable on 1.4.2 until 1.5 is widely adopted

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Mark Hillary

jdnc-interest@javadesktop.org wrote:

>It's always possible that we could fire up a 1.4 branch. However, we don't have the resources to manage a branch, and there can very well develop incompatibilities between the two. If somebody with a vested interest in 1.4 wanted to port the code in the incubator, it would be welcome work indeed!
>
A couple of days ago I ported swingx to 1.4. It was relatively straight
forward. Not much usage of 1.5 at all passed some generics and
annotations. The few places where 1.5 method calls where used where the
JXLoginPanel and some methods in WindowUtils, but as I don't use them I
just commented them out. I took a look at the jdnc source as well but
that seems to use 1.5 to a far greater extent, and as I don't really use
any of the JNComponents I didn't really bother.

I've put a binary and a source jar of swingx up on my university account
for anyone that is interested. Unfortantly this isn't an offer to
maintain them. I really don't have the time or the interest :) and I am
in the middle of my exams. And after I'm starting full time work.

One other thing this version contains a couple of things that I've
added. First is in Sorter.java, to stop a class cast exception when
sorting column in a JXTable where the cells don't contain all of the
same type. The second is to JXTable its self, I've added a couple of new
methods called packColumn, and packTable and modified the headerListener
so that double clicking on the resize handle resizes the column to it
best fit. The pack code isn't all mine, I got it from somewhere. Java
Almanac I think.

The links are
http://www.csd.abdn.ac.uk/~cs01mth/swingx.jar and swingx-src.jar

Cheers
Mark Hillary

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

kalyan
Offline
Joined: 2003-06-10
Points: 0

Do you still have this backport of SwingX to 1.4? The URL you gave did not work.

let me know,
thanks and regards,
-kalyan

Hasadiah
Offline
Joined: 2006-02-14
Points: 0

Hello,

I'd really appreciate it, too, if you could provide a possibility to download the ported swingx.

Thanks in advance if you can make it possible.

rbair
Offline
Joined: 2003-07-08
Points: 0

>For a product to choose to track the latest release is one thing, but for a library project, it is not the smartest decision

Going with 1.4 would have been the better short term choice. We believe going with 1.5 is going to be the better long term choice.

> Also, it is worth pointing out, that by targeting
> 1.5, JDNC is limiting
> itself to the pool of people who are either
> (a) experimenting
> or (b) starting a new project.

or (c) have or are migrating to 1.5

> i.e. within the broader java community, it is not
> likely to get a great
> deal of "real-world" testing for quite some time.

Time will tell

> I just don't see that 1.5 is of such great usefulness
> to JDNC to warrant
> the downsides.

It's always possible that we could fire up a 1.4 branch. However, we don't have the resources to manage a branch, and there can very well develop incompatibilities between the two. If somebody with a vested interest in 1.4 wanted to port the code in the incubator, it would be welcome work indeed!

Richard

dmouse
Offline
Joined: 2003-06-09
Points: 0

> It's always possible that we could fire up a 1.4
> branch. However, we don't have the resources to
> manage a branch, and there can very well develop
> incompatibilities between the two. If somebody with a
> vested interest in 1.4 wanted to port the code in the
> incubator, it would be welcome work indeed!
>
> Richard

There is already a 1.4 branch named [b]JDNC-Java14-Branch[/b]. I'm not volunteering to port the code in the incubator, especially since I finally got on 1.5 for the Mac, but I did want people to know the branch is available.

rbair
Offline
Joined: 2003-07-08
Points: 0

Hey Pete

> (whether or not this upgrade policy is stupid and
> short sighted is not the question, only that it is
> the environment that people have to work in)

More appropriately, "it is the environment that [some] people have to work in". Whether it is the more common, or less common case is not clear.

> The short term for some companies is five years.

The short term for others is 2 years. For others, 1 year. For others, they are already on 1.5 (reasonably large companies/installed user bases too, I might add).

Richard

evickroy
Offline
Joined: 2004-07-23
Points: 0

>
> The short term for others is 2 years. For others, 1
> year. For others, they are already on 1.5 (reasonably
> large companies/installed user bases too, I might
> add).
>
> Richard

We're a Fortune 500 company and we are using 5.0. We'll be using JDNC very shortly if I can Swing it. ;)

Noel Grandin

Hear, hear.

It takes a considerable amount of time for companies to upgrade VMs.
We're lucky - at least we're on 1.4, but because we're a "downstream"
supplier, we have to wait for our upstream clients to upgrade before we
can follow. The only reason I'm able to use JDNC is because my current
project is for a new client.
As soon as it's over and I shift back to regular projects, I won't be
using JDNC any more.

For a product to choose to track the latest release is one thing, but
for a library project, it is not the smartest decision.

Regards,
Noel Grandin

jdnc-interest@javadesktop.org wrote:

>>otherwise just install 1.5 (not very tricky ;) )
>>
>>
>
>Approximately which planet are you from?
>
>At work, we have ~100,000 desktop machines, and rolling out any new software costs around half a million pounds. By the end of the year we hope to have all the machines upgraded to 1.4.2 from their current Microsoft VMs (which means I'll finally get to use ArrayList rather than Vector for applets), and that is only being rolled out because we're upgrading from Windows NT to XP. For reasons that are opaque to me, the developers are the last to get the new OS, so there is no version of Java 1.5 available for any of the desktop machines I use. It is unlikely that 1.4 will be upgraded across the board until it goes out of support.
>
>(whether or not this upgrade policy is stupid and short sighted is not the question, only that it is the environment that people have to work in)
>
>At home, I use OS X, so only just found out that the new release of JDNC (I normally use java server side, and thought I'd upgrade my tree table in case they've fixed the bugs). Now I can't build it without faffing around getting ant to point to the new compiler at home, and none of my works machines will run it, so there's no use.
>
>It took a written business case, and about five meetings and compulsary enrollment on a software licensing legal awareness course for me to get JDNC 0.6 past our managers and procurement licencing team and in use on a product (hopefully next time will be faster now they know that LGPL doesn't mean we have to give all our source code away), but now there's no hope of getting any bug fixes for the next few years until corporate HQ decides to move to 1.5.
>
>
>
>>I don't understand what the big deal is about upgrading.
>>
>>
>
>Do you ever do any work for large companies?
>
>
>
>>In the long term 1.4 compatibility will be of marginal value.
>>
>>
>
>If half a million pounds is marginal to you, give me your pocket change.
>
>The short term for some companies is five years.
>
>I really wish I'd checked in earlier.
>
>
>Pete
>---
>[Message sent by forum member 'pete@cafemosaic.co.uk' (Pete Kirkham)]
>
>http://www.javadesktop.org/forums/thread.jspa?messageID=80562
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
>For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
>
>

NOTICE: Please note that this email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html

If you cannot access the disclaimer through the URL attached
and you wish to receive a copy thereof please send
an email to email@peralex.com

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

netsql
Offline
Joined: 2004-03-07
Points: 0

I have been using retroweaver to develop on 1.5 and deploy to 1.4, it works fine.

.V

Noel Grandin

Which works fine for making template code backwards compatible.
But sooner or later, in such a GUI-intensive project, someone is going
to start using 1.5-specific method calls, even if it is only by accident.

(And I'd feel very nervous about a project which said that I had to run
it through a conversion engine before I could use it).

Also, it is worth pointing out, that by targeting 1.5, JDNC is limiting
itself to the pool of people who are either
(a) experimenting
or (b) starting a new project.
i.e. within the broader java community, it is not likely to get a great
deal of "real-world" testing for quite some time.

I just don't see that 1.5 is of such great usefulness to JDNC to warrant
the downsides.

Regards,
Noel Grandin

jdnc-interest@javadesktop.org wrote:

>I have been using retroweaver to develop on 1.5 and deploy to 1.4, it works fine.
>
>.V
>---
>[Message sent by forum member 'netsql' (Vic Cekvenich)]
>
>http://www.javadesktop.org/forums/thread.jspa?messageID=80968
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
>For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
>
>

NOTICE: Please note that this email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html

If you cannot access the disclaimer through the URL attached
and you wish to receive a copy thereof please send
an email to email@peralex.com

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

netsql
Offline
Joined: 2004-03-07
Points: 0

>
> I just don't see that 1.5 is of such great usefulness
> to JDNC to warrant
> the downsides.
>

Oh, I agree w/ you, it should have been for 1.42 like JDIC is.

On the plus side, since 1.5 did VERY little for Swing (it was mostly anotations, etc to try to save EJB)... there is not much new api in 1.5.

I have bigger fish to fry, like being able to deploy. (Webstart issues.... still in 1.6... years from now).
Things I can hack, I am OK w/.
It's just an ant task to fix it.

.V

Kleopatra

Scott Violet wrote:

> This discussion reminds me a lot of the transition Swing made when going
> into the jdk during the 1.2 days. It's worth sharing some of those
> stories. But first, a brief history.

speaking of history ...

>
> Swing was originally developed before 1.2 was released and outside of
> the jdk. As such Swing could not use the new 1.2 apis that were being
> developed (like the collection classes). Swing eventually made it's way
> into the jdk as part of 1.2 and needed to use some of the new APIs in
> 1.2. We wanted to support Swing on top of 1.1 and we only wanted one
> code base.

... I'm eternally grateful to the Swing Team that you did decide to
continue _support_ of Swing on top of 1.1. At that time I had decided to
use Swing for a medium size frontend including much highly interactive
visualization and control for a number crunching application (yeah I did
that as well, but that's another story) - not everybody was pleased, but
I'm a bit stubborn at times. Everything went smoothly (yeah, guys, it
was and is possible to do serious work with pre-tiger Swing!) until I
tried to upgrade to 1.2 which was a nightmare. As an side: In my
personal rating 1.2 was the worst version ever and did much to produce
the slow, unusable image that's dragging Swing until now. With the
continued support of the stand-alone Swing I could abort the effort and
revert back and got the project running in time ...

That said ... I have to admit that I'm warming up to the idea of a clean
cut (due to Richard's continously sent subliminal messages and good
arguments) Though it feels like letting down developers who now are in a
similar situation as I was 6 years ago: I change my vote on b) from -1
to +1 - always liked the extremes :-).

As I see it, that's an all-or-nothing path: we can try to keep the code
basis compilable to 1.4 as long as it does not hinder the progress of
jdnc, but that's a bit like cheating - it has the label "1.4" but not
the content because it does not _support_ the 1.4 runtime specialities
which would be eminently important in the Swing layer.

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Xendren
Offline
Joined: 2006-02-17
Points: 0

> A lot of end users are balking at 1.5.
> It takes 2 years after release of a JDK for it to be
> widley used.
>
> SO ... I have to switch back (non comiter) to 1.42
> and agreee w/ Kelopatra.
>
> It has to be 1.42 at run time.
>
> .V

I think the "balking" theory will be proven wrong shortly. The J2EE vendors really need to make their tools easier to use with so many frameworks floating around, not to mention competition with .NET. I think J2EE 5.0 will ensure they'll adopt Tiger in less than 2 years. Many of the major IDE's support it now, or will by the end of the year. Oracle, for instance, will have "native" 1.5 support within JDeveloper 10g by the end of the summer. It took them 3 years to adopt 1.4, so if Oracle is committed to adopting 1.5 this soon... ;-)

rbair
Offline
Joined: 2003-07-08
Points: 0

Here's another compelling reason for going to Java 5 for JDNC: annotations. It has occurred to me that the use of annotations on a class could be used to describe the MetaData for that JavaBean, much like the database schema forms the basis for MetaData coming from a database.

Using this sort of development process, the developer simply annotates her classes with validation rules and descriptions, titles/labels, default values, nullable/not null flag, etc. Through the use of reflection at runtime the MetaData is discovered and constructed from these annotations as well as the normal reflection information (such as property name, etc).

The benefit of this approach is that various tools could be written (though not by us) for reading annotations and constructing a database schema based on the same information. JDO, for instance, might do such a thing. Although, for this to be of any real use we'd all have to be using the same annotations.

Just thinking...
Richard

wsnyder6
Offline
Joined: 2004-04-20
Points: 0

> Here's another compelling reason for going to Java 5
> for JDNC: annotations. It has occurred to me that the
> use of annotations on a class could be used to
> describe the MetaData for that JavaBean, much like
> the database schema forms the basis for MetaData
> coming from a database.
>

Hey,

We actually do something like this for the JavaBeanDataModel using xdoclet and beaninfo tags...makes life a _whole_ lot easier!

-1 for 1.4
+1 for 1.5

--Bill

dhall
Offline
Joined: 2006-02-17
Points: 0

I've been trying to support both 1.4 and 1.5 with the jga library for a while and it's a hassle, particularly to test the compatability jar against a 1.4 development/runtime environment. I've been using an old version of the early access 1.5 compiler since it had an semidocumented command line argument that produced non-generic source from generic source -- I use that to generate a completely non-generic test framework from the standard test framework source (which is then compiled and run using the compatability jar and a 1.4 development environment).

I end up observing a few limits in what I can do syntax wise in the standard test framework in order to live with the bugs in the early version of the compiler, but thats far easier than maintaining two separate test frameworks. Since we're not looking at a realistic 'production' date for several more months, I'd say that JDNC doesn't need the extra hassle.

-1 for 1.4
+1 for 1.5

Dave Hall
http://jga.sf.net/
http://jroller.com/page/dhall/

bino_george
Offline
Joined: 2003-06-16
Points: 0

-1 for 1.4
+1 for 1.5

Regards,
Bino.

rbair
Offline
Joined: 2003-07-08
Points: 0

Here's the vote count:

on maintaining 1.4 compatability:

9 "No" votes, 3 by committers
3 explicit or implicit "abstain" votes, 1 by committer
0 "Yes" votes

on moving to Tiger:

0 "No" votes
0 "Abstain" votes
12 "Yes" votes, 4 by committers

The motion to move to tiger for both design-time and runtime passes unanomously. Have fun inserting enhanced for loops :)

Richard

netsql
Offline
Joined: 2004-03-07
Points: 0

A lot of end users are balking at 1.5.
It takes 2 years after release of a JDK for it to be widley used.

SO ... I have to switch back (non comiter) to 1.42 and agreee w/ Kelopatra.

It has to be 1.42 at run time.

.V

Kleopatra

jdnc-interest@javadesktop.org wrote:
> A lot of end users are balking at 1.5.
> It takes 2 years after release of a JDK for it to be widley used.
>

yeah, I agree ...

> SO ... I have to switch back (non comiter) to 1.42 and agreee w/ Kelopatra.

... nevertheless I switched my vote My main concern is that we don't
have the (wo)menpower to actively maintain two versions - going 1.5 will
let us formally off the hook.

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

netsql
Offline
Joined: 2004-03-07
Points: 0

Hmm.

I am considering having a fork that is 1.4 of SwingX on sf.net under same license.

Right now it's 1.4! And
target="1.4" source="1.4"
in build will keep us honest, which is what JDIC has in it's builds. (I too have 1.5 installed, but I just targe 1.4 in Eclipse)
As I note things that are not, I would clean up. ( I imagine mostly the generics stuff )

So I volunter to maintain 1.4 verion of SwingX (that is not entire JDNC). If you give me a spot in JDNC incbuator, I could do it there and grant rights to Sun also. I don't want to raise any dust later, so if there are comments now, I want to encourage Sun to leverage O/S for it's benefit. In general things that are good for Sun Java are good for us.

(and thank you for your contributions Kleopatra, I rather like them!)

.V

budulinek
Offline
Joined: 2004-02-15
Points: 0

Dear Jeanette,
you write

>My reasons:
>a) we need 1.4 compatibility.
>b) any move into the 1.5 direction will effectively mean >to maintain two versions.

would you be so kind and explain who exactly is the "WE"? being at that you may also mention the WHY bit to add some credibility to your vote.

As for my negligible vote - would use similar reasoning as Nicola:

>1) -1
>2) +1
>Reason1: why base an API that might go in JDK1.6 on a JDK1.4 API?
>Reason2: Swing still has bugs, that are much less in 1.5. >If we want a good user experience, 1.5 is IMO the
>minimum needed

Milan

Kleopatra

Hi Milan,

>
> would you be so kind and explain who exactly is the "WE"?

you got it right: it's a pluralis majestatis! SCNR

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

awf999
Offline
Joined: 2003-07-06
Points: 0

jdnc-interest@javadesktop.org wrote:
> 1) Require J2SE 5 for the developer, but use only 1.4 API's until some future time so that JDNC apps will run on 1.4 JVM's
> 2) Require J2SE 5 for both developers and end users.

My non-binding votes:
1) -1
2) +1

David Staelens

> jdnc-interest@javadesktop.org wrote:
>> 1) Require J2SE 5 for the developer, but use only 1.4 API's until some
>> future time so that JDNC apps will run on 1.4 JVM's
>> 2) Require J2SE 5 for both developers and end users.
>
My non-binding votes:
1) -1
2) +1

Cheers,
Dave

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Scott Violet

This discussion reminds me a lot of the transition Swing made when going
into the jdk during the 1.2 days. It's worth sharing some of those
stories. But first, a brief history.

Swing was originally developed before 1.2 was released and outside of
the jdk. As such Swing could not use the new 1.2 apis that were being
developed (like the collection classes). Swing eventually made it's way
into the jdk as part of 1.2 and needed to use some of the new APIs in
1.2. We wanted to support Swing on top of 1.1 and we only wanted one
code base. To accommodate this we had a preprocessor that would strip
out 1.2 specifics for 1.1. As you could imagine this was a nightmare.
Additionally not being able to use the collection classes forced design
constraints on us. Had we started development of Swing after the
collection classes things would have been different.

I suspect the same holds true of JDNC now. If you don't start using
some of the 1.5 features now, like generics, you may make design
decisions that will be tough, if not impossible, to change later on down
the road. Additionally by the time JDNC is at version 1.0 JDK 1.5 will
have been out for quite a while.

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Patrick Wright

This is actually in reply to Richard's proposal to a vote; it will be
threaded incorrectly on the mailing list because I can't find that email
he sent (and for some reason, my login to java.net does not carry over to
the forums).

I think the arguments in support of generics (but also the new for loop,
static imports, etc. to reduce clutter) is the decision maker for me. More
to the point, JDNC will be competing, in short time, with XAML from
Microsoft. Doesn't MS have a history of forcing upgrades on users when
they release new APIs? JDNC has to be top-notch, and if JDK 1.5 features
make developers more productive, the code easier to develop and maintain,
that is a big plus in my book.

My (non-binding) vote is to require 1.5 for building but support 1.4 for
deployment. More generally, always support the last full-release of the
JDK but use the most current one for building.

I realize there is a downside for developers who want to contribute to
JDNC but who, for other reasons, are normally using JDK 1.4 for
development. But again, code simplicity and maintainability are paramount
in this sort of project.

FWIW
Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Hi Richard,

I'm slowly switching from holiday mode back to working mode :-)
Nevertheless my votes to both currently are clearly -1, sorry folks.

My reasons:
a) we need 1.4 compatibility.
b) any move into the 1.5 direction will effectively mean to maintain two
versions.
c) developing in 1.5 and using only 1.4 features does not change b)
principally, only moves the issue from compile to runtime - in
particular we will have two sets of bugs to "support".

Jeanette

PS: A healthy and successful New Year to all! (I'm a bit reluctant to
use "happy" in view of the end of the Old - want to express my sincerest
sympathy with anybody affected).

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rbair
Offline
Joined: 2003-07-08
Points: 0

> a) we need 1.4 compatibility.

Do we?

Kleopatra

jdnc-interest@javadesktop.org wrote:
>>a) we need 1.4 compatibility.
>
>
> Do we?

short question - short answer: yes, I think so :-)

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Nicola Ken Barozzi

Kleopatra wrote:
> jdnc-interest@javadesktop.org wrote:
>
>>> a) we need 1.4 compatibility.
>>
>> Do we?
>
> short question - short answer: yes, I think so :-)

I don't know here, but at Apache a veto has to have a technical
explanation, else it's void... unless this is majority voting and it's
just a vote.

--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Nicola Ken Barozzi wrote:

>>>>a) we need 1.4 compatibility.
>>>
>>>Do we?
>>
>>short question - short answer: yes, I think so :-)
>
>
> I don't know here, but at Apache a veto has to have a technical
> explanation, else it's void... unless this is majority voting and it's
> just a vote.
>

Here no formal rules are defined - yet. And I don't really care which
rules will be agreed on.

Technically speaking, the arguments for compatibility were already
mentioned in this thread, I need no need to repeat them. Plus,
non-compatibility is a show-stopper in contexts where it is needed (or
perceived to be needed).

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rbair
Offline
Joined: 2003-07-08
Points: 0

>>>a) we need 1.4 compatibility.
>>
>>Do we?
>
>short question - short answer: yes, I think so :-)

Ok, let me play devil's advocate for a moment here. There's no question in my mind that 1.4 compatiblity would garner a greater user base. Or that 1.2 compatibiltiy would have an even bigger user base. Without any real data we can't make a good case for whether there are enough people out there who would absolutely not use JDNC if it works with Java 5+ only. Likewise, we can't definitively say that they would use it. Making a decision based on our own perceptions is a recipe for disaster, because what is being discussed is marketing, not engineering. In the world of marketing, focus groups and polls rule.

Rather, lets discuss whether the API would be better off in Java 5 than it is in 1.4. Because while user's [b]will[/b] eventually migrate to 5, the API [b]will never[/b] break backwards compatibility. Thus, from the engineering standpoint, what is the right choice?

As far as I can tell the only thing API-wise that we may or may not benefit from in Java 5 that is not available in 1.4 is Generics. It may be possible to retrofit Generics on -- then again it may not be. Take the Validator code, for instance. Hans is suggesting a generified version. Can a 1.4 version be written that we could later add generics to without breaking compatibility?

If we commit to 1.4 now, will the API ever be able to be moved to Java 5 without breaking compatibility? If it can be, then we most definately should use 1.4 and let developers compile to 1.5 if they want to in order to take advantage of bug-fixes and such. However, if we cannot take advantage of Java 5 (generics etc) in our API in the future, then we either cut to Java 5 now, or intentionally handicap JDNC at the outset. Hmm... sounds drastic :)

This is where the "compile with 5, but don't use any 5-only API's so that I can compile to 1.4 bytecode" argument comes from. At least then we get to use Generics in the API and still support legacy 1.4 clients.

No matter what version we cut to now, will we ever in the future require a newer version? Two years from now, will we cut support for Java 5 and support only Java 6?

Richard

rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> As far as I can tell the only thing API-wise that we
> may or may not benefit from in Java 5 that is not
> available in 1.4 is Generics.

Don't forget the JAXP apis. Anyone serious about XML and web services should move away from Crimson, and on to JAXP 1.3.0 -- That means using JDK 1.5.

> 1) Require J2SE 5 for the developer, but use only 1.4
> API's until some future time so that JDNC apps will
> run on 1.4 JVM's

My vote: -1 for using only 1.4 APIs. By the time JDNC 1.0 ships, I expect Tiger to have a substantial installed base.

> 2) Require J2SE 5 for both developers and end users.

My vote: +1 because it is a nightmare to support both Crimson and Xerces because the DOM element impl classes are different in Crimson and Xerces. Java only supports single inheritance, and that has implications on the element implementation classes for the XML portion of JDNC. Because this has both API and runtime implications, we will need J2SE 5 for both developers and end users.

Ramesh

netsql
Offline
Joined: 2004-03-07
Points: 0

RBair,

But developers utimate clients are end users.
What is the penitration of 1.5 on users desktop vs 1.4
(vs <1.3)?

(for example flash vendors claim something like in the high 90% of PCs. They say Flash v7 is only on 70%).

If I can't develop an beta appliction for my clients I can't make money.
For example, Struts v1.26 works on JDK 1.3 and that is server side. Client side is even more legacy.

So I am very -1 on 1.5 for version 1.0. But I think v. 1.1 can be 1.5. I know Cool factor but... we are profesionals.

.V

rbair
Offline
Joined: 2003-07-08
Points: 0

> For example, Struts v1.26 works on JDK 1.3 and that
> is server side. Client side is even more legacy.

Here I'll have to respectfully disagree. As a general rule, I believe that client side users are much more likely to upgrade to the latest version of Java in order to run their application than a corporation is.

> So I am very -1 on 1.5 for version 1.0. But I think
> v. 1.1 can be 1.5. I know Cool factor but... we are
> profesionals.

Fair enough.

Thanks V.,
Richard

netsql
Offline
Joined: 2004-03-07
Points: 0

Rbair,

Would you test on 1.42 and fix bugs on 1.42 deployments?
I am not able to see how you would ensure 1.42 run time w/o developing in 1.42, things can sneak in.
Security sandbox is diferent, rt.jar classes are diferent ....

Idealy 1.5 is fine in a perfect world; but 1.42 is more practical to ensure productivity.
.V

rbair
Offline
Joined: 2003-07-08
Points: 0

Hi V,

> Would you test on 1.42 and fix bugs on 1.42
> deployments?

Ya, that's the idea. The main #1 reason why I want to develop on 1.5 so much is so that the API's we write will be able to take advantage of Generics. Things like enhanced for loops etc could easily be refactored in later, but being able to construct the API's based on generics now would be IMO a big deal. Once we release the 1.0 API's, we're stuck with them forever.

For certain things you could drop generics in later (like they did for the collections API), but for other things you need to design for it up front (see the DataSource code in the incubator for rationale).

> I am not able to see how you would ensure 1.42 run
> time w/o developing in 1.42, things can sneak in.
> Security sandbox is diferent, rt.jar classes are
> diferent ....

Absolutely, this is something that can be a bit tricky to do at first. I've been writing code in 1.5 since the first beta's were released, and it was tricky to get the master/detail demo written so that it would run in 1.4. But its certainly not impossible.

I definately agree with the idea that by requiring 1.5 to build the project, we make it so that all developers that want to use JDNC but have to deploy to 1.4 will have to become experts at knowing what API's in the JDK are for 1.5 and which are for 1.4, and that this is a bad thing.

On the other hand 1.5 will be almost a year old by the time we release 1.0. To be stuck with legacy API's a year after 1.5 was released seems unreasonable to me. I know that some corporate environments are still on 1.3 or, gasp, earlier versions of java. But if we design JDNC for these slow moving corporate environments, then we reap none of the enhancements that have been going into java for the past 36 months!

In the end I think this is the best compromise. Going forward it will please the most people, though it may be rough at first for some. Now, if an IDE out there was smart enough to recognize API's that are 1.5 only so that when you were using 1.5 but compiling to 1.4 it would complain...that would be ideal.

> Idealy 1.5 is fine in a perfect world; but 1.42 is
> more practical to ensure productivity.

I think I can agree with this statement, for today and in the corporate environment, but how long will it take before 1.5 is more practical? If we say that it takes, on average, 2 years for a new JDK to make its way onto corporate desktops, then JDNC using 1.5 for compiling will be a headache for about 8 months (1.0 relese + 8 months + 4 months development = 2 years), assuming that it takes 4 months to get the application written.

Now assuming that we are talking about end-users (mom and pop and grandma), then the issue is a non-start because these types of users are used to upgrading to the lastest version of iTunes, flash, whatever all the time. So asking them to upgrade to the latest version of Java is not a problem at all. For developers hitting this market (or the small business market), its much more important to develop on the latest version of the JDK to take advantage of the bugfixes, speed improvements, look and feel improvements, etc. For these types of developers the simplified (and safer) API's we get using generics etc will be a big selling point.

Its not an easy decision, but for me backwards compatibility is the deciding factor. Backwards compatibility is a huge ball and chain that drags every project once released, and I'd rather start with a really short chain (that will be 1 year "long" at the time of release) rather than a fairly long chain (about 4 years long at the time of release).

Richard

rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> The main #1 reason why I want to
> develop on 1.5 so much is so that the API's we write
> will be able to take advantage of Generics. Things
> like enhanced for loops etc could easily be
> refactored in later, but being able to construct the
> API's based on generics now would be IMO a big deal.
> Once we release the 1.0 API's, we're stuck with them
> forever.
>

OpenMarkup has already moved to 1.5, for pretty much the reasons Rich mentioned above, and there is no turning back! If JDNC moves to 1.5, it will make it that much easier to integrate the new forthcoming version of OpenMarkup into it.

>
> On the other hand 1.5 will be almost a year old by
> the time we release 1.0. To be stuck with legacy
> API's a year after 1.5 was released seems
> unreasonable to me. I know that some corporate
> environments are still on 1.3 or, gasp, earlier
> versions of java. But if we design JDNC for these
> slow moving corporate environments, then we reap none
> of the enhancements that have been going into java
> for the past 36 months!
>

Well said. Don't forget that 5.0 includes WebRowSet, Table printing, lots of important WebStart fixes, and so on.

>
> Backwards compatibility is a huge ball and chain that drags
> every project once released, and I'd rather start
> with a really short chain (that will be 1 year "long"
> at the time of release) rather than a fairly long
> chain (about 4 years long at the time of release).
>
> Richard

As for the XML layer, most of you probably already know that J2SE 5.0 does not ship with Crimson. So, this means shipping a separate jar with your 5.0 applications (see below). I'd imagine that WebStarted apps, in particular, would prefer not to drag along a ball and chain wherever they go.

If you do not upgrade to 5.0, but want to use the fixes and enhancements to OpenMarkup, you will have to ship a hefty 2 MB jar file for Xerces along with your application. I'll explain the reasons for this in the release notes.

If you do upgrade to 5.0 and the new OpenMarkup, you will rejoice that Xerces is included in the JRE, except when your customers are still deploying to 1.4x. In that case, you will still have to ship a legacy jar containing Crimson, but that is much smaller.

The only time you will be able to drop the ball and chain altogether is when you either stick with the status quo (JRE 1.4, and the current version of OpenMarkup), or upgrade (JRE 5.0, and the new version of OpenMarkup).

That said, I hear it loud and clear that backwards compatibility is very important to some of you. So, I propose that we keep both the old and new versions of OpenMarkup, and let people decide when they want to move to 5.0. Perhaps somebody can contribute by backporting fixes to the old version?

Please let me know what you think.

Ramesh Gupta

netsql
Offline
Joined: 2004-03-07
Points: 0

No 1.5.
It does not run on all the platforms.

v1.42 is deployed more and that should be the minimum.

Flash is deployed on more places than 1.5.
(there is no way to 'there is a new version of java vm, do you want to update to 1.5.1?)

.V

rbair
Offline
Joined: 2003-07-08
Points: 0

Hey,

So, if we always compiled to 1.4 binary compatability, and did not use 1.5 apis, would that suffice? In essence we require 1.5 to *build* the JDNC apps, but only require 1.4 to *run* the apps.

I think its fair to ask developers to build with the latest release.

Richard

Patrick Wright

Richard

There are all sorts of issues that were brought up on this idea before, to
summarize a couple:

1) corporate ennvironments will adopt tiger slowly; swing and jdnc are
corporate-app targeted, so no hurry to move to it

2) jdnc will take awhile to reach 1.0; if you wait till 1.x or 2.0 to use
tiger features, you will not be using tiger until 2006 or so, which seems
counter-productive for a Sun-sponsored project.

So, IMO

- definitely use tiger features and compile to 1.4 binary compatibility

- when there is a proposal to use a 1.5 API, let there be a specific
discussion about the pros and cons. in 1.5 offers strong advantages,
consider some sort of facade to provide compatibility with 1.4 to cover
that API

Patrick

> Hey,
>
> So, if we always compiled to 1.4 binary compatability, and did not use 1.5
> apis, would that suffice? In essence we require 1.5 to *build* the JDNC
> apps, but only require 1.4 to *run* the apps.
>
> I think its fair to ask developers to build with the latest release.
>
> Richard
> ---
> [Message sent by forum member 'rbair' (Richard Bair)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=41921ꏁ
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> > We'd like to get your input on this decision.
> > Here are the pros/cons as we see them:
> >
> > Pros:
> > - access to many new features:
> > . web rowset
>
> I'm not familiar with web rowset unfortunately.

WebRowSet adds important XML support to CachedRowSet, which (through other intermediary interfaces) is an extension of the SQL ResultSet.

A WebRowSet is a "disconnected" rowset. It enables offline support for networked data sources (JDBC, spreadsheet, flat text files, ...), allowing disconnected clients to modify data in the cached rowset, and propagate those changes to the data source upon reconnection at a later time. A big advantage of WebRowSet is that it maintains a connection for only as long as is necessary to transfer the data back and forth between a cache and the underlying data source.

JDNC currently supports only data retrieval; support for data updates is conspicuously absent from JDNC. Since WebRowSets already provide the underlying infrastructure for updates to a data source, JDNC wants to leverage that rather than reinventing that infrastructure. So, WebRowSet support is important for getting offline capability as well the ability to push updates to the data source.

>
> > . xerces parser
>
> The Xerces parser is available on Java 1.3 and above
> (if not Java 1.2).
> An XML parser along with JAXP is available from 1.4
> .4 and above which
> will seamlessly upgrade to Xerces on Java 1.5.

Yes, but with a download that weighs in at over 2 MB, it is beyond impractical for most applets and web-started applications.

>
> > - WebStart fixes/enhancements
>
> Anything in particular?

The most important ones:

Single Instance Service -- This ensures that multiple invocations of the same application will cause new arguments to be passed to the original instance. This avoids the overhead of relaunching Java every time you click on a JNLP link.

Desktop Integration -- The JNLP file can now suggest desktop and/or menu and specify submenu names. Java Web Start applications can now register themselves to be the primary handler for specific MIME types and extensions on the desktop or file system. Finally, other related content, such as HTML links, native content, and related JNLP applications, can be included in the desktop integration of an application.

Import Facility -- Can be used for CD installs, where code is initially loaded from one location and then updated from another. It can also be used to pre-install applications and libraries in either the user or system cache without running the applications.

Full Printing Support -- A JNLP sandboxed applications enjoy full print support using the Java Printing APIs; previously they could only use JNLP printing APIs.

> > - 1.5 not yet available on OSX
>
> This is the big killer. Sun hasn't even managed to
> finalize 1.5 so it's far too early to expect any of the
> other Java vendors to have a version ready.

Yes, this is a big issue. While I think Sun needs to work more closely with other Java vendors to ensure timely support for new JREs, the onus is equally on Mac OS X developers to push Apple to provide timely developer/early-access releases. Apple is providing a developer preview of a "headless" version of their 5.0 release for Java, but for client-side developers that's a yawn.

Ramesh

Patrick Wright

I think Adrian's well-thought out note on binding JDNC to Tiger is useful
for the discussion. However, I want to throw in $0.02 that might spin it
slightly differently.

As I see the marketing of Java from early on, it was intended primarily
towards a corporate development environment. The effort to bring Java to
widespread consumer use largely failed; it did not, for example, become a
VB-like platform for developing small desktop applications for consumer
use, Flash appears to be far more widespread than applets for animating
desktop pages (and, to a great degree, more suited to that). I understand
that J2ME is deployed on a great many cell phones, but that is another
market and toolkit entirely.

I do think that Sun saw an opening to replace the aging corporate busdev
languages/kits like PowerBuilder, VB, Delphi with a new, cross-platform,
network-aware, etc. kit.

My argument is based on this perspective. If JDNC is aimed at making rich
clients and Swing an interesting development platform for the corporate
environment--'business' applications--then I agree with Adrian that it
should be bound to JRE 1.4, as the corporate IT environment is slow in
moving to new anything, and there are people still on 1.1, .2, .3, etc.

But if Sun is trying to do something new by re-entering a
consumer-development environment, then I suggest that taking advantage of
the latest JRE makes sense. For consumers, I think that we programmers
*want* them to be using the latest JRE at any time, what with memory usage
improvements, performance and langauge improvements, etc. And consumers
will basically not be worried about upgrading to a new version of
something like Java, as it is just a background process for them anyway.

The current release cycles for both the JDK and related libraries is very
long. Competitors in the rich-client field are moving right along...

So, for my vote--I think that the corporate busdev market is largely not
tied to Swing and rich clients anyway, so why not try to develop a good
consumer market for Java apps?

+1: make JDNC 1.0 take advantage of JDK 1.5 features

Patrick

I realize this may sound like flame bait, but that is not my intention.

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

alainasl
Offline
Joined: 2006-02-17
Points: 0

Hi,

another major problem with Rowsets is the way, deleted, inserted and updated rows need to be retrieved.

It is mandatory to scan the whole Rowset and query
each row on it's state. In a distributed environment the Rowset travels back and forth and the server needs to scan the Rowset in order to insert, remove and/or update the rows. This is very costly especially when a small amount of changes are made on a given large set of retrieved data.

The Rowset should have one of the following:

1- The Rowset should have a method called getDeleted, getInserted and getUpdated which return a Rowset with only the rows that changed which then can be resolved
easily.

2- One method which return only the changes in a Rowset. If the situation is in a distributed environment only the changes are sent back to the server.

Of course the Rowset should have a more efficient mechanism of keeping track of changes then scanning the whole Rowset.

That said, i believe it is a good idea to move to Tiger 1.5 since there has been a lot of changes to the language and something as new as JDNC should be taking advantage of the latest changes. It is not a good idea to have JDNC released and be outdated already especially when other technologies are moving ahead at full steam.

Alain A.S.

MerlinMustang
Offline
Joined: 2006-02-17
Points: 0

There really shouldn't be many 1.4 apps that won't run on 1.5. I could understand if you had a compatibility issue, otherwise just install 1.5 (not very tricky ;) )
I don't understand what the big deal is about upgrading.

In the long term 1.4 compatibility will be of marginal value.

BTW: I would love to be able to use enums to set property values.

pete@cafemosaic...
Offline
Joined: 2006-02-14
Points: 0

> otherwise just install 1.5 (not very tricky ;) )

Approximately which planet are you from?

At work, we have ~100,000 desktop machines, and rolling out any new software costs around half a million pounds. By the end of the year we hope to have all the machines upgraded to 1.4.2 from their current Microsoft VMs (which means I'll finally get to use ArrayList rather than Vector for applets), and that is only being rolled out because we're upgrading from Windows NT to XP. For reasons that are opaque to me, the developers are the last to get the new OS, so there is no version of Java 1.5 available for any of the desktop machines I use. It is unlikely that 1.4 will be upgraded across the board until it goes out of support.

(whether or not this upgrade policy is stupid and short sighted is not the question, only that it is the environment that people have to work in)

At home, I use OS X, so only just found out that the new release of JDNC (I normally use java server side, and thought I'd upgrade my tree table in case they've fixed the bugs). Now I can't build it without faffing around getting ant to point to the new compiler at home, and none of my works machines will run it, so there's no use.

It took a written business case, and about five meetings and compulsary enrollment on a software licensing legal awareness course for me to get JDNC 0.6 past our managers and procurement licencing team and in use on a product (hopefully next time will be faster now they know that LGPL doesn't mean we have to give all our source code away), but now there's no hope of getting any bug fixes for the next few years until corporate HQ decides to move to 1.5.

> I don't understand what the big deal is about upgrading.

Do you ever do any work for large companies?

> In the long term 1.4 compatibility will be of marginal value.

If half a million pounds is marginal to you, give me your pocket change.

The short term for some companies is five years.

I really wish I'd checked in earlier.

Pete

evickroy
Offline
Joined: 2004-07-23
Points: 0

Wow! ~100,000 desktops machines JUST to run a browser and a bloated Office suite?!? You guys are just bleeding cash! ;)

Since you're using Windows, can't you just use Active Directory to automagically push down whatever VM you want, when you want to?

netsql
Offline
Joined: 2004-03-07
Points: 0
dhall
Offline
Joined: 2006-02-17
Points: 0

netsql:

is there something in that flash that brings an important point to the table? If so, could you please just present it in text form?

I find that not having a flash plugin installed cuts way down on the advertising that I have to wade through, so I wasn't able to view whatever it was that you wanted so much for us to see.

Dave Hall
http://jga.sf.net/
http://jroller.com/page/dhall/