A simple cross-platform Google Drive client as a swing app? Time for a hackaton... :o)

[Fernando Cassia]

Given this
http://www.pcworld.com/businesscenter/article/254488/google_drive_for_linux_is_on_the_way.html

It would be a great PR boost for Java if someone quickly coded a Google Drive client for Linux, so that it becomes availabel BEFORE the official release :)

I imagine something using Java6+ APIs like docking to systray....

In fact, there's something done in Java to upload docs to google accounts...
http://code.google.com/p/google-docs-upload/

And here
http://sourceforge.net/projects/upthesync/

Something about mounting a filesystem from Java could probably be borrowed from here
http://mudslide.sourceforge.net/

or here
http://sourceforge.net/projects/gdatafs/
"Gdatafs is a FUSE implementation that mount your account at google's picassa web to your filesystem. The filesystem support ful read/write and delete of album and photos."

Please ... someone better than me at coding (or with more time)... let's show Gurgle where Java excels... network-centric applications.

It'd be great to show Google that a single Java app is better than several native apps, one for each OS they want to support.... also a good way to give Linux users a reason to install OpenJDK...

It'd be a punch in the face if the program also included some sort of statement about that with a single java client, there's no need to do separate versions for each OS like Google does... :)

Just my $0.02
FC
--
During times of Universal Deceit, telling the truth becomes a revolutionary act
- George Orwell

[Casper Bang]

It'd be a punch in the face if the program also included some sort of statement about that with a single java client, there's no need to do separate versions for each OS like Google does... :)

I think, if there really were advantages to doing it in Java, Google would've gone that route already. This smells of JNI and platform specific code paths, even more so than Picasa, Google Earth etc. I'm afraid the Duke is no longer capable of providing any interesting punches and I'd go as far as to claim, Google Drive would upset its average users if it required Java.

[phil swenson]

You know what would be a good PR boost for Java on the client? A java
UI that didn't feel sluggish. Been 15+ years and I'm still waiting
for a speedy Java UI.

> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.

[Takeshi Fukushima]

I guess we have some apps that are like that. Have you guys tried jprofiler? Its a niche app but its UI is very snappy, responsive and looks good too. Id also say that IntelliJ is like that (but i havent used too much of it)

--
http://mapsdev.blogspot.com/
Marcelo Takeshi Fukushima

[phil swenson]

java apps can feel snappy sometimes. but often the first time you hit
a menu item it takes forever to come up. Or if you leave an app
running, leave for another task and come bask - it takes quite a while
to become responsive again. also, garbage collection pauses are
annoying.

I use IntelliJ, Eclipse, Ruby Mine, AppCode, and DBVisualizer on OS X.
I think those are all the java UIs I use these days.

[Casper Bang]

On Monday, April 30, 2012 8:17:03 PM UTC+2, phil swenson wrote:

java apps can feel snappy sometimes.  but often the first time you hit
a menu item it takes forever to come up.  Or if you leave an app
running, leave for another task and come bask - it takes quite a while
to become responsive again.  also, garbage collection pauses are
annoying.

I don't think it's the GC, but Swing is just horribly over-engineered. The most successful Java desktop applications (if we can call these successful) are SWT based.

[Cédric Beust ♔]

Agreed. I think overall, it's easier to create a reasonably responsive SWT application while doing so in Swing requires a lot of time and expertise. There are very, very few companies that can pull this off besides JetBrains.

-- 

Cédric

[Ricky Clarkson]

Squirrel is pretty snappy and if you change the look and feel from the default, not too ugly. Ricoh's InfoPrint Manager has an ugly but quick Swing client. My last company has various ugly but quick Swing CCTV playback applications.

I wrote a network simulator that was less ugly, and snappy. I wrote a tiny app that verifies MD5 sums so that non-technical staff could run quality checks on files being loaded onto hardware just before shipping, and got asked whether it was really in Java as it was fast and tiny.

All that's not to say that the Swing-slow statements are unfounded.  It just takes some effort to make sure things are fast.  I remember loading a date picker at startup just because the classloading delay was visible if that was left to when the user wanted it.  Not a large delay, just visible.

Another part of the story is background tasks, which hopefully just improved in Java 7 with SecondaryLoop. I'm looking forward to trying that out.

[Cédric Beust ♔]

On Mon, Apr 30, 2012 at 1:57 PM, Ricky Clarkson <ricky.c...@gmail.com> wrote:

