Roadmap...

[david.gilbert]

Seems you forgot the pan functionality.

Yes, momentarily, but it will definitely be done before JFreeChart gets the 1.0 label. Thanks for the reminder!

[Matthias]

In
http://www.jfree.org/phpBB2/viewtopic.php?t=2644
you wrote you "... managed to get the shapes in there [the legend], but still need to do some (not too difficult) work to get the stroke displayed as well...will do it when I find the time. "

I appreciate this intention and just wanted to remind you about this since you want to rework the legend anyway and I also would welcome JFreeChart being able to show the data point strokes in the legend.

[david.gilbert]

Thanks - it will be done.

[arnaud]

Hello,

As planned, I did update the code for the item label auto-range feature. The result can be found on the dedicated sourceForge RFE page.

To better understand how it works, I included (in the zip file) a documentation page to explain the algorithm. It will also help other developers to extend the feature to other renderer and rendering options.

Feedbacks are welcome !

Best regards,
Arnaud

[janakisri]

Although not very proficient in JFreeChart API , I want to help in doing some work in the areas of bug fix or simple functionality addition . If it is not too much trouble to introduce me to the problems .

Thanks

Sri

[david.gilbert]

There is a list of bugs here:

https://sourceforge.net/tracker/?group_ ... tid=115494

Anything you can fix will be appreciated!

[BengtRJ]

I am writing some classes that are JFreeChart api wrapers.

They are a "bridge" do get things done easy and fast. An example:

A ChartFactory class, that has some methods like:

Code: Select all

makeChart(java.util.Map data, Options options, short chartType)

The Options class that have various public fields like size, showLegends, showTooltips etc.

So, an example code:

Code: Select all

Options options = new Options(); //use default values
options.chartTitle = "Emails sent last hour";
ChartFactory factory = new ChartFactory(OutputStream out);//make the charts and write then into an OutputStream
Map chartData = new TreeMap();
chartData.put("With errors", new Integer(243));
chartData.put("Without errors", new Integer(5288));
factory.makeChart(chartData, options, ChartFactory.CHART_TYPE_PIE);

This approach has some advantages:
1) Decoupled interfaces: no matter how JFreeChart changes, my client's code could not care less: I just have to deploy a updated ChartFactory together with the updated JFreeChart jars, the factory act not only as a Factory but as an Adapter, because it has a steady public interface (remember Design Patters?)
2) Client code could easily choose dinamically the kind of chart to generate: just change ChartFactory.CHART_TYPE_PIE to ChartFactory.CHART_TYPE_BAR
3) It makes anyone capable of writing in 15 minutes code that generate good and customized charts: it took me 3-4 days to understand and make some customized charts work the way I wanted.

I understand that the approach is not perfect, but as soon as I finish this Factory, I could share it with you guys, if there's interest enough, maybe even make it to a JFreeChart release as a alternate way to make charts.

[nikster]

David,

i want to comment on thread synchronization. i might be somewhat biased because i currently don't need thread synchronization for JFreeChart. but i have done a lot of threaded programming, with a GUI application as well (e.g. data gets modified in N different threads, is displayed in event thread).

i feel that it should not be included in JFreeChart for the following reasons:

- JFC was not designed to be thread safe from the beginning so adding it now is more complicated
- testing of whether it "really" works or not will be pretty much impossible. JFreeChart already has tons and tons of features. They are great, but they make testing more difficult. testing threading behavior is notoriously difficult. in my environment, i have never seen bug-free code dealing with threading - most people seem to close both eyes and hope for the best...
- making things thread-safe by adding synchronized statements is not possible. you will just get deadlocks instead of thread errors.
- the only way (IMHO) to make an application using JFreeChart thread safe is to design it for that from the beginning. for instance, in the example where threads update a dataset which is being displayed by other threads, it's relatively easy to do with Swing.invokeLater(..).

