. The jury won't weigh in on this for a
while yet -- it still hasn't for Android after all.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email
better, more
flexible tools exist.
--
Jess Holle
[EMAIL PROTECTED] wrote:
Of course, if I'm getting to use Groovy/Ruby for writing tests,
metaprogramming features do allow me to mock static methods.
Interesting... do you have a code snippet that demonstrates
inferring when the right
hand side is a literal or a constructor, e.g:
final foo = x;
final bar = new Whatever();
On Oct 10, 9:17 pm, Jess Holle [EMAIL PROTECTED] wrote:
Allowing
final foo = someMethodCall();
encourages these downsides to be propagated throughout dozens and dozens
.
There are restrictions on when, but changing those vs. working with them
is a JVM spec change, not a source rewrite or even JVM implementation issue.
--
Jess Holle
1) Remove checked exceptions
Why: Loiters the code without actually adding anything
2) Add type aliases
Why: To avoid
, Jython, Fortress, etc, all avoid this
dimension of change -- they suggest changes they'd like but work around
the lack thereof for now so as to be more accepted tools for now.
--
Jess Holle
Viktor Klang wrote:
Reinier,
my point (although somewhat between the lines) was that doing things
possibly give
developers any clue as to what to expect from them -- such consideration
is not part of Apple's style.
--
Jess Holle
Neil Bartlett wrote:
Bear in mind that relying on new features in the latest Java release
(such as draggable applets) will mean Mac OS users won't be able to
use your
the compiler help me get it right (for all
compilers) the first time -- and can wait for the spec to be improved.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group
figure out how to put them all together).
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group
So I guess that should mean a compile all possible classes compiler
more than a lenient compiler.
In a CI environment you might have 100's of modified sources. If some
fail to compile, you'd like to ensure that (1) all other possible
sources are compiled [javac will simply stop trying at some
Hmmm
I guess I see no need to go down that path.
Jim Blackler wrote:
Well it may be possible to compile most of a class, for instance if I
introduce a field with an invalid type. Only at the moment that
something tried to use that type would an exception be thrown.
2008/10/24 Jess Holle
, Nov 5, 2008 at 4:44 AM, Jess Holle [EMAIL PROTECTED] wrote:
Brett Ryan wrote:
@Weiqi
Do you like using Introspector? ;) Okay it might be a tongue in cheek
question, but I'd still much prefer being able to do
foo.getDeclaredProperties() and have a PropertyDescriptor array
returned without
the means of attaining them are not the
same syntactic sugar you see in another language does not mean that (a)
they're not there and (b) that they're not usable.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
() utility so that one could do things like new T[]
in sort -- throwing a runtime exception if the typing info is not
present. This would be undoing erasure without blowing new/old code
interoperability except where actually necessary.
--
Jess Holle
Christian Catchpole wrote:
Here is my
then be mapped as appropriate
as part of implementing the trait interface.
--
Jess Holle
Mark Derricutt wrote:
Please please please bring on traits! I'm somewhat on the fence of
rather seeing traits than closures in java sooner than the other.
I'm finding LOTS of places in my code where traits
Jess Holle wrote:
One could call such interfaces traits instead with a new keyword
or such.
I don't really see /any/ benefit from this, though.
I'd have full blown no-holds-barred multiple inheritence, but it's too
late for that for Java. I have /no/ fear or loathing of diamond
) breaking of existing Class contracts,
explicit or implicit, (2) resulting in duplication of Class objects or
other bloat, or (3) breaking interoperability between new and old code.
--
Jess Holle
On Thu, Nov 6, 2008 at 7:47 AM, Jess Holle [EMAIL PROTECTED] wrote:
getTypeParameters() will tell
doesn't like it you can still offer them ways to avoid
it (PMD if must, compiler-option if wanted). I don't see how adding
multiple inheritance would be worse than adding implementations to
interfaces.
Peter
On Thu, Nov 6, 2008 at 7:52 AM, Jess Holle [EMAIL PROTECTED] wrote:
One could
-- and
anything below that in the hierarchy inherits these ambiguity
resolutions. [At least in any reasonable proposal I've seen.] In that
sense things are not flat.
--
Jess Holle
Therefore with Traits the rule is, if ambiguous it is an error that
must be resolved explicitly by the programmer
to store the type parameters on each object, which
is probably much more expensive in total. The former approach seems to
also match the type model better.
Yes, I was thinking something along the lines of the former.
On Thu, Nov 6, 2008 at 8:22 AM, Jess Holle [EMAIL PROTECTED] wrote:
Peter
Terracotta does not cover all platforms :-(
Viktor Klang wrote:
It's rather easy to run Terracotta Session replication and have this
feature for free.
On Thu, Nov 6, 2008 at 10:53 AM, Alexis Moussine-Pouchkine alexis.mp
http://alexis.mp@gmail.com http://gmail.com wrote:
Active
Viktor Klang wrote:
On Thu, Nov 6, 2008 at 1:49 PM, Jess Holle [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Viktor Klang wrote:
Actually guys, referential equality is kind of retarded, so the
MapString,Integer.class == MapFoo,Bar.class
example is bad.
However
== and .equals MUST give the same results for Class objects --
else loads of things break.
The ConcreteClass noted below would not be a Class -- it would be a
new API.
--
Jess Holle
On Thu, Nov 6, 2008 at 12:38 AM, Jess Holle [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Peter Becker wrote
There are big limitations imposed by dynamic proxies here as I see it.
Dynamic proxies are beautiful interceptors for one or more interfaces,
but they themselves are of a synthetic class.
If you have a class A and you want to mix-in/apply an interface to it,
dynamic proxies could help wire a
this irrelevant, subjective cruft.
--
Jess Holle
P.S. I did loads of development on green or orange screened dumb
terminals in college. By comparison to this modern IDEs and modern
screen sizes are a miraculous improvement and thus I generally can't
complain about them on the basis of look
I know another NetBeans user who wants off-white / light grey rather
than white backgrounds.
He uses the jvi plug-in and uses a light grey background for it, but the
rest of the panels are not so easily changed, which is a source of
annoyance for him.
--
Jess Holle
??(milan) wrote:
yes you
around
by other JVM vendors.
* While I understand Sun's stance here, the 32 vs. 64-bit
tradeoffs are most severe for the Sun JVMs right now to the
best of my knowledge.
--
Jess Holle
Joshua Marinacci wrote:
Absolutely. And for many programs this is awesome
Yes, clearly the new plug-in technology helps clear the way.
The small in-process bridge still needs to be delivered in 32 and 64-bit
forms, though, which I assume is what's causing this feature to be
delayed until Update 12 rather than just being part of Update 10.
--
Jess Holle
Joshua
whether it is GPL'ed. I don't care too much about
particulars beyond this -- BSD, Apache License 2.0, etc, even LGPL, are
all free, unrestricted for commercial use licenses. Stating the
actual license used is probably faster than any other way of spelling
this out, though.
--
Jess Holle
If the Posse can spend the time gathering the this one word or TLA
(three-letter-acronym), then this little bit of alphabet soup can help
some of us a lot.
Peter Becker wrote:
On Thu, Nov 20, 2008 at 10:03 PM, Vince O'Sullivan
[EMAIL PROTECTED] wrote:
On Nov 19, 7:14 am, Reinier
I believe that in context of the discussion Dick really meant to say
commutative, not associative, transitive, reflexive, or any other such term.
--
Jess Holle
Peter Becker wrote:
Hi Dick,
the math guy in me just has to comment on your comments on
transitivity/reflexivity in #218 ;-)
You
://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578753,
4330950
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4330950,
etc. There are plenty of nasty desktop Java bugs (and
HTTP(S) client issues) outside the top 25 as well.
That's it for now.
--
Jess Holle
of JavaFX per se -- there's a time and
a place for everything, but conversely there's a time and a place for
plain 'ole Java and it wouldn't seem right to be forced into JavaFX for
many of these things. You'd expect to be able to just call some
well-documented Java APIs.]
--
Jess Holle
Oh... I almost forgot.
What's the estimated time of release of the integrated 2/3D scene graph
for JavaFX?
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post
a huge number of existing Java users
mad and have trouble getting such contentious language features through
a design-by-committee JSR process.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java
Jess Holle wrote:
Casper Bang wrote:
Sorry guys, but I just don't buy that JavaFX had no negative effect on
JSR's and JSE development. Could we drop the feel-good spin for a
moment and consider the evidence:
- Some JSR's are as good as abandoned, i.e. JSR-296 where the spec
lead (before
I'm glad to hear this is a server issue.
That said, what a way to start off on the wrong foot! You'd think Sun
(being a hardware company) would err on the side of throwing /too much/
at the problem given the criticality of a smooth and sexy release.
--
Jess Holle
Joshua Marinacci wrote:
We
Most critically for FX would seem to be the fix for D3D acceleration
issues on some specific Nvidia board models.
sherod wrote:
.It came out 2 days ago and is a bug fix issue mainly.
On Dec 5, 9:53 am, Matt Scully [EMAIL PROTECTED] wrote:
. but when did 6u11 come out? Was that released
better things to do than chase every shiny new kitchen
sink :-)
Now traits on the other hand... Traits would be really nice to add (if
done right -- as always the devil is in the details).
--
Jess Holle
On Dec 12, 5:02 am, Hairless_ape gantra...@gmail.com wrote:
What the hell
Christian Catchpole wrote:
On Dec 12, 5:33 am, Jess Holle je...@ptc.com wrote:
Overall conservative language evolution does not equal language death.
Some of us have better things to do than chase every shiny new kitchen
sink :-)
Maybe you are right, but it's such a waste
not come up often and isn't /that/ painful either. Not
being able to pass generics to the existing mountains of non-generic
aware code -- /that /would be excruciating for my work. I'd probably
still be unable to make any practical use of generics without erasure
doing its thing.
--
Jess
T[], and the like are all examples
where this actually hits you -- and generally it is easy to workaround
-- albeit while getting a clear sense that you shouldn't have to.
Jess Holle wrote:
Generics are really so painful? Really?
I use them a /lot/. While having to pass ClassT in classes
and hundreds of third
party libraries that have grown over the past decade that all needs to
talk together -- and still need Java to move forward, just without
marooning all of this or creating new and old ghettos.
--
Jess Holle
Frederic Simon wrote:
What Alex Buckley said on Java7 BOF
be
ignored unless you run into code using it phase.
--
Jess Holle
On Fri, Dec 12, 2008 at 2:08 PM, Casper Bang casper.b...@gmail.com
mailto:casper.b...@gmail.com wrote:
I agree, but that's obviously not the way it's ever done in Java,
considering we still have to use Vector from time to time
Jess Holle wrote:
Frederic Simon wrote:
About considering we still have to use Vector from time to time: I
asked Mark if he will put them in a dirty old Java module that can
be excluded in a profile. Basically, have clean new Java list of
modules as a base, and then add dirty old Java
include Perl and C++. From what I've seen Ruby, Scala, and
C# also fall into this category -- to differing degrees.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post
peter wrote:
On Dec 18, 9:46 am, Jess Holle je...@ptc.com wrote:
peter wrote:
As for the usual complexity claim: you can write easy-to-ready code in
scala (our 'big novelty' was to come up with coding guidelines), just
as you can write ugly code in scala. Note though, the same
into the picture.
--
Jess Holle
Joshua Marinacci wrote:
Absolutely. In any normal time 6u10 would really be a full new
release of Java. However, that would require even more overhead and
time due to the complexities of putting out a new release with new
API. We specifically designed 6u10
Kram wrote:
For a while now, I've been wanting to get my hands dirty on Java and
the JVM, by this is mean getting to know bytecode, and how compilers
work, JIT, the JVM in general, etc...
So the best thing I figure to do is to write my own, very basic,
language for the JVM. Even if it
I keep hearing that Groovy performance is hideous. Is this just FUD?
Paul Wallace wrote:
For me Groovy/Grails was the best discovery of 2008, and I can see a
place for the combo in the Enterprise world - initially Groovy for
scripting/testing.
Regarding the low profile, perhaps
you just never load if you don't use it.
Ideally Javadoc gets updated to hide such cruft by default as well.
Then you get the best of both worlds -- nothing breaks, but you don't
have to pay for cruft in any real sense.
--
Jess Holle
--~--~-~--~~~---~--~~
You
and are free to blabber on as they see fit.
--
Jess Holle
Ed G wrote:
How about offering a speeded-up version for those who like the amount
of information but want to do it quicker? A 10% or 20% speedup would
not be very noticeable (not like chipmunks at all!) and would save
that much time. After
to the simplifications it allows in the software
architecture.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe
as they want to do serious perusal of OpenJDK, NetBeans, or
OpenSolaris sources. [I think Sun bet on the wrong horse and should
drop Mercurical for Git as well, but that's another matter.]
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you
with the - notation (like Fan does), but being
realistic that's not doing to happen.
On Feb 8, 11:11 am, Jess Holle je...@ptc.com wrote:
My thinking is that when you combine Java's lowercase field and property
naming conventions with use of the existing . notation for properties
you cause confusion
, this does mean you amongst others) should be on Java 5 or
higher -- except, of course, that Sun gives the J2ME world no choice,
thus forcing part of the Java community to live in the past and making
it harder for all of us to move forward together.
--
Jess Holle
a 'devolving compiler' will
downgrade to whatever works on J2ME, and if it detects usage of API or
features that just cannot be downgraded, an error with a useful
message would result. Just saying its somewhat harder than it might
seem.
On Feb 17, 2:38 pm, Jess Holle je...@ptc.com wrote:
Brian
We've found that Groovy 1.6 eats up all the memory in sight for our use
cases (Groovy within complex Ant scripts), whereas 1.5.x does not. So
for us there's no Groovy 1.6 love at all -- it is completely unusable.
--
Jess Holle
hayden.paul.jo...@gmail.com wrote:
I was surprised
most everyone else in implementing and
supporting new Java versions (and new J2EE versions and so on). It is
thus hard to see them pushing Java's evolution anywhere nearly as fast
as Sun does -- despite all the stones thrown at Sun in this category.
--
Jess Holle
Steven Herod wrote:
http
apart from having source to Sun's JVM, I've much
preferred its behavior and reliability.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email
If Microsoft bought Java it would be an unambiguous call to action for
the Java community to take full ownership of their own OpenJDK fork.
IBM could likely successfully waffle such that OpenJDK is effectively
killed or crippled by a combination of their inactivity /and/ the
community's -- as
consultants or the source code.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email
I'm sure Sun execs told employees it was a focus thing and told them to
be focused.
Meanwhile they focused on selling the farm...
Joe Data wrote:
On Mar 18, 6:56 am, Steven Herod steven.he...@gmail.com wrote:
http://online.wsj.com/article/SB123735970806267921.html
Personally, it's
DB2's rear :-)
[DB2 is no Oracle...]
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group
ThreadPoolExecutor to behave
reasonable? [Yes, allowCoreThreadTimeOut() helps, but it really isn't
enough...]
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email
they are over-engineering the
solution.
I'm not saying you are doing that in this case.. My 2 cents.
Again, recently I wrote a comms pool which I know will never fall over
(of its own volition).
CC
On Apr 4, 2:20 pm, Jess Holle je...@ptc.com wrote:
I was naively and happily using
restrictions
would be different or change -- and then changed their mind. If so,
that's unfortunate, but I can understand how Sun would change their mind
if they made this mistake.
--
Jess Holle
P.S. I've encountered incompatibilities in J9 code adopted from Harmony
that were less than pleasant
with J9
would tend to suggest that the TCK is indeed too weak. Here Sun's
finances do again become relevant -- they can't afford massive
investment in the TCK or Java specification to add sufficient teeth to
ensure compatibility if sufficient teeth are not already present.
--
Jess Holle
?
Overall I'm just mystified as to what motivated them to cripple their
app engine -- at least to a degree. [I've seen their whitelist of Java
classes, but I've not seen their blacklist, so it is unclear what's all
missing from a glance.]
--
Jess Holle
Casper Bang wrote:
On 15 Apr., 15:30
for many companies and their customers. This is clearly evident
in most of the big enterprise players -- IBM, Oracle, Sun, etc, etc --
and their customers.
It is possible to innovate without burning compatibility -- it's just
another design constraint.
--
Jess Holle
of the last flu pandemic. There's
reason to worry, but there's no clear reason to worry that much about
*this* outbreak -- unless your immune system is already on shaky ground
or you have no access to good health care.
--
Jess Holle
Joshua Marinacci wrote:
When *treated* the flu annoying rather
swine flu outbreak isn't it.
On Apr 29, 2009, at 9:01 AM, Jess Holle wrote:
True enough -- for most flus.
Health officials are quite worried of something like the last flu
pandemic, though -- in that it caused healthy people's immune systems
to go into overdrive and hit the young healthy adults
to the developed world largely
forgetting about the huge numbers of people dying from malaria every year.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send
.
Fully agreed on that point.
You could worry about earthquakes, asteroid impacts, etc, as well if
you're going to worry about this. It's not worth the worry.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Put another way, is DB2 anywhere that's not either (1) still stuck on
mainframes or (2) so true-blue IBM that they're IBM thru-and-thru?
Considering some of the issues with it as compared to something like
Oracle, I'd be surprised.
--
Jess Holle
Carl Quinn wrote:
We stand corrected. I'll
on anything other than IBM
servers. I am curious on some of the issues though. I have never used
Oracle so I can't compare the two, but I am curious as to what
problems there are with DB2.
--
James R. Perkins
On Fri, May 1, 2009 at 10:22, Jess Holle je...@ptc.com
mailto:je...@ptc.com wrote
Having all eggs in one basket is a double-edged sword...
--
Jess Holle
Donald Bell wrote:
On May 2, 7:19 am, IngoF ingo.frei...@googlemail.com wrote:
In the end they have a chain starting with the IBM mainframe right
down to the individual developer workplace running Rational
Application
and critical Java IDE functionality.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group
Or is this simply a matter of it's too weird and dissimilar to anything
I have background in?
Be honest -- I don't mean the latter as a slam.
For instance, I'll admit that I find Scala far too weird and dissimilar
to anything I'm used to. While I like the ideas behind Scala, the
actual
But doesn't it work fine on both platforms except for some video codecs,
etc?
That says nothing about the overall technology set but rather about the
lack of portability of a handful of bits.
Paul Hardin wrote:
As a Java developer it does strike me that there is something deeply
wrong with
a horde of
creative, undisciplined developers loose and watch it happen.
--
Jess holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email to javaposse
function without using GPL'd NetBeans
code.
The classpathexception is rather clear on this. Compiling against
NetBeans libraries is not restricted by GPL in this case.
Recompiling/rebuilding existing portions of NetBeans is.
--
Jess Holle
Outside of Grizzly, which is based on NIO, of course, I think many folk
have avoided NIO entirely due to various items like this.
--
Jess Holle
John Wright wrote:
We've been using it in a production environment for 2 years with no
issues.
Its much faster and very stable. We've used
Any silly bit is fine by me -- as long as the Posse does not get so lost
in doing it that it takes them a long time to actually get to discussing
anything.
That occasionally accidentally happens, but that's life.
Otherwise silliness and the theme song are the only things that makes my
son not
enough that other parties don't necessarily step in to tackle various
problems in the space at all.
--
Jess Holle
P.S. I'd sooner see Sun do a Java for AIX so I wouldn't have to deal
with IBM's JVM than see them do a Java for the Mac. If Sun had infinite
money, it would be great to see them do
APIs throughout. ME is thus a death knell for
write once run anywhere. Sure, ME is meant to be a smaller subset of
APIs, etc, but using an antiquated version of the language means nothing
modern from SE can just run on ME. How's that for splintering the
community?
--
Jess Holle
Viktor
with FX, but the ME runtime is still broken in this
respect and still a problem to the degree to which ends up doing any
Java on it.
Fabrizio Giudici wrote:
Jess Holle wrote:
Well JavaFX can run on top of Java ME, right?
And there are unofficial (non-Google) ME adapters for Android, so
Fabrizio Giudici wrote:
Jess Holle wrote:
FX is an end-run around the ME fragmentation issue to a point.
I say to a point in that there would appear to be times where you really
need/want to duck into a Java library for part of the application's
back-end. Thus FX lessens the extent
sense.
There are other things that really gave me pause (e.g. the emphasis on
native packaging to the exclusion of cross-platform portable packaging
approaches!!!), but by-passing OSGi seems like a non-issue.
--
Jess Holle
P.S. I'd contrast this with by-passing log4j, for instance, where log4j
disagree with the decision.
--
Jess Holle
Eric Newcomer wrote:
Yes, that's what they keep saying. I'm sure they mean that they speak
when they see each other in the hallways at Java One, or after a
presentation. Or something like that.
But there is no participation in any OSGi expert group
in ME and no plans whatsoever to add these! On the
other hand, Google went a lot further to develop their own set of client
libraries rather than using any existing client libraries -- and thus is
creating another splinter UI platform space like SWT did before it.
--
Jess Holle
be another (almost certainly simpler) solution to part of the
problem space in the future.
I certainly do understand concerns about how OSGi and Jigsaw are /really
/going to work together, though.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message
in getting you around this -- until you hit the wall.
Java and JavaFX are far more attractive in this regard.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group
of that component instead
of moving to the new version, in which case it is time to upgrade.
--
Jess Holle
P.S. If you mean multiple versions just for things like a web app
reload, that's a different matter entirely, of course.
--~--~-~--~~~---~--~~
You received
/ configuration should be bound in
with annotations and that configuration files should then be used to
override this as needed.
That's the best of both worlds.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
. Wikipedia on the other. Google's not evil here, but clearly
what's best for them isn't necessarily best for everyone (not even
everyone but their competitors).
--
Jess Holle
ctwise wrote:
Google wants very much for everything to move to HTML. They don't
want Flash. They don't want
I believe SWT was a great kick in Sun's pants to get them to fix Swing, etc.
Now that it has done that I believe it has *no* reason to exist and is a
essentially the single reason I'd never choose to use the Eclipse RCP.
--
Jess Holle
Lhasadad wrote:
If it wasn't for the pressure of something
to even attempt to do anything about this!
If Android does nothing else it will hopefully give these folks a kick
in the pants to either (1) really update J2ME, (2) support J2SE [plus
mobility libraries] and give up on J2ME, or (3) give up and support
Android instead of J2ME.
--
Jess Holle
be preserved for JavaFX, but things
will fall on their face as soon as you need to use a Java library.
Android in some ways holds up to the WORA promise better than J2ME.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed
important than reification in my book as well.
--
Jess Holle
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from
Because Mac OS X fully supports the hardware it is sold for.
It's not expected to support more. It's part of the Mac-way.
One of Linux x86's promises has always been to support the broad range
of x86 hardware. People expect to grab any old x86 system and for Linux
to work. Same goes for
1 - 100 of 300 matches
Mail list logo