All that's not to say that the Swing-slow statements are unfounded.

All I said was that it takes a lot of expertise to write snappy Swing applications, and you are unwittingly proving my point by saying that you wrote several snappy Swing applications :-)

-- 

Cédric

[Kevin Wright]

My experience of Squirrel is a good 30 seconds of unresponsiveness when pasting 100 lines or so in the SQL edit window, and I'm not exactly on a slow machine either...

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Oscar Hsieh]

You guys should try DBVisualizer.  It is fast and good looking.

Sent from my iPad

[Ricky Clarkson]

For what it's worth I saw a delay and was on the verge of trying to debug it and then I upgraded and it disappeared.  There are still things it does in the foreground that it shouldn't though, such as when you do a text search for (part of) a table name.

[phil swenson]

I remember being very disappointed when I first looked at Java for
writing desktop UIs. It was a huge step backwards from all the
lessons learned from Delphi and VB in the 90s. No properties, no
events, layout hell, overly complicated APIs.

It's like the engineers at Sun didn't even look at what others had done.

It's 2012 and it's still much faster and easier to write a client in
Delphi circa 1997 than Java Swing.
I can't comment on JavaFX of course, never looked at it.

[Simon Ochsenreither]

I can't comment on JavaFX of course, never looked at it.

I'd say don't get too excited.

It should have been "Swing — the good parts", but it ended up more like "JavaFX — Swing business as usual.".

It is certainly miles away from competing offerings (not that those don't have their own issues).

[Casper Bang]

On Tuesday, May 1, 2012 6:46:05 PM UTC+2, phil swenson wrote:

I remember being very disappointed when I first looked at Java for
writing desktop UIs.  It was a huge step backwards from all the
lessons learned from Delphi and VB in the 90s.  No properties, no
events,  layout hell, overly complicated APIs.

And yet, the hardcore Java developer will defend it vigorously.

It's like the engineers at Sun didn't even look at what others had done.

Sun spearheaded the NIH virus.

 

It's 2012 and it's still much faster and easier to write a client in
Delphi circa 1997 than Java Swing. 

I can't comment on JavaFX of course, never looked at it.

They've got one idea right; declarative expression tree modelling (top-down rather than bottom-up). However, I believe it's limited to the UI and that quicky made JavaFX utterly useless and a waste of time for me. Fantom and Ceylon are examples of the same line of though, taken a bit further into general purpose. It seems pretty obvious to me that we are going to need strong hierarchical modelling constructs, most everything we do revolve around trees.

[Fabrizio Giudici]

On Tue, 01 May 2012 19:25:36 +0200, Simon Ochsenreither
<simon.och...@googlemail.com> wrote:

>
>>
>> I can't comment on JavaFX of course, never looked at it.
>>

It seems we're discussing on different things (as usual :-) I think
Cédric's point is the more accurate, that is Swing can be fast but it
needs a sound expertise. I don't think the GC is a problem if not in some
corner cases. I don't see the point about missing properties and such
compared to Delphi, which has to do with the code look and not the speed
(BTW, the statement is more toward Java than Swing, and yes we can have
properties without writing plumbing code with an annotation processor).

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Fabrizio Giudici]

On Tue, 01 May 2012 19:41:57 +0200, Casper Bang <caspe...@gmail.com>
wrote:

> On Tuesday, May 1, 2012 6:46:05 PM UTC+2, phil swenson wrote:
>>
>> I remember being very disappointed when I first looked at Java for
>> writing desktop UIs. It was a huge step backwards from all the
>> lessons learned from Delphi and VB in the 90s. No properties, no
>> events, layout hell, overly complicated APIs.
>>
>
> And yet, the hardcore Java developer will defend it vigorously.

This is not true as most Java developers know that Swing is pretty old.
BTW, getting back to the original Phil's statement, apart from the fact
that you can have properties in the language with an annotation processor,
I'd like to know what does he mean with "no events". One of the problems
of Swing is perhaps that there are too many (kinds of) events.

[Casper Bang]

This is not true as most Java developers know that Swing is pretty old.  
BTW, getting back to the original Phil's statement, apart from the fact  
that you can have properties in the language with an annotation processor,  
I'd like to know what does he mean with "no events". One of the problems  
of Swing is perhaps that there are too many (kinds of) events.

Que Joe! Joe? Ah right... 

