does Activeweb really need to be java 1.8?
I'd like to be able to use App Engine's standard edition[1], but it only supports java 1.7.
I'm quite behind on activeweb development, so would appreciate understanding the need for 1.8 at least.
Thanks!
If you really need Java7, there is an ActiveWeb backward-compatible release for Java 7: http://javalite.io/activeweb-release-notes-january-7-2017
The same is available for ActiveJDBC: http://javalite.io/activejdbc-release-notes-january-06-2017
However, with Java 7 was released 6 years ago, and Java 8 is about 3 years old now, I'd suggest to not look back. and just use Java 8.
Meh. It looks like java 1.8 is around the corner in standard edition.
Mentioned at bottom of:
https://cloudplatform.googleblog.com/2017/03/your-favorite-languages-now-on-Google-App-Engine.html
Related
Trying to test some code in Pharo 2.0 and it depends on BlockContext which was dropped, what can I do?
You can download Pharo 4 and run Magritte 3 and Seaside 3.1, as that are the stable versions. The major change in Magritte 3, introduced and explained early 2012, is the moving of the descriptions to the instance side, and renaming description to magritteDescription. You can find sample code of Seaside & Magritte in a QCMagritte image you can download from CI, in addition to the plain magritte builds
Otherwise, just check the pharo, seaside and pier mailing lists of 4 years ago and the monticello repositories to see what changed. There have been lots of little changes because of the improvements in Squeak and Pharo in the past 4 years.
If you need to use Magritte 2 to migrate legacy code you might want to take a look (with Pharo 5) at my experimental MonticelloProjects code on Smalltalkhub. That builds a data structure of all source code in the Monticello packages in a project repository, allowing you to more easily see what changed when.
I wanted to port a program from Squeak 4.4 to Squeak 4.5 but get the error message: OrderedCollection(Object)>>doesNotUnderstand:#flatCollect:.
flatCollect does not seem to be available anymore in Squeak 4.5. Does anybody know a good replacement for it?
You can simply replace all occurrences of flatCollect: with gather:.
It has basically the same functionality.
We know all that JGraph is a very powerful graphic library and now we are in version 6 (JGraphx).
Me I have an application (by the way I am newbye in JGraph) coded in JGraph 5 and I want to migrate it to Graphx.
Is there any tut to know what is the main differences between these two versions?
That migration, is it easy to do (in general)?
JGraph (the last version of which was version 5) and JGraphX (which was originally going to be called JGraph 6) are completely different code-bases. JGraphX was a complete rewrite from scratch, which is why we made the naming change to avoid the idea you could upgrade from 5 to 6.
So no, there is no migration route, you'd need to re-write your part of the application that interfaces with JGraph(X).
Does anybody know of a good approach for testing Java 6 code in Java 5? I just finished writing some programs for an internship application in Java 6, only to realize that they wanted me to submit code written in Java 5. I use eclipse, so I tried setting a duplicate project to run in a J2SE-1.5 environment and it worked. Was that a proper test, or was I mistaking something else for a Java 5? I also tried finding an online Java 5 compiler to test my code, but I couldn't find any websites with versions earlier than Java 6. I don't have a whole lot of experience with the more technical aspects of this sort of thing, so any simple approach would be immensely appreciated.
Yes, I think testing in a J2SE-1.5 environment should do it. Did you also change your compiler settings in the "Properties" window to 1.5? Please check that and try running your code. As far as I know I only do this to test between different versions of Java.
I have been asked to develop a new, small, custom-specific CRM (Customer Relationship Manager) that will be used mainly on Linux desktops (compatibility with Windows and Mac OS X would be appreciated but it is not required).
This seems to be a good opportunity to try the new Vala language and some of its libraries (most notably libgda and the rest of Gnome-DB) but, of course, I still have to deliver a working product to the customer in time so... I'm still scratching my head and wondering.
To develop this application I would need:
A "glue" language (Vala itself). This is OK.
A GUI Library (GKT+ 2.X or 3.X). This is OK.
A database abstraction layer (libgda). Here I have some doubt.
Maybe a MVC framework like Bakery (Bakery 2.6 seems to be working
with GTKmm 2.4 only. It does not work with the GObject-enabled GTKmm
3, as long as I can see.).
Maybe a ORM like Hiberlite (libgda supplies data-aware widgets
and other tools but it is not a full-blown ORM, as long as I know).
At the moment, I'm confident about the first two items, only. Even the real amount of Vala support for libgda is not very clear to me (The ValaDoc describes as supported the interface of a old version of LibGDA while the Gnome-DB website says that the new 4.2 and 5.X versions of the library are GObject- and Vala- enabled). Most likely, Bakery and Hiberlite would not be available any time soon for Vala.
The nearest alternative seems to be:
C++
GTKmm (2.X)
Maybe Bakery 2.6
libgda
Maybe Hiberlite
A more mature stack but... maybe so mature to be fated.
Hence: would you try Vala for a new database-centric project like this?
Or would you wait for a more mature and more rich Vala ecosystem?
Thanks
Vala just means native compilation without requiring a framework (and versions) to bother about. Connecting to database still looks premature and definitely undocumeted (that's how I came to this post). Besides, there is no IDE. Glade is not really and IDE, but an interface designer.
Try out Lazarus and you will be in for a surprise, how conveniently database front ends can be developed. Pretty mature, native compilation, ready to use third party components, database support right through the IDE, options of using Gtk or Qt.
And it gives native exe's on Windows, Linux and Mac. Nothing comes even remotely close if you are developing cross-platform database front ends. Development time would be a fraction and performance comparable to C, if not equal.