Skip to main content

move to tiger?

69 replies [Last post]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
netsql
Offline
Joined: 2004-03-07

It's quite OT.
It's is funy video from MadBean blogger. (He also has a funny video on Swing). I used to have 100 funy videos in Flash.

There is not point in OT or funny. He made fun of the syntax Sugar in 1.5 that should be avoided.

Flash is not that bad. Nothing wrong with WebMasters making some $, it's not that easy to infleunce us to buy.

(I take it you won't be using Flex/Laszlo. Wait, I promise that advertisers will be writing ads in JDNC and LookingGlass. I might write one, just for fun. )

.V

rbair
Offline
Joined: 2003-07-08

Before we cut any 5.0 code to core JDNC, I'm going to create a 1.4 branch so that we still have somewhere to cut bug fixes for any existing 1.4 clients out there. Any objections?

Richard

Andy Depue

+1 To move JDNC to Tiger. JDNC needs to be competitive or developers will go
elsewhere. JDNC is a new platform and doesn't have a currently existing user
base which it must continue to support, so it is free to move on. I believe
that if you decide to be 1.4 compatible now and then move to 1.5 in the
future it will only create problems (and may never happen at all). If
anything, it could open up a nice market opportunity for someone to come up
with a solution to run JDNC on 1.4 VMs.

---------------------------------------------------------------------
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

I voted for 1.42... but now I want to reverse myself.

The main reason is:
WebStart deployment - There are so many issues deploying, and there is a chance that 1.5 team will listen to patch requests, while 1.42 ... won't get fixed.

I think rowset are not a good idea for DTO and won't get used in production apps. People will use Collections, Lists and Maps, like they do now.

So I vote to cut to 1.5 now, so we can have the new WebStart sandbox.

.V

rbair
Offline
Joined: 2003-07-08

We've talked about it, now its time to vote on it. We'd love to hear the input of everyone who cares, but of course only the committer votes are binding. Any -1 vote from any committer acts as a veto.

Two proposals:

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 votes:

1) abstain
2) +1

Nicola Ken Barozzi

jdnc-interest@javadesktop.org wrote:
> We've talked about it, now its time to vote on it. We'd love to hear the input of everyone who cares, but of course only the committer votes are binding. Any -1 vote from any committer acts as a veto.
>
> Two proposals:
>
> 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

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
Reason3: differently from the past releases, 1.5 already has a high
adoption rate

--
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:

> Reason3: differently from the past releases, 1.5 already has a high
> adoption rate
>

interesting - could you please point me to any hard evidence for that?

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:
> Nicola Ken Barozzi wrote:
>
>> Reason3: differently from the past releases, 1.5 already has a high
>> adoption rate
>
> interesting - could you please point me to any hard evidence for that?

I don't have stats, this is what I gained from reading blogs and mailing
lists. In any case, I meant that the 1.5 is getting adopted more rapidly
than other releases where when they came out.

In corporate sectors it's mainly because of the JVM monitoring
capability, and because it can tune itself better.
On the client because the startup and GUI percieved responsiveness is
much better.

In any case, we should target the JDK used not on the existing user base
configuration, but on what they will have when JDNC 1.0 will be
released. IMHO at that time JDK 1.5 will be prominent on the desktop.

--
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

Mark Swanson

> 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

C) cut JDNC to 1.5 now, but only use those features that are downgradable to
1.4 via retroguard. This lets you program using autoboxing and generics (and
more) and still work perfectly with folks using jdk1.4.

I've been building and deploying the ScheduleWorld client for over 3 months
now using JDK1.5. It's been nice to be able to rely on autoboxing (though
ints are converted to Float and you manually have to cast them) and _very_
helpful to rely on generics. It's easy to create a JNLP file that contains
1.4 (plus retroguard) and 1.5 jars. See the scheduleworld jnlp file for an
example.

Note that moving a large project to completely use generics might be a lengthy
process. It literally could take 6 months to pass the new -Xlint:unchecked
compiler checks if you move to generics a little bit at a time.

Thousands of folks per week start up the retroguarded ScheduleWorld client
using Java 1.4.x and I haven't received a single complaint, nor have I ever
seen a single problem doing this in all of my testing.

Just thought I'd mention the option...

Note: being jdk1.5 ready means you will likely need a few months working
around the differences in standard packages (java.util, javax.swing) as lots
of little differences will break your app. The more time you spend with
jdk1.5 prior to your release the better.