This has been discussed before. An event in Java, is interface bound and can be done in so many ways. There are the legacy java.util.Observable, the legacy java.awt.AWTEvent stuff, but most just roll their own callbacks modeled around the singlecast or multicast observer pattern. Then there are all the various data-binding attempts, where JSR-295 comes to mind which I believe you forked as well.

However, it really does not have to be so complicated. First of all, events elsewhere are build into the languages, enabling wiring up code (and tools) to take advantage of this knowledge. They also typically facilitate decoupling observer and observee, so that it becomes a matter of compatible signatures rather than shared types, similar to the advantage lambda's offers over anonymous inner classes.

I don't want an annotation processor; I want the generic abstractions I use everyday to be baked into the language as first class constructs. Any handyman will claim that having good tools is half the job. The language is a programmers primary tool, so this should apply to software construction as well as house construction.

[Fabrizio Giudici]

On Wed, 02 May 2012 11:30:04 +0200, Casper Bang <caspe...@gmail.com>
wrote:

> I don't want an annotation processor; I want the generic abstractions I
> use
> everyday to be baked into the language as first class constructs. Any

I think it's difficult nowadays to have wide consensus on this. An
annotation is a first-class construct and it's Java's way to be enhanced.
In Scala events are pretty elegant when I look at Akka, but as I
understand they are not baked into the language; they are implemented on
the top of DSL-like flexibility that Scala offers (including operator
overloading). To me it's precisely what Java does, even though it's a
rougher (?) approach of course.

To me in the end the important part is that syntax is clear, semantics are
precise and I don't have to do something strange to have it working.
Putting a jar in the classpath it's not strange.