on the other hand, if you try to get away without using Swing.invokeLater, it becomes very difficult and - and this is important - impossible test. the nature of threading bugs is that they appear infequently while on the same machine, but quite often as soon as anything related to threading changes (underlying machine implementation, JVM implementation, etc).

anyway, probably too late now...

[david.gilbert]

There are a few different types of threading issues I need to look at (please note I'm not a thread programming guru):

(1) Synchronising the update methods in classes like TimeSeries to ensure internal consistency. I think this is a relatively simple problem that can be dealt with by Java's 'synchronize' mechanism, but it won't deal with the larger problem outlined in (3).

(2) Allowing charts to be drawn by two or more separate threads simultaneously (e.g. paint the screen and save to PNG), but assuming the dataset is NOT updated. Here the issue is simply to ensure that the plot, axis and renderer classes store all drawing state information in temporary "thread specific" structures...there are still cases where this is not being done.

(3) Synchronising chart painting and dataset updates. This is the part I think you are addressing and it is a really hard problem. Essentially you need to lock the datasets (and remember that there can be any number of datasets in the chart/plot structure) from the beginning to the end of the JFreeChart draw() method. When I last looked at this, I thought a ReaderWriterLock of some sort would do the trick, allowing many threads to read the dataset (see (2) above) while locking it from write access, or allowing one thread to write the dataset but locking it from read access. As you say, it is really complex and impossible to know if it really works.

I read something somewhere recently about using Swing.invokeLater() to update the datasets in the same thread as the ChartPanel is being repainted...and that seems to me a good (or at least reasonable) way to address the problem for GUI development. For server side development I don't know - leave the developers to work it out?

Increasingly, I'm beginning to think that having a stable 1.0 API out the door is going to deliver more of a benefit (to most users) than solving (3) above, so I may drop this from the 1.0 roadmap.

Thoughts anyone?

[nikster]

i understand the issue of threading pretty well. in my experience, the best way to make multiple threads work is to keep it as dead simple as possible. Swing.invokeLater() is a good example of that. just move your dataset-updating code into Swing.invokeLater and don't worry about it.

as for the issues:

(1) i am not sure why you need to synchronize there? an example like "Thread1 changes the dataset, Thread2 paints" would be helpful.

(2) you never want to draw from more than one thread. i can see how servers definitely want to export as png from more than one thread though.

(3) maybe the strategy should be this: JFreeChart is not thread safe, but it also does not prevent clients from writing threadsafe code.

in order to facilitate thread safe code, we could provide a thread safe wrapper for ChartPanel / or JFreeChart (anyway, the topmost drawing class which cares about locking data).
we could then have an interface ThreadSafeDataset which declares methods lock() and unlock() and maybe a sample implementation that simply wraps or extends an existing dataset class.
the thread safe wrapper for the top level drawing class then calls lock/unlock on the dataset and the dataset makes sure that the internal state is not modified when its locked.

this would not even require any changes to JFreeChart classes. it just adds some new classes. it also doesn't add synchronization where people might not want it, which is a kind of insurance against bugs in the threading scheme.

i could then take the dataset and the thread safe top level drawing class and have my X threads reading and writing to and from that dataset and another Y threads creating thread safe drawing objects on that dataset and exporting them to PNG. i have an object which contains the creation methods for the drawing objects and each thread has an instance of it (e.g. no static factory).

note that each thread has its own threadsafe drawing object. e.g. thread sync happens between the object and the shared dataset. the drawing objects are never shared (nor meant to be shared), only the data is. that is important.

caveat: JFreeChart must not keep any state information in static variables. static variables (or other constructs that assume there is only one of ... in the system) have the tendency to kill multithreaded approaches...

my (somewhat long) 2c

[Guest]

This thread has the topic "Roadmap", so i hoped to find roadmap infos like version history and what's comming up.

Is there an existing roadmap for possible versions that still come between 0.9.20 and 1.0.0? Is there a planned date for releasing the 1.0 version (not just "in a couple of months" like i read somewhere else)?

If finally a 1.0.0 is released (with an API that finally doesn't change anymore), i would be happy to - once again - adjust my enhancements for 1.0 and -once again - post it to SourceForge.

This ongoing oh-no-another-0.9.x-version-with-possibly-changed-APIs-that-break-my-code "evolution" does not do any good for this library. with such experience, my boss is definitely not willing to pay for a developer license or even spent much more time for me to catch up the API for every new JFreeChart version.

[nikster]

1) i am pretty happy with the pace of development. i would be happy if we wait with 1.0 until several large scale changes that are currently underway are finished - such as full support for efficient implementation of large datasets.

2) there is no need to upgrade to each new verison. just use the latest version for your project, download the source code (in case you need to go in and fix something), make jar file, and just continue to use that until the project is finished.
there is no problem with the ongoing 0.9.x evolution - just know how to deal with it. if you update just for update's sake, that's your choice - not a problem inherent in the update schedule.