Cheers.

--
Free SyncML-capable replacement for Exchange and Outlook
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics

---------------------------------------------------------------------
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

Hey Everybody,

I wanted to resurrect this thread and come to a definate conclusion. By my count it was 4-2 in favor of using java 5, although the general consensus among those 4 was that it was ok to use Java5 constructs such as generics, but that we should NOT use Java5 only api at this time. So things like popup menus on components are out, but generics are in.

Is this a good compromise?

Richard

Patrick Wright

Richard

My impression was that the decision would in part be based on when the 1.0
release was due (which was waiting for the plan, now published).

I thought as well it would be more of a 1.5 release, with a 1.4
compatability layer supported for some time, or something like that.

FWIW
Patrick

---------------------------------------------------------------------
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

Hey Patrick,

> I thought as well it would be more of a 1.5 release,
> with a 1.4
> compatability layer supported for some time, or
> something like that.

That's my feeling as well.

jancarel
Offline
Joined: 2004-03-11

My vote is to stick to 1.4 for the moment; it seems to me that there's a lot you can still do which will not change under 1.5.
I would never have looked at JNDC at this stage if it could only be deployed under 1.5

dcurry
Offline
Joined: 2006-02-17

This depends on what JDNC 1.0 will deliver.

If the net effect of 1.0 is to make incremental improvements to ease Swing development as it is done today, then I'd agree that JDNC should be deployable on the J2SE 1.4.x platform.

But, personally, I would urge that JDNC 1.0 establish a new plateau for the rapid evolution of the facilities necessary for the Java platform to compete with .NET on the desktop. If this is the intent and 1.5 will help get it right the first time, then by all means cut to it now.

If corporate IT strategic spending recovers and the rich-client wave hits while Microsoft is ready and Java isn't, JDNC won't get a second chance.

Adrian Sutton

> 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.

I'd be very much against making JDNC dependent on 1.5 because it so
drastically limits the target audience for JDNC and thus it's developer
base as well. Forcing developers to force their users to upgrade the
JRE just makes Java look extremely incompatible and makes deployment
more difficult.

> 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.

> . 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 and above which
will seamlessly upgrade to Xerces on Java 1.5.

> . table printing

From what I saw of the Table Printing API at JavaOne it should be able
to work just by calling the print method on Java 1.5 without needing to
do much else. Either way this could likely be developed as a separate
add-on or in such a way that it degrades gracefully on 1.4 (ie: only
the printing feature breaks on 1.4).

> - generics for improving apis

Nice to have certainly but it is only syntactic sugar. No new
functionality is made available by generics. Is it possible to run
generics code on 1.4 systems? If so requiring 1.5 to compile isn't so
bad.

> - concurrency utilities

Definitely useful though much of this is available through Doug Lee's
libraries as well.

> - pack200 for huge download/compression improvements

My understanding was that this was available in JRE 1.4 but the tools
to create pack200 jars weren't available. If that's correct then it
would be possible to compile on 1.5 but still support 1.4. Even better
though would be to use a property in the build script to decide whether
to use pack200 or not.

> - WebStart fixes/enhancements

Anything in particular?

>
> Cons:
> - 1.5 hasn't gone final yet, thus most JREs out there haven't
> upgraded, forcing more
> JRE downloads for JDNC deployments

I think it's pretty safe to say that effectively no end users will have
1.5 yet. While JDNC won't hit 1.0 for a while, my experience with open
source projects is that people will start using it long before you hit
1.0 and that allows them to provide feedback to improve the product.
"Release early, release often" doesn't work if noone uses the releases.

> - 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. If you develop JDNC on 1.5 you won't get any feedback
from OS X users about platform specific assumptions that get made.
Swing already struggles to fit into the Mac OS model for applications
and it would be a big mistake to develop more GUI libraries without
taking OS X deployment into account (as well as Linux etc but they're
not at issue here).

> - Many won't move to 1.5.0 and will delay upgrading until a 1.5.X
> release,
> which isn't likely until 2005.

Many won't upgrade to 1.5 for many years. We still get customers
complaining that we don't support Java 1.1 (our competitors only just
dropped support). We still support Java 1.3 and are starting to
consider dropping that as well (which means dropping support for a
bunch of existing, paying customers).

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