Note that I'm not arguing *against* having baked in support for events in
a language. I'm so event oriented that I'd appreciate it. But as I've said
in the past, I'm not keen to see many new constructs in Java and I prefer
to see it extended in other ways. But this has nothing to do with Swing -
we're back discussing on languages. I think Scala can use Swing and have
pretty nice events that "look" baked in the language (while, of course,
Scala can't do anything with obsolete Swing APIs).

[Ricky Clarkson]

Regarding Java lacking events, look at C#'s event keyword.  Java provides the same, just not with pleasant syntax.  I think that's what the poster meant.

Annotation processors - too much like magic.  Scala's DSLs are written in the language and don't require anything other than a library.  You don't have to worry about two DSLs conflicting with each other (ignoring implicit conflicts for a moment) and they don't make classloading or compilation any more difficult.  I'm not just promoting Scala here, Java could really use what JavaFX has been failing to deliver all these years, a decent DSL for graphical applications.

Personally I'd rather see more effort put into making Swing behave as native (e.g., the same menus when you right-click in a JTextField as in any other application), and begin to throw exceptions on badly threaded Swing code - with an option to just run it anyway of course.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

[Fabrizio Giudici]

On Wed, 02 May 2012 13:27:57 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> Annotation processors - too much like magic. Scala's DSLs are written in
> the language and don't require anything other than a library. You don't

I've said that Java is clearly rougher in this than e.g. Scala, but it
does work, and doesn't require more than a library (e.g. lombok.jar).
Scala has been designed from the ground up to support inner DSL and we
can't really ask Java for doing the same job.

> have to worry about two DSLs conflicting with each other (ignoring
> implicit
> conflicts for a moment) and they don't make classloading or compilation
> any
> more difficult.

I'm not aware that Lombok, e.g., creates problem with classloading. I'm
using it everywhere, including the NetBeans Platform (which does heavy use
of classloaders) and Android and it just works. I've only had a problem
when using it together AspectJ static weaving, but it was more a problem
with the AspectJ Maven plugin that missed an option that makes the two
technologies live happily together.

[Casper Bang]

I think it's difficult nowadays to have wide consensus on this. An  
annotation is a first-class construct and it's Java's way to be enhanced.  
In Scala events are pretty elegant when I look at Akka, but as I  
understand they are not baked into the language; they are implemented on  
the top of DSL-like flexibility that Scala offers (including operator  
overloading). To me it's precisely what Java does, even though it's a  
rougher (?) approach of course.

Indeed, we've seen annotations as a facilitator for many things by now, many of which are characterized by the JLS and luminaries as being misuses. Don't get me wrong, I absolutely love runtime pluggability (Java's SPI is particular elegant and one of the few examples where it shines over C#), but annotations are used for far too much now. I still get shivers when I think about certain large complex applications which has IoC and AOP annotations sprinkles all over... horrible.

 

To me in the end the important part is that syntax is clear, semantics are  
precise and I don't have to do something strange to have it working.  
Putting a jar in the classpath it's not strange.

Yeah but what happens when my module X has to be integrated with your module Y, through module Z? A lack of standards is far worse than an lackluster standard in the long run. Software is build for the long run.

Anyway, we're digressing. I honestly have very little hope for Java to continue staying relevant given its history over the last decade and if I don't expect it, at least I won't get disappointed. :)

[Ricky Clarkson]

Lombok might just need to be on the classpath when you compile, but it changes your source during compilation.  Would two things like Lombok work together in the same source file without problems?  If it was just a library it wouldn't need IDE plugins.

[Kevin Wright]

Lack of IntelliJ support is also a very large thorn in Lombok's side and a deal-breaker for many.

If Java (the lang) was prescribed then I think I'd want to prevaricate until lambdas arrive, possibly by playing Duke Nukem Forever in the meantime...

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Fabrizio Giudici]

On Wed, 02 May 2012 13:45:32 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> Lombok might just need to be on the classpath when you compile, but it
> changes your source during compilation. Would two things like Lombok
> work
> together in the same source file without problems? If it was just a
> library it wouldn't need IDE plugins.
>

IDE plugins are needed because of autocompletion. IDEs need to know that
there are extra fields / methods available in addition to the ones that
have been coded directly in order to provide hints. In other words, IDE
plugins for Lombok are there to solve a problem of the IDE. Actually you
can use Lombok with Ant or Maven by just having a library in the
classapath, thus nothing different than usual business.

[Ricky Clarkson]

Libraries don't cause problems for autocompletion.

[Fabrizio Giudici]

On Wed, 02 May 2012 13:45:32 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> Would two things like Lombok work
> together in the same source file without problems?

Forgot to answer this. Probably not, but it's just a matter of standarts
(de facto). I mean, Lombok exists as a base project, while many people
have created their own annotation processors based on Lombok (e.g.
Lomprop, etc...). They share some basic Lombok function in order to work.
Of course, people not using Lombok but their own stuff could experience
problem. It can be solved with the community adopting Lombok as a de-facto
standard for plugging in their stuff. I'd have loved to see Sun/Oracle to
work on a better standardisation for annotation processors.

[Fabrizio Giudici]

On Wed, 02 May 2012 15:20:35 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> Libraries don't cause problems for autocompletion.

If the problem is autocompletion, does autocompletion work for *every*
feature of Scala? Today?

[Kevin Wright]

Racking my brains here, but I can't think of any where it doesn't.

There's the occasional issue where it will falsely report a syntax error in perfectly valid code.  But this is increasingly rare and only really happens for especially tricky constructs, certainly not for the sort of bread-and-butter work that I'd use Lombok for.

I can also just hit the "play" button on some test and the IDE will happily run it in a pretty GUI, I'm not forced to drop down to a command-line build tool.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Ricky Clarkson]

I don't know, I haven't tried for a couple of years.

If/when autocomplete works for all Scala features it'll work for all libraries.  The same is not true for magic like Lombok.

[Kevin Wright]

What is an event if not just a simple function?  The kind of thing that we have to clumsily emulate with SAM types in Java...

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Fabrizio Giudici]

On Wed, 02 May 2012 15:36:06 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> I don't know, I haven't tried for a couple of years.
>
> If/when autocomplete works for all Scala features it'll work for all
> libraries. The same is not true for magic like Lombok.

I think I've read something recent about "fixing" Scala autocompletion,
but my knowledge is scarce, so I trust Kevin's word that *today*
everything work. But I suppose this didn't work magically, but somebody
wrote the proper plugin / configuration for the IDE. New language, new IDE
plugin. Same for annotation processors. New feature, new IDE plugin.

[Simon Ochsenreither]

Hi Kevin,

thinking about it for a few moments ...

Isn't that a key benefit of Scala's macros over Java's annotation processing?

Annotation processing requires both a compiler plugin and an IDE plugin, whereas no special IDE specific support for macros might be needed. Additionally, people can read and understand what the macro does quite easily by jumping to the macro definition, whereas in Java people have to dig into the sources of the plugin themselves, because there is no link between the annotation declaration and the implementation of the transformations applied.

[phil swenson]

>> I'd like to know what does he mean with "no events".

in Delphi you could do stuff like:

sendButton.onClick = ClickHandlerMethod



I don't even want to think about what the equivalent is in Java.

Basically, you need function pointers.