3) if we commit to not changing the API anymore, we better make sure it's a damn good API. this will be precisely the reason that people will continue using JFreeChart.

just my 2 ct

[Guest]

1) "large scale changes"??? oh no!
0.9 exists now for about 1 year (not x weeks or a few months) ...

2) of course there _IS_ need because of the lots of bugs that are hopefully fixed. I already wrote several workarounds and subclasses. but that's not the intention of a library. there's also no "way how to deal with it". the API changes and that's a big problem.

3) it's not about not changing the API anymore (with little changes), it's about not changing the architecture anymore (classes move, fields/methods vanish, etc.). there where several main architecture changes and sometimes it must be enough.

If sun would have changed teh API of Java just about 1% of how much JFreeChart changed during the last year, nobody would use Java. Compatibility is a major point in software. Of course, JFreeChart can continue breaking the API every now and then, but you can bet that noone would keep on changing their applications just for this reason. And that's the reason why i'm still stuck with 0.9.13. If there only would be documented migration code, you could say "okay, i make the upgrade because it's just a few amount of time to adjust your code." But the reality is, that we just get new versions and we have to find out ourselves what changed (the compiler throws errors) and find out how we can replace the old code with the new API and HOPE that all formerly working charts look the same with the changed code. IF all changes can be easily translated at all. And that's not the case (for classes that suddenly become abstract and methods that don't exist anymore).

Your point of view is to have a perfect library and this requires constant changes. As there is no perfect software, this leads to an every changing API. Users must (at some point) rely on a fixed API to be able to upgrade to a newer version (with fixed bugs, improved performance, etc.) without having to fix a broken API. See Suns Java SDK. There are lots of old, deprecated, not-so-perfect implementations. But they don't throw it out because existing applications need to run - also with newer version of the SDK/JRE. And those "old" applications keep running with the latest JVMs and benefit from the advancements of the latest JVMs (HotSpot, Memory, Speed, etc.). Even for some changes (like e.g. the newly introduced "enum" keyword), they offer a command line switch to ignore these new features that might break old code.

That's the way JFreeChart should also finaly go. It's time for a 1.0 version (after 1 year of 0.9.x versions). Subsequent changes need to be documented (@deprecated marks) but not only removed. This will lead to older applications still running with newer versions and benefit from bugfixes and other improvements. Developers can still use the new API (that replaces older classes/methods/fields).

Summary: API changes are evil (for released software). This leads to the fact that JFreeChart is still alpha software and should be marked as such.

[nikster]

point 1: don't post as "Guest". it lends more credibility to your arguments if we know who you are.

point 2: i agree that changing APIs of released software is evil. this is why the API has not been frozen yet, and why 1.0 has not been released. because we still need to change the APIs to make it better. it's not there yet.

point 3: i think we both agree that the API needs to be good enough before it is frozen. you think this is the case now, i think it's not.

if you are so inclined, i will discuss topics like the Java APIs or framework-philosophy in private. but i don't think this is the right forum for that, or that it adds anything to this discussion.

[BigWillyStyle42]

I'm sure Java's API went through similar changes before v1.0 was released.