Definitely stick with 1.4.2 unless there's very good reason to move to
1.5. JDNC is a library that's meant to be used in applications to make
developer's lives easier, it can't achieve that goal if people can't
use it. Take a look at the projects in Jakarta and particularly
Jakarta Commons (http://jakarta.apache.org/commons/) and see how few
require 1.4 even after this long. They are all components that are
designed to be reused and thus try to be as compatible as possible.

I particularly want to stress that most features that depend on 1.5 can
be provided in a way that's compatible with Java 1.4 even if it means
that extra jars are available on 1.4 (eg: Xerces) or by gracefully
degrading (that feature doesn't work on 1.4 but the rest does).

> [Message sent by forum member 'Aim' (Amy Fowler)]

Regards,

Adrian Sutton

----------------------------------------------
Intencha "tomorrow's technology today"
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com
[PGP.sig]

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

rbair
Offline
Joined: 2003-07-08

This one isn't going to be easy no matter which choice you make. For me, its 1.5 all the way (since it'll be stable by the time my product launches and I want all the goodies 1.5 has to offer). I'm sure, however, that there are 20 voices to every one of mine.

What is the possibility of compiling a binary jar with some of the sun code in 1.5 for use with JDNC in 1.4? As for generics, that only matters at compile time, right? I have no qualms asking JDNC developers to have 1.5 on their system for building JDNC.

I hope there is a solution that can bridge the 1.4/1.5 camp, because I'd hate to alienate the 1.4 crowd and I'd hate to see 1.5 go unused by a project that is trying to fill the gap for desktop apps.

If push came to shove I'd say stick with 1.4 -- but I or someone could maintain a 1.5 port once the api solidifies.

Rich

PS> WebRowSet is very unstable, and has some internal api problems that practically make it unusuable. For instance, if a RowSet is backing a DataModel that is used by a JTable, you will have poor performance. This is due to the fact that the only external methods for traversing a RowSet involve a lot of listeners -- there is no way to get the value at a specific row/col without moving to that row and then retrieving the value. Every row movement results in listeners firing etc. Due to this and other bugs I had to write my own row set impl. Ce, la vie.

Amy Fowler

jdnc-interest@javadesktop.org wrote:

>
> PS> WebRowSet is very unstable, and has some internal api problems that practically make it unusuable. For instance, if a RowSet is backing a DataModel that is used by a JTable, you will have poor performance. This is due to the fact that the only external methods for traversing a RowSet involve a lot of listeners -- there is no way to get the value at a specific row/col without moving to that row and then retrieving the value. Every row movement results in listeners firing etc. Due to this and other bugs I had to write my own row set impl. Ce, la vie.

Yes, we've discussed these issues internally with Jonathan Bruce (JSR114 spec lead)
and I hope we'll be able to resolve them over time, as CachedRowSet is something which
*ought to* work very nicely with rich clients. Have you filed a bug?

If there are no listeners registered for the cursor change events, do you still see
the performance problems? (we talked with Jonathan about ensuring no events were
fired if no listeners were registered). Obviously this is not the ideal solution.
What we really want is a way to *read* rows without moving the cursor.

Aim

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

Richard Bair

>Yes, we've discussed these issues internally with Jonathan Bruce (JSR114
>spec lead)
>and I hope we'll be able to resolve them over time, as CachedRowSet is
>something which
>*ought to* work very nicely with rich clients. Have you filed a bug?

Tried, but it got returned with a "Please provide code we can test with"
etc. Between deadlines and a lack of faith in the implementations (and the
fact that I can't see the source to solve the problems myself) I had to
switch gears and write my own implementation. I can't be tied to a JRE
release schedule for fixes in row sets.

>If there are no listeners registered for the cursor change events, do you
>still see
>the performance problems? (we talked with Jonathan about ensuring no
>events were
>fired if no listeners were registered). Obviously this is not the ideal
>solution.
>What we really want is a way to *read* rows without moving the cursor.

I don't remember whether I had listeners attached at the time of testing or
not, but I needed to have listeners attached. For instance, I have a table
and a bunch of components (text fields and the like). Whatever the current
row in the table is determines the current data in the text fields. As a
result, the rendering behavior would force all of the components to be
loaded/unloaded countless times.

Another thing I wanted that works out really well with JDNC's DataModel
framework was caching/reuse of rows between row sets.

I really REALLY wish that the row set implementations were open source. We
could solve a ton of problems that way and have a level of confidence in the
implementation that is currently lacking.

_________________________________________________________________
Planning a family vacation? Check out the MSN Family Travel guide!
http://dollar.msn.com

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