[Joseph Ottinger]

ricky: the java version is way worse, because it doesn't use =.

On Wed, May 2, 2012 at 10:53 AM, Ricky Clarkson <ricky.c...@gmail.com> wrote:

sendButton.addMouseListener(clickListener);

--
Joseph B. Ottinger
http://enigmastation.com

Ça en vaut la peine.

[Fabrizio Giudici]

On Wed, 02 May 2012 16:51:02 +0200, phil swenson <phil.s...@gmail.com>
wrote:

>>> I'd like to know what does he mean with "no events".
>
> in Delphi you could do stuff like:
>
> sendButton.onClick = ClickHandlerMethod
>
>
>
> I don't even want to think about what the equivalent is in Java.
>
> Basically, you need function pointers.

So, it's not events but first class functions and it's not a Swing
problem, but a Java problem. In Groovy or Scala with Swing you can do that.

[Kevin Wright]

sendButton.onClick += clickHandlerFn

Because:

1. It's really rather nice to have first-class functions and lambdas/closures available, not just methods tethered to a particular class
2. There could be multiple handlers for the onClick event, '=' implies there's only ever one, '+=' doesn't

For what it's worth, ScalaFx property binding (closely related to events) uses a different notation:

scrollBar.value ==> progressBar.value

[Kevin Wright]

Yup:

http://www.slideshare.net/perneto/scalaswing

http://www.cs.helsinki.fi/u/wikla/OTS/Sisalto/examples/html/ch32.html

Or better still, there's another exciting new paradigm on the horizon:

http://lampwww.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Ricky Clarkson]

sendButton.addMouseListener(clickListener);

On May 2, 2012 11:51 AM, "phil swenson" <phil.s...@gmail.com> wrote:

[Casper Bang]

Or better still, there's another exciting new paradigm on the horizon:

http://lampwww.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf

Already being used on .NET, with the Reactive Extensions framework (Rx) which allows such goodness as LINQ over events.

http://rxwiki.wikidot.com/101samples 

Also, I believe the Fantom brothers are contemplating going this route.

[phil swenson]

> So, it's not events but first class functions and it's not a Swing problem,
> but a Java problem. In Groovy or Scala with Swing you can do that.

This is correct. But when these guys were writing the Swing APIs, it
seems to me the Swing guys should have gone to the Language Guys and
said "WTF. We need properties and events or this is going to suck!"

[phil swenson]

click listener isn't a method

[Fabrizio Giudici]

On Wed, 02 May 2012 17:48:36 +0200, Casper Bang <caspe...@gmail.com>
wrote:

>
>>

I skimmed the paper and I think I'm seeing familiar stuff. Nice to have a
reference on what others are doing, though. Is there some similar stuff
done in Java?

[Ricky Clarkson]

Right, it's an object. Java doesn't have methods as first class values.  You'll find my name on the First Class Methods proposal from 2008 or so.  I agree but don't think adding a new kind of type and syntax just for events is flexible enough.

[phil swenson]

closures may lead to some sort of event construct, I'm not sure.

Closures are at least 10 years late to the party.

On Wed, May 2, 2012 at 10:40 AM, Ricky Clarkson

[Kevin Wright]

Closures were partying until 4am whilst objects were still a mere glint in their father's eye.  Who are you calling "late"?

[Casper Bang]

To those of us who live in the real world working within Tiobe's top 10, and specifically in a Java context, closures are definitely late to the party. In fact, within top 5, only C# offer closures as first-class functions.

[Ricky Clarkson]

I'm not sure how we got from method pointers to closures, but of the top 5 C, C++, Objective-C and C# all have some form of method/function pointer, leaving Java as the odd one out.

If you go for closures, C has them with compiler extensions, the latest version of the C++ has them, Objective-C now has blocks and C# has lambdas.  Of the top 5, Java's equivalent, anonymous classes, is the most verbose and distracting.

That said, when I use C# I do actually miss anonymous classes, just not for those that contain a single-method.

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/uve_FAZ3ccMJ.

[Simon Ochsenreither]

You make it sound as if it was the fault of Closures.

BTW: Tiobe ... seriously?

[phil swenson]

"I'm not sure how we got from method pointers to closures"

well in a langage w/o pointers - seems like closures fit the bill, no?

> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.

> To view this discussion on the web visit

> https://groups.google.com/d/msg/javaposse/-/bdUc7Yye4_UJ.

[Cédric Beust ♔]

