Piet Souris wrote:Just reading this topic, and I was wondering: have you by any chance VB6 around (or maybe even VB4.5)? Or do you know someone who does?
Then it would be a very easy job to read those files in uing VB and write them out as text (using the PRINT# statements).
You would need to know what's in those files, but if I understand correctly that's not the problem.
Greetz,
Piet
Bear Bibeault wrote:Those are still desktop apps. Sure, they are client-server in that they connect to a remote database. But they are still traditional fat-client apps rather than web-based thin-client SAAS web applications which, these days, most people will think of when you say "client".
My point is to be more precise when you use the word "client".
But if your point is just that JavaFX is taking over from Swing for the limited areas in which Swing is used, I have no insight into that area.
Bear Bibeault wrote:From Mark Reinhold’s Blog
I applaud this move. No one benefits from taking the cake out of the oven before it's done baking.
Bear Bibeault wrote:
Jay Orsaw wrote:Well I also want to add in what about FX? That seems to be where the Java world is headed, at least the Client side.
I'm sure you meant to say "Desktop". JavaFX will not be making inroads on the web as a client-side technology.
I would recommend that you use a JDBC driver provided by the vendor of your database or a commercial JDBC Driver instead of the JDBC-ODBC Bridge.
Pat Farrell wrote:
Jay Orsaw wrote:I had a computer science professor say that the entire architecture of computers could change at any time
While it is true that the probability that we will switch from a Von Neumann architecture to something else is non-zero, its also very small. Perhaps vanishingly small.
While folks toss around the term "architecture" of computers loosely, such as claiming that an ARM chip is a different architecture than an Intel X86, they still have a lot in common. The last attempt at a different architecture was Intel's VLIW machines, which failed to deliver the promised performance, and failed in the market.
If there is a wide acceptance of functional programming languages or object-oriented DBMS packages, then we could see a significant switch. But lately, all we have done is crank up the clock and add more CPU units. A 64 processor chip running Von Neumann architecture is still Von Neumann.
Bear Bibeault wrote:
Jay Orsaw wrote:And how many people still code C that's 40 years old? :P.
Many, many, many, many, many, many developers.
Ever hear of embedded systems? What do you think is running in your residential gateway? Your TiVo?
Even though Java was invented with embedded systems in mind, C still rules that roost.
Winston Gutkowski wrote:
Martin Vajsar wrote:How would the compiler know that the code being compiled was or wasn't modified after the introduction of Java++?
Not sure, but I can't imagine that a "Day 0" date would be too difficult to implement and then check against file mod timestamps; or indeed, introduce a new annotation ("@Java++' ?) for new source - although that would go against Bear's idea of obliging people to use the new syntax. Dunno...maybe a combination of the two...
Pat Farrell wrote:
Bill Clar wrote: Fortunately, this means we'll all have jobs for the next 20-40 years.
Yuck. Who in the world would want a job doing maintenance on 40 year old code written in a dead language? How many young programmers are dying to get jobs doing maintenance on 40+ year old COBOL systems?
If a language doesn't evolve, while the legacy installed base doesn't go away, it is never picked for new work. I've been a professional developer for 40 years, and I've been paid to write in about 30 languages. Any programmer who is smart enough to earn a salary is smart enough to pick up a new language.
Pat Farrell wrote:
Jay Orsaw wrote:I also tried just doing Calender rightNow = Calender.getInstance(); inside the look, that would keep creating new instances right?
Yes, it creates a new Calendar instance, but that is a cheap constructor. Calendar's data structure is not much more than a Date, its the member functions that are less insane than Date's.
Pat Farrell wrote:I see this as having a philosophical loop. How do you update the time every second, when you don't know what a second is? If you could set an interrupt every second, seems to me that you are already done.
And, of course, you are NOT suposed to to update the Calender.getInstance(), instead you should get a new instance every second.
Jeff Verdegan wrote:You could use a java.util.Timer and java.util.TimerTask to update the time once per second.
Java 5.0 introduced the java.util.concurrent package and one of the concurrency utilities therein is the ScheduledThreadPoolExecutor which is a thread pool for repeatedly executing tasks at a given rate or delay. It is effectively a more versatile replacement for the Timer/TimerTask combination, as it allows multiple service threads, accepts various time units, and doesn't require subclassing TimerTask (just implement Runnable). Configuring ScheduledThreadPoolExecutor with one thread makes it equivalent to Timer.