On Wed, May 2, 2012 at 11:14 AM, Simon Ochsenreither <simon.och...@googlemail.com> wrote:

BTW: Tiobe ... seriously?

By definition, most of us are working with the top languages of TIOBE.

No need to get emotional, nobody was saying bad things about Scala.

-- 

Cédric

[fcassia]

On Apr 30, 2:49 pm, phil swenson <phil.swen...@gmail.com> wrote:
> You know what would be a good PR boost for Java on the client?  A java
> UI that didn't feel sluggish.  Been 15+ years and I'm still waiting
> for a speedy Java UI.

Strange. I use muCommander daily. http://ho.io/mu-commander
And Vuze.

Don't notice any sluggishness.

FC

[fcassia]

On May 1, 1:46 pm, phil swenson <phil.swen...@gmail.com> wrote:

> I can't comment on JavaFX of course, never looked at it.

This looks interesting... calling JavaFX APIs from Pure Java apps.

http://marxsoftware.blogspot.com.ar/2011/12/pure-java-javafx-20-menus.html

FC

[fcassia]

On Apr 30, 2:02 am, Casper Bang <casper.b...@gmail.com> wrote:
> > It'd be a punch in the face if the program also included some sort of
> > statement about that with a single java client, there's no need to do
> > separate versions for each OS like Google does... :)
>
> I think, if there really were advantages to doing it in Java, Google
> would've gone that route already.

No, because Google is on a crusade against Java. In fact, they removed
their perfectly functional and useful J2ME GMail application from
their servers. They could have just placed a notice saying "this won't
be updated anymore, use it as-is" but no, they had to erase the
binaries from their servers.

Think of Microsoft making sure its apps don't run under WINE.

Fortunately users re-uploaded the app to third party servers without
Gurgle's permission... and it continues working just fine (someone
from sweden even hacked it to support multiple accounts, I think).

> This smells of JNI and platform specific
> code paths, even more so than Picasa, Google Earth etc.

There is no graphics in a network centric tool, so the comparison is
really not appropiate.

Yes, some JNI could perhaps be needed.

FC

[Cédric Beust ♔]

On Tue, May 15, 2012 at 2:53 PM, fcassia <fca...@gmail.com> wrote:

No, because Google is on a crusade against Java.

That's nonsense. What could possibly have led you to make such an absurd claim?

In fact, they removed
their perfectly functional and useful J2ME GMail application from
their servers.

I don't know how accurate that is, but it certainly says nothing about whether Google is on a crusade against Java.

By the way, I created the Java Gmail project so I know a thing or two about it, and while I have some emotional attachment to it, I certainly can't blame a company for moving away from Java ME. The faster we leave this monstrosity behind, the better.

-- 

Cédric

[Ricky Clarkson]

Even BlackBerry (well, RIM) are going to leave Java behind, though I have to say what Google did is awful for people stuck on a J2ME device for the forseeable future.

At least gmail does IMAP so there'll always be an alternative.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

[Russel Winder]

On Tue, 2012-05-15 at 15:01 -0700, Cédric Beust ♔ wrote:
[...]

> blame a company for moving away from Java ME. The faster we leave this
> monstrosity behind, the better.

If Java ME was/is a monstrosity what does that make JavaCard?

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[Russel Winder]

On Tue, 2012-05-15 at 19:19 -0300, Ricky Clarkson wrote:
> Even BlackBerry (well, RIM) are going to leave Java behind, though I have
> to say what Google did is awful for people stuck on a J2ME device for the
> forseeable future.

It will be interesting to see what all the companies I did Java ME
training for last year and previously so they could build corporate
Blackberry apps are going to do now that both Java ME and Blackberry are
going down the pan.

[Steven Siebert]

This months Java Magazine has a relevant article on JavaME ( http://www.oraclejavamagazine-digital.com/javamagazine/20120506?sub_id=EoA81h7GiCiZ#pg17 ). This article at least provides anecdotal evidence that Oracle or the global telecom industry is seeing the near demise of JavaME.  Perhaps in our countries, where we spend big $$ on "smart" phones this may be so...but we aren't the majority of phone users globally.

[Ricky Clarkson]

> Perhaps in our countries, where we spend big $$ on "smart" phones this may be so...but we aren't the majority of phone users globally.

I know that here in Argentina a lot of people prefer Blackberrys to at
least medium-line Android phones, but more out of habit than anything,
and the collective noun for smartphones seems to be 'Blackberrys', no
matter the manufacturer or OS. Which throws me every time.

In fact when I got my Samsung device it was 2/3 the price of the
cheapest Android, bought on a contract, despite to my eyes at least,
being 100 times better, so I guess either they can't sell Android
devices and push the price down to get rid, or they push the
BlackBerry prices up according to demand, or a combination of both.

Whole groups of friends organise events using BlackBerry Messenger,
and people relying on the cross-manufacturer equivalent, WhatsApp,
often find themselves missing some information.

I'm not sure RIM should even try to compete with Apple and Android
like-for-like. Something new is needed, such as those magical
unfolding screens that always seem to be in the late prototype phases,
decent quality speakers on which bass can actually be heard, tactile
feedback from the screen so you can feel the edge of a button, more
accurate touch (fingernail?) so that UIs don't have to have comically
large buttons to be reliable, etc.

[Fabrizio Giudici]

On Wed, 16 May 2012 07:26:48 +0200, Russel Winder <rus...@winder.org.uk>
wrote:

> On Tue, 2012-05-15 at 15:01 -0700, Cédric Beust ♔ wrote:
> [...]
>> blame a company for moving away from Java ME. The faster we leave this
>> monstrosity behind, the better.
>
> If Java ME was/is a monstrosity what does that make JavaCard?

Monstrosity is not a correct word, while I do understand that Java ME is
no more a strategic asset. I'd understand whether Google stopped any
development on a JME application, but I can't understand why it has to be
completely removed, as the previous poster said that in some way others
are being able to manage it. Especially in this crisis scenario, you can't
force *all* the people to buy a new phone because they can't read the mail
any longer.

In any case, I find excessive to say that Google is fighting a crusade
against Java.

[Kevin Wright]

On 16 May 2012 07:48, Ricky Clarkson <ricky.c...@gmail.com> wrote:

> Perhaps in our countries, where we spend big $$ on "smart" phones this may be so...but we aren't the majority of phone users globally.

I know that here in Argentina a lot of people prefer Blackberrys to at
least medium-line Android phones, but more out of habit than anything,
and the collective noun for smartphones seems to be 'Blackberrys', no
matter the manufacturer or OS.  Which throws me every time.

In fact when I got my Samsung device it was 2/3 the price of the
cheapest Android, bought on a contract, despite to my eyes at least,
being 100 times better, so I guess either they can't sell Android
devices and push the price down to get rid, or they push the
BlackBerry prices up according to demand, or a combination of both.

Whole groups of friends organise events using BlackBerry Messenger,
and people relying on the cross-manufacturer equivalent, WhatsApp,
often find themselves missing some information.

I'm not sure RIM should even try to compete with Apple and Android
like-for-like.  Something new is needed, such as those magical
unfolding screens that always seem to be in the late prototype phases,
decent quality speakers on which bass can actually be heard, tactile
feedback from the screen so you can feel the edge of a button, more
accurate touch (fingernail?) so that UIs don't have to have comically
large buttons to be reliable, etc.

If by "better quality" you mean "highly directional", then I'm all for it.  Anything that means I don't have to endure whatever 5 minute wonder the schoolkids are playing for each other on the bus this week.

Better still, why not just remove the speaker entirely and give the thing 5 headphone sockets?  And 5 pairs of half decent headphones that don't blast so much of the "music" outwards that I can use shazam to identify what my fellow travellers are listening to? (I'm looking at *you* Apple...)

I'd also pay good money for a handset with some sort of EMP capability built in, able to knock out the noisiest devices of everyone else within a 5 metre radius :)

[Ricky Clarkson]

Hah, people playing music on the bus isn't so much of a problem here as a) it doesn't happen so much b) the music they play is better. :)

[phil swenson]

>>what Google did is awful for people stuck on a J2ME device for the

To anyone "stuck" on J2ME…. I say upgrade :)

[Mark Derricutt]

I could see one reason to remove the JME application - if GMail's APIs
have actually changed and the app no longer works - if they're not going
to update the app, better to remove it than have something broken out there.

[Cédric Beust ♔]

Another reason is not having to support it any more and allocate the engineers to projects that are going to seve a larger number of users.

-- 

Cédric

--

You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

[Fabrizio Giudici]

On Thu, 17 May 2012 00:19:56 +0200, Cédric Beust ♔ <ced...@beust.com>
wrote:

> Another reason is not having to support it any more and allocate the
> engineers to projects that are going to seve a larger number of users.
>

Correct. But is the app open source? If not, why not release it to open
source?

[Cédric Beust ♔]

It's not open source.

-- 

Cédric

[Fabrizio Giudici]

On Thu, 17 May 2012 09:18:53 +0200, Cédric Beust ♔ <ced...@beust.com>
wrote:

> It's not open source.
>

So, why not releasing it to the open source? When Adobe decided that e.g.
Flash was no more a source of profit, but a source of expenses, they
donated it to Apache. At least this makes it possible for the community of
users to have a smooth transition, or to find their own way. As I said, I
wouldn't call this an attack to Java, but a scarce consideration of users.

[Cédric Beust ♔]

On Thu, May 17, 2012 at 12:26 AM, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:

It's not open source.

So, why not releasing it to the open source?

I can only speculate, but I can think of plenty of reasons, starting with 1) turning a closed source project into open source requires a lot (a lot!) more efforts than people think, 2) it would also mean exposing the API that the application uses, which means more support and 3) what does Google have to gain from such a move? (nothing)

Contrary to what a lot of people think, open sourcing proprietary projects is not just difficult, it's expensive and creates a significant drag on the organization in charge of the effort (at least) and most likely, the entire company.

More often than not, open sourcing is the *wrong* thing to do for a corporation.

-- 

Cédric

[Fabrizio Giudici]

On Thu, 17 May 2012 09:48:52 +0200, Cédric Beust ♔ <ced...@beust.com>
wrote:

> I can only speculate, but I can think of plenty of reasons, starting with
> 1) turning a closed source project into open source requires a lot (a
> lot!)
> more efforts than people think,

This is true when the company still maintains the project. I don't see it
happening when you donate it and clearly state that you're no more
spending effort on it. I repeat: Adobe did it for Flash, they aren't
investing any longer into the product, still decided to donate it.

> 2) it would also mean exposing the API that
> the application uses, which means more support and

Not true. Google can say: the app is using a deprecated API and we won't
be supporting it any longer; community, be advised that if you want to
keep the client alive it's up to you to patch it to use the newest API.

< 3) what does Google
> have
> to gain from such a move? (nothing)

I perfectly agree. This is the true reason. It's legitimate. What makes me
angry is when I hear Google proclaiming their support for the community,
sake of the world's progress and the other bullshit. Not counting the
"Make no evil" stuff which is the mother of all insults to people's
intelligence.

[Joe Attardi]

In my experience, most sluggish Swing UIs are sluggish because the developer didn't properly understand Swing threading.

Stop blocking the EDT!!!

On Monday, April 30, 2012 1:49:11 PM UTC-4, phil swenson wrote:

You know what would be a good PR boost for Java on the client?  A java
UI that didn't feel sluggish.  Been 15+ years and I'm still waiting
for a speedy Java UI.

On Sun, Apr 29, 2012 at 7:51 PM, Fernando Cassia <fca...@gmail.com> wrote:
> Given this
> http://www.pcworld.com/businesscenter/article/254488/google_drive_for_linux_is_on_the_way.html
>
> It would be a great PR boost for Java if someone quickly coded a Google
> Drive client for Linux, so that it becomes availabel BEFORE the official
> release :)
>
> I imagine something using Java6+ APIs like docking to systray....
>
> In fact, there's something done in Java to upload docs to google accounts...
> http://code.google.com/p/google-docs-upload/
>
> And here
> http://sourceforge.net/projects/upthesync/
>
> Something about mounting a filesystem from Java could probably be borrowed
> from here
> http://mudslide.sourceforge.net/
>
> or here
> http://sourceforge.net/projects/gdatafs/
> "Gdatafs is a FUSE implementation that mount your account at google's
> picassa web to your filesystem. The filesystem support ful read/write and
> delete of album and photos."
>
> Please ... someone better than me at coding (or with more time)... let's
> show Gurgle where Java excels... network-centric applications.
>
> It'd be great to show Google that a single Java app is better than several
> native apps, one for each OS they want to support.... also a good way to
> give Linux users a reason to install OpenJDK...

>
> It'd be a punch in the face if the program also included some sort of
> statement about that with a single java client, there's no need to do
> separate versions for each OS like Google does... :)
>

> Just my $0.02
> FC
> --
> During times of Universal Deceit, telling the truth becomes a revolutionary
> act
> - George Orwell

>
> --
> You received this message because you are subscribed to the Google Groups

> "The Java Posse" group.